Content Security Policy: meta http-equiv

Content Security Policy es una política aplicada por el navegador que restringe qué recursos puede cargar y ejecutar una página. Es la defensa más sólida contra Cross-Site Scripting: incluso si un atacante inyecta una etiqueta <script>, el navegador se niega a ejecutarla a menos que la política lo permita.

CSP puede enviarse como encabezado de respuesta HTTP (Content-Security-Policy: ...) o como etiqueta meta en HTML: <meta http-equiv="Content-Security-Policy" content="...">. Se recomienda el encabezado; la etiqueta meta resulta útil cuando no puede controlar el servidor.

default-src es el valor de respaldo para los tipos de recursos no especificados. script-src, style-src, img-src, connect-src (XHR/fetch), font-src y frame-src restringen cada uno su tipo correspondiente. Incluya en la lista de permitidos orígenes específicos o utilice 'self' para permitir únicamente el mismo origen.

'self' (entre comillas) hace referencia al propio origen de la página. script-src 'self' significa "ejecutar únicamente scripts alojados en el mismo origen que la página". Esta es la base de la mayoría de las políticas; añada CDN externos específicos cuando sea necesario.

De forma predeterminada, CSP bloquea todas las etiquetas <script> en línea y los atributos de controladores de eventos (onclick). Esta es la protección más sólida contra XSS: un <script> inyectado no puede ejecutarse porque está en línea. Traslade todos los scripts a archivos externos referenciados mediante src.

Para los scripts en línea necesarios, utilice un nonce: el servidor genera un token aleatorio por solicitud, lo establece como script-src 'nonce-RANDOM' en CSP y añade nonce="RANDOM" a las etiquetas <script> legítimas. Los scripts inyectados no tienen el nonce y se bloquean.

'unsafe-inline' vuelve a permitir scripts y estilos en línea. 'unsafe-eval' vuelve a permitir eval() y new Function(). Ambos debilitan gravemente CSP; utilícelos solo como último recurso durante una migración y planifique eliminarlos.

La CSP entregada mediante una etiqueta meta no puede utilizar la directiva report-uri ni otras funciones de generación de informes. Además, entra en vigor más tarde que un encabezado: cualquier contenido anterior a la etiqueta meta queda sin protección. Los encabezados son estrictamente mejores; utilice meta solo como alternativa.

Pruebe una política nueva sin interrumpir el sitio: Content-Security-Policy-Report-Only: .... El navegador informa de las infracciones sin bloquearlas, de modo que puede ajustar la política hasta permitir todos los recursos legítimos antes de activar la aplicación efectiva.

Olvidar style-src 'unsafe-inline' bloquea los estilos en línea, que a menudo generan los frameworks. Olvidar connect-src bloquea las solicitudes AJAX a las API. Pruebe siempre primero la política en modo de solo informes y revise la consola para detectar los recursos bloqueados.

Una CSP estricta combina script-src 'nonce-RANDOM' 'strict-dynamic' para los scripts con una lista de permitidos restrictiva para todo lo demás. 'strict-dynamic' permite que los scripts con nonce carguen otros scripts sin enumerar cada uno, lo que facilita mucho el mantenimiento frente a las listas de permitidos por origen.

¿Cómo se defiende CSP contra los ataques XSS incluso cuando un atacante logra inyectar una etiqueta de script?

CSP es una política aplicada por el navegador que restringe qué scripts, estilos, imágenes y otros recursos pueden cargarse. Puede implementarse mediante un encabezado de respuesta (opción preferida) o una etiqueta meta. Utilice nonces para los scripts en línea necesarios, evite unsafe-inline y unsafe-eval y pruebe primero en modo de solo informes. La CSP estricta con 'nonce-X' 'strict-dynamic' es la base moderna.