El 76% no tenía CSP y el 64% podía cargarse dentro de un marco controlado por otro sitio. Esos son los dos resultados más llamativos de una revisión de páginas web de protocolos DeFi publicada en DEV Community. El análisis examinó las respuestas que recibía un navegador corriente; no intentó explotar los sitios ni conectarse a sus carteras.
La diferencia importa: las cifras describen la configuración visible de las páginas analizadas, no incidentes ni pérdidas. Aun así, apuntan a defensas web que pueden ser relevantes cuando una interfaz invita a firmar operaciones con una cartera.
Qué midió la revisión
El equipo partió de los protocolos de DefiLlama que tenían sitio web —unos 4.000 dominios— y eligió 1.000 al azar. De ellos, 896 respondieron; 39 bloquearon las comprobaciones automatizadas y 65 no respondieron. Los porcentajes publicados usan como base esos 896 sitios.
La comprobación fue pasiva: se cargó la página de inicio y se revisaron cabeceras de respuesta, indicadores de cookies, HTTPS, scripts de terceros y enlaces rotos. No hubo inicio de sesión, conexión de cartera, envío de formularios ni búsqueda de archivos ocultos. Tampoco se publicaron nombres de proyectos ni resultados individuales.
Además de la falta de CSP y de protección contra framing, el equipo encontró que el 35% no tenía HSTS, el 27% cargaba scripts de terceros sin Subresource Integrity (SRI), el 6% tenía cookies sin los atributos Secure o HttpOnly y el 5% presentaba enlaces rotos en la página de inicio.
La limitación principal está en dónde se hizo la prueba. En muchos proyectos, la página de inicio es una web informativa y la aplicación que contiene el botón para conectar una cartera vive en otra dirección. Por eso, el propio análisis presenta sus resultados como una señal para investigar, no como demostración de que las personas usuarias de esos proyectos corran peligro.
Una interfaz puede ser parte de la superficie de ataque
El informe contrasta las medidas dedicadas a proteger contratos inteligentes con la atención que reciben las webs que los usuarios utilizan para interactuar con ellos. Como antecedentes, cita el incidente de BadgerDAO de diciembre de 2021, con pérdidas de unos 120 millones de dólares, donde un script inyectado en la interfaz pidió aprobaciones de tokens. También menciona el incidente de Ledger Connect Kit de diciembre de 2023: una versión envenenada de una biblioteca de interfaz muy utilizada convirtió dApps en herramientas para vaciar carteras.
La CSP, o política de seguridad de contenido, permite al sitio limitar los recursos que el navegador puede cargar y los destinos a los que puede enviar datos. Según el análisis, funciona como una segunda barrera si ya se ha conseguido inyectar un script: puede restringir de dónde se ejecuta código y adónde se transmiten datos. No evita por sí sola toda inyección, pero una política explícita reduce lo que ese código podría hacer.
El framing plantea otro riesgo. La guía de pruebas de OWASP describe el clickjacking como un engaño en el que una página oculta la aplicación objetivo dentro de un iframe y hace que la persona pulse elementos distintos de los que cree estar usando. En una interfaz que solicita firmas, el equipo de DEV Community plantea que un atacante podría alinear un botón de aprobación bajo otro que prometa, por ejemplo, reclamar una recompensa.
La página cargada sigue siendo la auténtica, pero la persona puede interactuar con ella sin darse cuenta de qué acción está realizando. OWASP también advierte que algunas defensas contra CSRF pueden eludirse en este escenario. Por eso, no basta con que el contrato inteligente sea correcto si la interfaz que conduce a una firma puede presentarse de forma engañosa.
La comparación no muestra una ventaja en las dos defensas clave
Para comparar, el equipo revisó también 1.000 webs corrientes; 571 respondieron. En tres medidas, los sitios DeFi salieron mejor parados: faltaba HSTS en el 35% frente al 61%; las cookies carecían de Secure o HttpOnly en el 6% frente al 26%; y el 27% tenía scripts de terceros sin SRI, frente al 64%.
Pero la comparación cambia en las protecciones más vinculadas a interfaces que piden firmas. El 64% de los sitios DeFi podía enmarcarse desde otra web, frente al 58% de los sitios corrientes. Y el 76% carecía de CSP, frente al 79% en la otra muestra. En otras palabras, la revisión no encontró una ventaja de DeFi en esos dos controles; tampoco demuestra que las webs comparadas ofrezcan el mismo tipo de interacción o riesgo.
Configuración sencilla, pero con decisiones de compatibilidad
El equipo propone tres medidas: una CSP con una lista explícita de scripts permitidos y la directiva frame-ancestors 'none'; SRI para cada script de terceros —o alojarlos en la propia infraestructura—; y HSTS. Según el equipo, estas correcciones son de configuración, no de código, y las tres pueden desplegarse en una tarde.
La directiva frame-ancestors permite especificar qué sitios pueden insertar una página mediante elementos como iframe. OWASP recomienda usarla como defensa del lado del servidor contra el clickjacking. El valor 'none' impide que otros sitios la enmarquen; en un producto que necesite permitir marcos legítimos, la política tendrá que reflejar esa necesidad en vez de bloquearlos sin distinción.
La CSP también exige decidir qué recursos necesita realmente la aplicación. Una lista explícita de scripts permitidos puede limitar la ejecución de código no autorizado, pero debe incluir los orígenes legítimos que la web utiliza. La propia revisión señala un matiz para SRI: sirve para que el navegador rechace un script cuyo contenido haya cambiado, pero no es aplicable a scripts que cambian por diseño, como la mayoría de las etiquetas de analítica. Para esos casos, el informe señala la CSP como protección.
El contraste entre corrección rápida y compatibilidad es especialmente práctico para equipos que dependen de proveedores externos: la recomendación no es añadir controles sin comprobar su efecto, sino decidir qué scripts necesita la página y cuáles pueden alojarse en el propio sitio. El análisis no ofrece datos sobre cuánto trabajo llevó cada corrección ni prueba las políticas propuestas en cada proyecto; su afirmación sobre el tiempo de despliegue es una estimación del equipo.
Qué debería comprobar un equipo
El resultado más útil no es asumir que una aplicación concreta es vulnerable, sino revisar las páginas donde se producen las acciones sensibles, no solo la portada. La metodología publicada se centró en páginas de inicio y reconoce que la aplicación con conexión de cartera puede estar en otro dominio. Además, OWASP recomienda comprobar las variantes móviles y de accesibilidad: pueden tener protecciones distintas de las de escritorio.
También conviene verificar las cabeceras que recibe el navegador en cada página relevante. OWASP advierte que los proxies pueden eliminar o modificar cabeceras, y que una protección aplicada solo en algunas páginas deja otras sin cubrir. La CSP, la política de framing y HSTS deben evaluarse en las respuestas efectivas, no únicamente en la configuración que el equipo cree haber desplegado.
La revisión ofrece una fotografía acotada de noviembre de 2026, basada en la lista de protocolos de DefiLlama y en una carga de las páginas de inicio. No permite saber cuántas aplicaciones completas heredan esos mismos fallos. Sí deja una pregunta concreta para cada equipo DeFi: ¿la página que presenta el botón de conexión y la solicitud de firma tiene las mismas defensas que su portada?
Fuentes: DEV Community, OWASP Foundation
