Saltar al contenido

Constructor de políticas CSP

CSP Builder

Arma una cabecera Content-Security-Policy desde un formulario guiado o desde un informe de violaciones, y explica cada directiva.

Content-Security-Policy es la cabecera que convierte un fallo de cross-site scripting de un compromiso en un mensaje bloqueado en la consola, y también es la cabecera que más a menudo se publica en una forma que no hace nada. Esta herramienta construye una directiva por directiva y explica qué está impidiendo realmente cada una.

🔒 Se ejecuta por completo en tu navegadorcspheaderswebgenerator
Cargar una política existente

El valor al que recurren todas las directivas de carga que no fijes explícitamente.

De dónde pueden cargarse los scripts. La directiva que de verdad frena el XSS.

De dónde pueden cargarse las hojas de estilo.

De dónde pueden cargarse las imágenes.

De dónde pueden cargarse las tipografías.

A dónde pueden conectarse fetch, XHR, WebSocket y EventSource.

De dónde pueden cargarse <audio> y <video>.

De dónde pueden cargarse <object>/<embed>. Lo normal es dejarlo en 'none'.

De dónde pueden cargarse los documentos de <iframe>.

Quién puede meter esta página en un marco: el sustituto moderno de X-Frame-Options.

Qué puede ponerse en <base href>. Limítalo a 'self' o 'none'.

A dónde pueden enviarse los formularios.

De dónde pueden cargarse los Workers, SharedWorkers y service workers.

De dónde puede cargarse el manifiesto de la aplicación web.

Reescribe las peticiones de subrecursos http:// a https://.

Bloquea de plano cualquier subrecurso http:// (heredado).

  • ⚠ No hay frame-ancestors: añádelo (por ejemplo 'none' o 'self') para controlar quién puede enmarcar la página.
  • ⚠ No hay base-uri: añade base-uri 'self' para frenar la inyección de la etiqueta <base>.

Content-Security-Policy

default-src 'self'; script-src 'self'

Cómo se usa

  1. Empieza desde el formulario o desde un informe

    El formulario guiado pregunta de dónde vienen los scripts, los estilos, las imágenes y las conexiones. Si ya tienes informes de violaciones, pégalos y las fuentes se derivan de lo que realmente se cargó.

  2. Despliégala primero en modo solo informe

    `Content-Security-Policy-Report-Only` registra las violaciones sin bloquear. Déjala una semana y los informes nombrarán el embebido de terceros que nadie recordaba.

  3. Quita `unsafe-inline` al final, y bien

    Una política con `script-src 'unsafe-inline'` bloquea casi nada. Sustitúyelo por un nonce por respuesta o por hashes de los bloques en línea; la herramienta genera las dos formas.

Preguntas frecuentes

¿La herramienta prueba mi sitio?

No. Compone y explica una política a partir de lo que le dices. Comprobar lo que un sitio en producción envía ahora mismo es trabajo del análisis de cabeceras de seguridad.

¿Por qué mi política sigue permitiendo scripts en línea?

Un nonce o un hash en `script-src` se ignora cuando `unsafe-inline` también está presente en la misma directiva, por compatibilidad hacia atrás. No se pueden mantener las dos cosas: gana la de respaldo.

¿Basta con `default-src 'self'` por sí solo?

Es una buena base, pero varias directivas no recurren a él: `frame-ancestors`, `form-action` y `base-uri`, entre otras. Esas hay que fijarlas explícitamente, y esta herramienta las fija.

Puede recibir de

Después

Estas aceptan lo que produce esta herramienta, así que el resultado puede pasar directamente.