Generador de cabeceras CSP gratis

Crea cabeceras de Content Security Policy para tu sitio web. Gratis, rápido y funciona por completo en tu navegador sin necesidad de registro.

Actualizado

Share:
Home/Security Tools/CSP Generator

CSP Generator

Build Content Security Policy headers interactively with presets, directive builder, nonce support, and strictness scoring.

CSP Builder

Strictness Score
70/100
Nonce:Not generated

Directives

default-src
L1

Fallback for other fetch directives

'self'
script-src
L1

Valid sources for JavaScript

'self'
style-src
L1

Valid sources for stylesheets

'self'
'unsafe-inline'
img-src
L1

Valid sources for images

'self'
data:
font-src
L1

Valid sources for fonts

'self'
connect-src
L1

Valid targets for fetch, XHR, WebSocket

'self'
object-src
L1

Valid sources for plugins (Flash, etc.)

'none'
frame-ancestors
L2

Valid parents that can embed this page

'none'

Preguntas Frecuentes

¿Qué es el generador de CSP?

El generador de CSP es una herramienta en línea gratuita que crea encabezados de Content Security Policy para proteger tu sitio web contra XSS, clickjacking y otros ataques de inyección.

¿El generador de CSP es gratuito?

Sí, es completamente gratuito y no requiere registro. Toda la generación de políticas se realiza del lado del cliente en tu navegador.

¿Por qué necesito una Content Security Policy?

Una CSP indica a los navegadores qué fuentes de contenido son de confianza, bloqueando scripts maliciosos y reduciendo el riesgo de ataques de cross-site scripting (XSS) en tu sitio web.

¿Están seguros mis datos con esta herramienta?

Por supuesto. El generador de encabezados CSP procesa todo del lado del cliente en tu navegador. No se sube ni se almacena ningún dato en ningún servidor. Tu contenido permanece privado en tu dispositivo en todo momento.

¿Funciona el generador de encabezados CSP en dispositivos móviles?

Sí, el generador de encabezados CSP es totalmente adaptable y funciona en teléfonos y tabletas. 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 generador de encabezados CSP en tu navegador y empieza a usarlo de inmediato. No hay barreras de registro ni restricciones de uso.

¿Cómo uso el generador de encabezados CSP?

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

¿Qué navegadores son compatibles?

El generador de encabezados CSP funciona en todos los navegadores modernos, incluidos 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 'self', 'none' y 'unsafe-inline' en una CSP?

Estas son palabras clave de origen de CSP que le indican al navegador qué contenido permite una directiva. 'self' permite recursos solo desde tu propio origen (mismo esquema, host y puerto), así que un script-src con 'self' carga tus propios scripts pero bloquea los de terceros. 'none' es el valor más estricto: bloquea toda fuente para esa directiva, por eso object-src 'none' es un paso de endurecimiento habitual. 'unsafe-inline' reactiva los scripts y estilos inline escritos directamente en tu HTML, y 'unsafe-eval' permite código basado en eval(); ambos son cómodos pero reabren exactamente el agujero de XSS que CSP existe para cerrar, así que usa un nonce o un hash cuando sea posible. Este generador te permite hacer clic en estas palabras clave directamente sobre cada directiva y muestra cómo cada elección mueve tu puntaje de rigurosidad, para que veas el compromiso de seguridad mientras construyes.

¿Por qué mi Content Security Policy no funciona en una etiqueta meta HTML?

Algunas directivas simplemente se ignoran cuando la CSP se entrega mediante una etiqueta meta HTML en lugar de una cabecera de respuesta HTTP real. La directiva frame-ancestors, que previene el clickjacking controlando quién puede embeber tu página, solo funciona como cabecera porque la decisión de encuadre ocurre antes de que el documento procese la etiqueta meta. La directiva report-uri, para recolectar reportes de violaciones, y la directiva sandbox se ignoran en formato meta por la misma razón. Por eso, si tus reglas anti-clickjacking o de reporte parecen no hacer nada, esa suele ser la causa. Siempre que controles la configuración de tu servidor, prioriza la cabecera HTTP. Esta herramienta señala exactamente esta limitación en su vista de Salida y te entrega la cabecera Content-Security-Policy en bruto junto con bloques de configuración listos para pegar en Nginx, Apache, Express.js y Next.js, para que la despliegues de la forma correcta.

¿Cómo uso un nonce de CSP para permitir de forma segura un script inline específico?

Un nonce es un token aleatorio de un solo uso que te permite confiar en un script inline específico sin abrir la puerta con 'unsafe-inline'. Agregas el valor 'nonce-{aleatorio}' a tu directiva script-src, y luego colocas el atributo nonce correspondiente en la etiqueta script que quieres permitir, como <script nonce="{aleatorio}">. El navegador ejecuta solo los scripts inline que lleven ese token exacto y bloquea cualquier otro script inyectado, así que un atacante que no pueda adivinar el valor no puede ejecutar su payload. La regla crítica es que el nonce debe generarse de nuevo en cada carga de página, nunca debe estar codificado de forma fija ni reutilizarse. Este generador crea un nonce criptográficamente fuerte con la API crypto.getRandomValues() del navegador y te entrega la cadena formateada 'nonce-...' para copiarla tanto en tu política como en tus etiquetas script.

¿Cuál es la diferencia entre el modo solo-reporte y aplicar una CSP en modo forzado?

Una política demasiado estricta bloquea silenciosamente scripts, estilos o llamadas a API legítimas, así que enviar CSP directo a producción en modo forzado es arriesgado. El modo solo-reporte resuelve esto. Al enviar la política bajo la cabecera Content-Security-Policy-Report-Only en lugar de Content-Security-Policy, el navegador no bloquea nada; solo registra cada violación que habría causado, enviando los detalles a tu endpoint report-uri. Esto te permite observar el tráfico real, descubrir qué recursos disparan la política y corregir las reglas antes de que algún usuario vea una página rota. El patrón de despliegue seguro estándar es lanzar primero en modo solo-reporte, monitorear hasta que los reportes se calmen, y luego cambiar a la cabecera de aplicación forzada. Usa el generador de esta herramienta para armar y ajustar la política, y su vista de Prueba para verificar URLs específicas contra tus directivas antes de comprometerte con el modo forzado.

¿Qué preset de CSP debería usar como punto de partida para WordPress o una aplicación de una sola página?

Elegir una base sensata es más rápido y seguro que construir desde cero, y el punto de partida correcto depende de tu stack. El preset de WordPress es más permisivo porque los temas y plugins suelen inyectar scripts y estilos inline, así que permite 'unsafe-inline' y fuentes de embebido comunes como YouTube y Vimeo para evitar romper el panel de administración y el frontend. El preset de SPA es adecuado para builds de React, Vue o Angular: mantiene script-src ajustado en 'self', agrega worker-src para workers de tipo blob, y abre connect-src para tus endpoints de API y WebSocket. También existen los presets Estricto, Moderado y Relajado, que cubren todo el rango desde el máximo bloqueo hasta el más permisivo. Aplica el preset más cercano en esta herramienta, y luego recorta o extiende directivas individuales según tus dominios reales de terceros mientras el puntaje de rigurosidad en vivo te guía hacia una política más dura.

Acerca del Generador de Cabeceras CSP

El Generador de Cabeceras CSP es una herramienta gratuita para construir una Content Security Policy (Política de Seguridad de Contenido) — la cabecera de respuesta HTTP que le indica al navegador qué orígenes de scripts, hojas de estilo, imágenes, fuentes y otros recursos tiene permitido cargar en tu página. Una política bien ajustada es una de las defensas más sólidas contra el cross-site scripting (XSS), ya que impide que el navegador ejecute scripts inyectados o de terceros que nunca aprobaste. La herramienta está pensada para desarrolladores web, dueños de sitios e ingenieros de seguridad que quieren una política correcta sin memorizar la sintaxis.

Todo ocurre en tu navegador. No hay registro, no hay carga de archivos y no se envía nada a un servidor — armas la política en tu propio dispositivo y copias el resultado. Ese diseño del lado del cliente también significa que la herramienta funciona apenas carga la página.

Construye una política directiva por directiva

La política se construye a partir de directivas individuales, cada una controlando un tipo de recurso. El generador admite 15 directivas de los niveles 1 a 3 de CSP, incluyendo default-src, script-src, style-src, img-src, font-src, connect-src, frame-ancestors, base-uri, form-action, y adiciones más recientes como worker-src y manifest-src. Para cada directiva agregas valores de origen — ya sea haciendo clic en sugerencias comunes como 'self', 'none', data: o https:, o escribiendo un origen personalizado. Si prefieres partir de una base ya probada, tienes cinco presets a un clic de distancia: Estricto, Moderado, Relajado, WordPress y SPA.

Para permitir de forma segura scripts inline específicos, la herramienta también genera un nonce criptográfico usando la API crypto.getRandomValues() del navegador, listo para incluir tanto en tu política como en tus etiquetas <script>.

Lee el puntaje de rigurosidad mientras avanzas

Un puntaje de rigurosidad en vivo, sobre 100, refleja cuán blindada está tu política. Premia las decisiones que más importan: un default-src restrictivo, un script-src libre de 'unsafe-inline' y 'unsafe-eval', object-src 'none', un frame-ancestors definido y un report-uri para recolectar reportes de violaciones. Vale la pena entender estas palabras clave:

  • 'self' permite recursos solo desde tu propio origen.
  • 'none' bloquea toda fuente para esa directiva.
  • 'unsafe-inline' y 'unsafe-eval' vuelven a abrir la puerta al código inline y basado en eval() — cómodo, pero debilita la protección que CSP busca ofrecer.
  • 'strict-dynamic', los nonces y los hashes son la forma moderna y más segura de confiar en scripts específicos.

El puntaje es una verificación rápida, no una garantía, así que igual conviene probar tu política contra páginas reales antes de aplicarla en modo forzado.

Copia el resultado en el formato que despliegas

Una vez que la política queda como quieres, la vista de Salida te entrega fragmentos listos para pegar: la cabecera HTTP Content-Security-Policy: en bruto, una etiqueta HTML <meta> y bloques de configuración de servidor para Nginx, Apache, Express.js y Next.js. Un recordatorio que muestra la herramienta: algunas directivas — frame-ancestors, report-uri y sandbox — solo funcionan como cabecera HTTP real y se ignoran dentro de una etiqueta meta, así que prioriza la cabecera siempre que controles la configuración del servidor.

Prueba antes de forzar

Los fallos de CSP son fáciles de enviar a producción porque una política demasiado estricta bloquea recursos legítimos sin avisar. La vista de Prueba te permite pegar una URL — digamos un script de un CDN o un endpoint de analítica — y ver, directiva por directiva, si tu política actual la permitiría o la bloquearía. Un conjunto de ejemplos comunes de violaciones muestra a los culpables típicos, desde scripts y estilos inline hasta intentos de clickjacking detectados por frame-ancestors, cada uno junto con su solución. Un patrón de despliegue seguro es lanzar primero en modo solo-reporte, observar qué se dispara, y recién entonces pasar a la aplicación forzada una vez que los reportes se calman.

Construye tu política arriba, observa cómo sube el puntaje de rigurosidad, y cópiala en el formato que coincide con tu stack.