Content Security Policy (CSP)

El servidor envía una política como una lista de directivas, y cada una nombra los orígenes permitidos para un tipo de recurso. El navegador la aplica y rechaza todo lo que quede fuera de la lista, y si se quiere puede informar de las violaciones a un endpoint que tú designes. Las directivas que soportan el peso son script-src, que decide qué puede ejecutarse, object-src, que debería estar vacía, base-uri, que impide que una etiqueta base inyectada redirija las URL relativas de los scripts, y frame-ancestors, que controla quién puede enmarcar la página y sustituye a la cabecera de enmarcado antigua frente al clickjacking.

Una política moderna no hace listas de dominios permitidos. Marca los scripts que la página pretende ejecutar con un nonce por respuesta o con un hash, de modo que el script inyectado no tiene nonce y no se ejecuta, y usa strict-dynamic para que los scripts cargados por script de confianza hereden esa confianza sin que la política tenga que conocer todas las máquinas.

Casi todas las políticas que nos encontramos son decorativas. El hallazgo más frecuente con diferencia es 'unsafe-inline' dentro de script-src, que permite exactamente el script inyectado en línea que la política existe para bloquear, y que casi siempre se añadió para que funcionara una etiqueta de analítica. El siguiente es un nonce que no es por respuesta, porque un nonce que un atacante puede predecir o reutilizar no es un nonce. Después vienen listas de permitidos tan amplias que contienen una máquina que sirve un framework desactualizado o una plataforma de contenido de usuario, lo que le da al atacante un sitio de confianza donde alojar su carga.

El asunto del enmarcado va aparte y se pasa por alto a menudo: una política puede ser impecable para el script y aun así omitir frame-ancestors. Y una política que se queda en modo de solo informe después del despliegue no aplica absolutamente nada, que es un estado habitual meses después de que terminara el proyecto que la introdujo. La CSP es defensa en profundidad frente al cross-site scripting, nunca un sustituto de codificar la salida.

La política pertenece a la línea base de hardening, así que la leemos respuesta a respuesta y no en la documentación, porque suele variar según la ruta, y demostramos la consecuencia: una inyección que la política detiene es un hallazgo, y una inyección que la política deja pasar es otro. El informe lista las directivas, la vulnerabilidad concreta y una carga real que la política actual permite. Arreglar la cabecera sin arreglar la inyección cambia la severidad, no el hallazgo. Esto forma parte de cómo evaluamos los controles del lado del navegador en una aplicación web.