Una política de seguridad de contenido (CSP) ayuda a garantizar que el propietario del sitio confíe en cualquier contenido cargado en la página. Los CSP mitigan los ataques de secuencias de comandos entre sitios (XSS) porque pueden bloquear las secuencias de comandos no seguras inyectadas por los atacantes. Sin embargo, el CSP puede pasarse por alto fácilmente si no es lo suficientemente estricto. Consulte Mitigar secuencias de comandos entre sitios (XSS) con una política de seguridad de contenido (CSP) estricta para obtener más información. Lighthouse recopila los CSP aplicados en el documento principal e informa los problemas de CSP Evaluator si se pueden omitir.

Prácticas requeridas para un CSP no anulable

implemente las siguientes prácticas para asegurarse de que su CSP no se pueda omitir. Si se puede omitir el CSP, Lighthouse emitirá una advertencia de gravedad alta. CSP apunta a XSS # Para apuntar a XSS, un CSP debe incluir las directivas script-src, object-src y base-uri. El CSP también debe estar libre de errores de sintaxis. script-src y object-src protegen una página de scripts inseguros y complementos inseguros respectivamente. Alternativamente, default-src se puede usar para configurar una política amplia en lugar de muchas directivas, incluidas script-src y object-src. base-uri evita la inyección de etiquetas no autorizadas que se pueden usar para redirigir todas las URL relativas (como secuencias de comandos) a un dominio controlado por un atacante. CSP usa nonces o hashes para evitar eludir la lista de permitidos # Un CSP que configura una lista de permitidos para script-src se basa en la suposición de que todas las respuestas provenientes de un dominio de confianza son seguras y se pueden ejecutar como scripts. Sin embargo, esta suposición no se cumple para las aplicaciones modernas; algunos patrones benignos comunes, como la exposición de interfaces JSONP y el alojamiento de copias de la biblioteca AngularJS, permiten a los atacantes escapar de los límites de CSP. En la práctica, si bien puede no ser obvio para los autores de la aplicación, un atacante con un error XSS puede eludir la mayoría de las listas permitidas de script-src y brinda poca protección contra la inyección de script. Por el contrario, los enfoques basados ​​en nonce y hash no sufren estos problemas y facilitan la adopción y el mantenimiento de una política más segura. Por ejemplo, este código utiliza un punto final JSONP alojado en un dominio de confianza para inyectar un script controlado por un atacante:

CSP:

HTML

Para evitar ser eludido, un CSP debe permitir secuencias de comandos individualmente usando nonces o hashes y usar 'estricto-dinámico' en lugar de una lista de permitidos. Recomendaciones adicionales para un CSP seguro # Implemente las siguientes prácticas para mayor seguridad y compatibilidad. Si el CSP no sigue una de las recomendaciones, Lighthouse emitirá una advertencia de gravedad media. Configurar informes de CSP # La configuración de un destino de informes ayudará a controlar cualquier rotura. Puede establecer el destino de los informes mediante las directivas report-uri o report-to. Actualmente, report-to no es compatible con todos los navegadores modernos, por lo que se recomienda usar ambos o solo report-uri. Si algún contenido viola el CSP, el navegador enviará un informe al destino configurado. Asegúrese de tener una aplicación configurada en este destino que maneje estos informes. Defina el CSP en un encabezado HTTP # Un CSP se puede definir en una metaetiqueta como esta: However, you should define a CSP in an HTTP response header if you can. An injection before the meta tag will bypass the CSP. Additionally, frame-ancestors, sandbox and reporting are not supported in meta tag CSPs. Ensure CSP is backwards compatible # Not all browsers support CSP nonces/hashes, therefore adding unsafe-inline as a fallback for non-compliant browsers is recommended. If the browser does support nonces/hashes, unsafe-inline will be ignored. Similarly, strict-dynamic is not supported by all browsers. It is recommended to set an allowlist as a fallback for any non-compliant browsers. The allowlist will be ignored in browsers that support strict-dynamic. How to develop a strict CSP # Below is an example of using a strict CSP with a nonce-based policy.

CSP:

HTML

random123 sería cualquier cadena base64 generada en el lado del servidor cada vez que se carga la página. unsafe-inline y https: se ignoran en los navegadores modernos debido a la dinámica estricta y nonce. Para obtener más información sobre cómo adoptar un CSP estricto, consulte la guía de CSP estricto. Puede verificar un CSP en busca de posibles desvíos usando Lighthouse y CSP Evaluator. Si desea probar un nuevo CSP sin correr el riesgo de romper las páginas existentes, defina el CSP en modo de solo informe utilizando Content-Security-Policy-Report-Only como nombre de encabezado. Esto enviará infracciones de CSP a cualquier destino de informes que haya configurado con report-to y report-uri, pero en realidad no aplicará el CSP.