Generador de Content Security Policy (CSP)

Cómo crear una política

1. Elige un punto de partida en Empezar desde una plantilla: Estricta (nonce + strict-dynamic), Sitio estático blindado, Sitio web típico o Típico + Google Analytics / Ads. El editor se abre con la plantilla de sitio web típico.
2. Ajusta las Directivas. Cada campo admite orígenes separados por espacios; si dejas un campo vacío, la directiva no se incluye.
3. Usa Añadir rápido para agregar una palabra clave a la Directiva elegida: 'self', 'none', 'unsafe-inline', 'strict-dynamic', https:, data:… Añadir un nonce inserta un nonce aleatorio de 128 bits.
4. Para permitir un script en línea concreto sin recurrir a 'unsafe-inline', pégalo (o el HTML que lo rodea) en Calcular el hash de un script o estilo en línea y pulsa Calcular SHA-256 y añadir.
5. Marca upgrade-insecure-requests si alguna URL antigua sigue usando http:// y, si quieres, indica una URL del endpoint de informes.
6. Copia la Cabecera HTTP, la Cabecera Report-Only o la Etiqueta HTML . La Revisión de esta política se actualiza mientras escribes.

Para auditar una política que ya tienes, pégala en Evaluar una política existente y pulsa Evaluar la política; Cargar en el editor la copia en los campos para que puedas retocarla.

Para qué sirve una Content Security Policy

Una CSP le indica al navegador desde qué orígenes puede cargar una página scripts, estilos, imágenes, fuentes, iframes y conexiones. Su función principal es limitar el cross-site scripting (XSS): aunque un atacante consiga inyectar marcado en tu página, una buena política impide que el script inyectado se ejecute. También controla quién puede incrustar tu página en un iframe (frame-ancestors), adónde pueden enviarse los formularios (form-action) y a qué puede apuntar <base> (base-uri).

Las directivas de carga como img-src o font-src recurren a default-src cuando faltan. En cambio, base-uri, form-action y frame-ancestors no tienen ese respaldo, y por eso la revisión las pide de forma explícita.

Nonces, hashes y strict-dynamic

Permitir hosts (script-src https://cdn.example.com) parece seguro, pero a menudo se puede eludir: los grandes dominios alojan endpoints JSONP y bibliotecas antiguas que un atacante puede reutilizar. El enfoque que recomiendan los equipos de seguridad de los navegadores es una CSP estricta: cada <script> legítimo lleva un nonce que el servidor genera en cada respuesta, o se autoriza mediante su hash, y 'strict-dynamic' permite que esos scripts de confianza carguen los scripts que necesitan. Con ese planteamiento, https: y 'unsafe-inline' solo sirven de respaldo para navegadores muy antiguos; los modernos los ignoran.

Un nonce solo funciona si cambia en cada respuesta y es impredecible. El que inserta Añadir un nonce es un ejemplo: tu servidor o tu framework debe generar el suyo. Un hash cubre los bytes exactos del código en línea, así que si vuelves a formatear el script necesitarás un hash nuevo.

Cabecera, Report-Only y etiqueta meta

Siempre que puedas, envía la política como cabecera de respuesta HTTP. Despliégala primero como Content-Security-Policy-Report-Only: los navegadores informan de las infracciones (en la consola y en tu endpoint si has definido uno) sin bloquear nada, de modo que puedes corregir tus páginas antes de aplicarla de verdad. Los ajustes de informes añaden report-uri para navegadores antiguos y report-to con una cabecera Reporting-Endpoints.

La versión <meta http-equiv> resulta práctica en alojamientos estáticos, pero los navegadores ignoran en ella frame-ancestors, report-uri, report-to y sandbox, y no existe una etiqueta meta Report-Only. La herramienta quita esas directivas de la etiqueta y te lo indica.

Todo se genera en tu navegador: la política que escribes o pegas no se envía a ningún servidor.