Skip to content

CSP no corrige XSS. Con suerte limita el impacto

Content Security Policy ayuda, pero no sustituye el encoding contextual, las APIs DOM seguras ni la eliminación de sinks peligrosos.

Publicado el 1 min de lectura

Content Security Policy es una de las defensas más malinterpretadas de la seguridad web.

No es un parche. CSP es una política del navegador que puede bloquear algunas rutas de ejecución después de que la aplicación ya produjo una salida insegura. Eso es valioso, pero llega tarde.

Si una entrada no confiable alcanza un contexto ejecutable, la aplicación todavía tiene un bug XSS.

Una política estricta cambia la clase de payload

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

Los manejadores inline como onerror=alert(1) deberían fallar. También muchas URLs javascript: y scripts remotos. Pero eso no vuelve segura a la aplicación: obliga al tester a buscar gadgets del mismo origen, nonces reutilizados o rutas heredadas con unsafe-inline.

CSP no es output encoding

La corrección de una inyección HTML reflejada sigue siendo encoding contextual. La corrección de DOM XSS sigue siendo eliminar sinks inseguros o usar sanitización adecuada. CSP ayuda cuando algo se escapa, pero no debe ser el control principal.

Artículos relacionados

Las pruebas XSS responsables dependen del alcance, la evidencia, la minimización de datos y saber cuándo una prueba de concepto ya es suficiente.
Una mirada práctica a por qué las herramientas XSS no deberían procesar en servidor URLs internas, fragmentos privados o notas sensibles de pruebas.
La elección del payload importa menos que el contexto de inyección: HTML, atributos, URLs, scripts y sinks DOM fallan de formas distintas.