Constructor de Content Security Policy

Crea cabeceras CSP de forma visual con plantillas predefinidas, controles por directiva, advertencias de validación, puntuación de rigurosidad y modo report-only.

Actualizado

Share:
Home/Website Tools/Content Security Policy Builder

Content Security Policy Builder

Visually build Content Security Policy headers with preset templates, per-directive controls, validation warnings, and strictness scoring.

Preset Templates

Use Content-Security-Policy-Report-Only header (monitors violations without enforcing)

Strictness Score
0/100
Weak

0 directives enabled

Directives

Preguntas Frecuentes

¿Qué es CSP?

Una cabecera HTTP que controla qué recursos puede cargar un navegador, lo que previene ataques de XSS e inyección de datos.

¿Aplicada frente a solo de informe?

La aplicada bloquea las infracciones. La de solo informe las permite pero las reporta, lo cual es útil para hacer pruebas antes de aplicarla.

¿Por qué evitar unsafe-inline/eval?

unsafe-inline permite scripts en línea explotables. unsafe-eval habilita la ejecución de código dinámico. Ambos debilitan considerablemente la protección de CSP.

¿Es gratuito el Constructor de Content Security Policy?

Sí, el Constructor de Content Security Policy es 100 % gratuito, sin registro, sin cargos ocultos y sin límites de uso. Todo el procesamiento ocurre localmente en tu navegador, garantizando una privacidad total.

¿Funciona el Constructor de Content Security Policy en dispositivos móviles?

Sí, el Constructor de Content Security Policy es totalmente adaptable y funciona en smartphones y tablets. Puedes usarlo en cualquier dispositivo con un navegador web moderno, sin necesidad de descargar ninguna aplicación.

¿Necesito crear una cuenta para usar esta herramienta?

No se necesita ninguna cuenta ni registro. Simplemente abre el Constructor de Content Security Policy en tu navegador y empieza a usarlo de inmediato. No hay muros de registro ni restricciones de uso.

¿Cómo uso el Constructor de Content Security Policy?

Solo tienes que introducir tus datos en el campo correspondiente, ajustar las opciones a tu gusto y la herramienta los procesará al instante. Después puedes copiar el resultado al portapapeles o descargarlo.

¿Qué navegadores son compatibles?

El Constructor de Content Security Policy funciona en todos los navegadores modernos, como Chrome, Firefox, Safari, Edge y Opera. Para una mejor experiencia, usa la última versión de tu navegador preferido.

¿Cuál es la diferencia entre default-src y script-src en una CSP?

default-src es la directiva de respaldo: establece las fuentes permitidas para cualquier tipo de recurso que no hayas configurado explícitamente, así que fijarla en 'none' o 'self' crea una base de denegación por defecto. script-src es una anulación específica que controla únicamente desde dónde puede cargarse JavaScript, y tiene prioridad sobre default-src para los scripts. Como los scripts son el vector principal del cross-site scripting, casi siempre conviene tener un script-src estricto aunque default-src ya sea restrictivo; por ejemplo, default-src 'self' junto con un script-src 'self' independiente que añade un nonce. Otras directivas por tipo, como style-src, img-src y connect-src, funcionan igual, acotando un tipo de recurso mientras default-src cubre el resto. Este creador te permite establecer default-src una sola vez y anular directivas individuales solo donde haga falta.

¿Cómo añado una cabecera CSP en Nginx o Apache?

En Nginx añades la política dentro de un bloque server o location con add_header Content-Security-Policy "tu política aquí" always; el indicador always garantiza que la cabecera se envíe incluso en respuestas de error como los 404. En Apache usas Header set Content-Security-Policy "tu política aquí" dentro del VirtualHost correspondiente o en el .htaccess, con mod_headers habilitado. En ambos casos el valor es la cadena completa de directivas, y hay que recargar el servidor para que surta efecto. Acertar con la sintaxis a mano es propenso a errores, así que este creador genera fragmentos listos para copiar y pegar para Nginx, Apache, Express.js y Next.js a partir de la política que configures. Define tus directivas de forma visual, elige tu servidor y pega el bloque generado directamente en tu configuración.

¿Por qué no puedo usar frame-ancestors ni report-uri en una CSP dentro de una etiqueta meta?

Una CSP puede entregarse de dos maneras: como cabecera de respuesta HTTP Content-Security-Policy o como etiqueta HTML <meta http-equiv="Content-Security-Policy"> en el head de la página. El método de la etiqueta meta es cómodo cuando no puedes editar la configuración del servidor, pero la especificación ignora deliberadamente ciertas directivas en ese contexto. frame-ancestors, report-uri, report-to y sandbox solo funcionan cuando se envían como una cabecera HTTP real, porque deben conocerse antes de que la página se renderice o porque se relacionan con el reporte a nivel de respuesta. Si la protección contra clickjacking te importa, frame-ancestors debe venir de la cabecera, no de la etiqueta meta. Este creador te permite alternar entre los formatos de salida de cabecera y meta, y te avisa de qué directivas se descartan en el modo meta, para que no publiques una política que pierda silenciosamente su protección contra el clickjacking.

¿Cómo funciona la puntuación de rigurosidad y qué hace que una CSP puntúe más alto?

Cada cambio recalcula una puntuación de rigurosidad sobre 100, calificada como Débil, Aceptable, Buena o Excelente. La puntuación premia decisiones realmente protectoras en lugar de la mera presencia de una política. Obtienes la mayor cantidad de puntos por un default-src restrictivo ('none' supera a 'self'), un script-src sin las palabras clave unsafe-inline ni unsafe-eval, object-src 'none' y un frame-ancestors definido. Añadir base-uri, form-action, un style-src limpio y otras directivas de acotación empuja el número aún más hacia arriba, mientras que las fuentes con comodín y las palabras clave inseguras lo mantienen bajo. Activar el modo de solo informe (report-only) reduce ligeramente la puntuación, ya que una cabecera de solo informe no ofrece bloqueo real hasta que aplicas la política. La pestaña de Análisis detalla exactamente qué está determinando tu puntuación, para que veas qué puntos débiles corregir y pasar de Buena a Excelente.

¿Qué es un nonce o un hash en una CSP y cuándo debería usar uno en lugar de unsafe-inline?

Un nonce es un token aleatorio que tu servidor genera en cada carga de página y coloca tanto en la CSP como en cada etiqueta <script> de confianza; el navegador solo ejecuta los scripts que llevan el nonce correspondiente. Un hash funciona de forma similar, pero identifica un script en línea específico mediante su huella sha256, sin necesitar un token por solicitud. Ambos te permiten conservar los scripts en línea necesarios mientras eliminas 'unsafe-inline', que de otro modo permitiría ejecutar cualquier script en línea inyectado y anularía tu protección contra XSS. Combinar un nonce con 'strict-dynamic' también permite que los scripts de confianza carguen sus propias dependencias sin necesidad de incluir en la lista blanca cada dominio. Este creador incluye valores de fuente con marcadores de nonce y sha256, y recomienda pasar de unsafe-inline a un enfoque basado en nonce o hash. Configura aquí script-src con un marcador de nonce y luego conecta el token real en tu servidor.

Acerca del creador de políticas de seguridad de contenido (CSP)

El creador de políticas de seguridad de contenido convierte una cabecera de seguridad notoriamente delicada en un ejercicio de apuntar y hacer clic. En lugar de escribir a mano una larga cadena Content-Security-Policy y confiar en que la sintaxis sea correcta, marcas las directivas que necesitas, eliges sus fuentes permitidas y la herramienta ensambla una política válida en tiempo real. Está pensada para desarrolladores, propietarios de sitios web y equipos con foco en seguridad que quieren protección contra XSS e inyecciones sin memorizar toda la especificación de CSP.

Una política de seguridad de contenido es una cabecera de respuesta HTTP que le indica al navegador exactamente qué orígenes tienen permiso para cargar scripts, estilos, imágenes, fuentes, marcos (frames) y otros recursos. Cuando una página intenta cargar algo que la política no permite, el navegador lo bloquea. Ese único mecanismo frena la mayoría de los ataques de cross-site scripting (XSS), bloquea la exfiltración de datos no autorizada y, mediante frame-ancestors, protege contra el clickjacking.

Construye una política directiva por directiva

El creador expone 15 directivas estándar de tipo fetch y navegación, entre ellas default-src, script-src, style-src, img-src, connect-src, frame-ancestors, base-uri, form-action y worker-src. Activa cualquier directiva y asigna valores de origen desde una lista seleccionada: palabras clave como 'self', 'none', 'strict-dynamic', marcadores de nonce y sha256, y fuentes de esquema como https:, data: y blob:. También puedes añadir dominios personalizados (por ejemplo https://cdn.example.com o *.example.com) para incluir en la lista blanca tu CDN, tus herramientas de analítica o tus proveedores de contenido multimedia embebido.

Si prefieres no partir de cero, seis plantillas predefinidas rellenan configuraciones razonables:

  • Basic Secure — una política basada en 'self' que cubre las directivas más comunes
  • Strict — bloquea default-src en 'none' y permite explícitamente solo lo estrictamente necesario
  • Permissive — un punto de partida flexible para sitios antiguos que aún usan código en línea
  • WordPress — contempla scripts en línea, Google Fonts e incrustaciones de YouTube/Vimeo
  • Next.js — gestiona los requisitos de inline y eval propios del framework
  • SPA (React/Vue) — ajustada para aplicaciones de página única y workers de tipo blob

Puntúa tu política y detecta puntos débiles

Cada cambio actualiza una puntuación de rigurosidad sobre 100, calificada de Débil a Aceptable, Buena y Excelente. La puntuación premia decisiones realmente protectoras: un default-src restrictivo, un script-src libre de palabras clave inseguras, object-src 'none' y un frame-ancestors definido; y la pestaña de Análisis detalla qué está determinando ese resultado.

Se marcan al instante dos fuentes de riesgo. 'unsafe-inline' permite scripts en línea explotables y es la razón más común por la que una CSP no logra detener el XSS; 'unsafe-eval' permite eval() y otras formas de ejecución dinámica de código. El creador señala ambas con advertencias y sugiere alternativas más seguras basadas en nonce o en hash. Las recomendaciones también te orientan hacia directivas protectoras que falten, como base-uri y form-action.

Pruébala de forma segura y despliégala en cualquier servidor

CSP puede romper un sitio si se bloquea un recurso legítimo, así que el creador incluye un modo de solo informe (report-only). Este emite la cabecera Content-Security-Policy-Report-Only, que registra las infracciones en un endpoint de reporte opcional sin bloquear realmente nada, la forma recomendada de validar una política en producción antes de aplicarla de verdad. Ten en cuenta que esto reduce ligeramente la puntuación de rigurosidad, ya que una cabecera de solo informe no ofrece protección real hasta que pasas al modo de aplicación.

Cuando la política esté lista, cópiala como cabecera HTTP en bruto o como etiqueta HTML <meta http-equiv> (la herramienta te recuerda que frame-ancestors, report-uri y sandbox no se pueden establecer mediante una etiqueta meta). Se generan fragmentos listos para usar en Nginx, Apache, Express.js y Next.js, y puedes descargar el resultado como archivo.

Todo se ejecuta enteramente en tu navegador. Ninguna política, dominio o configuración se envía a un servidor, no hace falta registrarse, y el creador de políticas de seguridad de contenido funciona en cualquier navegador moderno, móviles incluidos.