Generador CSP
Ciberseguridad corporativa•Cumplimiento RFC 3986 y W3C CSP3

Generador CSP & Content Security Policy

Genera cabeceras Content Security Policy (CSP) seguras al instante. Configura script-src, style-src, nonces y hashes para mitigar ataques XSS y resolver errores de CSP.

100
Postura de seguridad OWASPBlindada (Grado A+)
Perfiles de seguridad predefinidos:
1
Ingesta y parsing AST de directivas
16 directivas y tokenizador de orígenes
2
Nonces criptográficos y Web Crypto
CSPRNG criptográfico de 128 bits y SHA-256
3
Auditoría estática de bypass OWASP
7 detectores de bypass de severidad alta
4
Emisión multiplataforma para servidores
Nginx, Caddy, Next.js y Apache
Parámetros y entradas
Régimen de despliegue arquitectónico
Modo de aplicación de la cabecera
Opciones avanzadas y directivas de orden superiorNivel de especificación W3C CSP Level 3
Compatibilidad de nivel CSP (W3C Level 1/2/3)
Sintetizador Web Crypto de nonce CSPRNG y hash SHA-256
window.crypto.subtle
Prefijo de nonce criptográficodG9vbHNhYS1zZWN1cmUtbm9uY2UtMjAyNg==
Generador de hashes SHA-256 para scripts inline:'sha256-RFWzHiTAeaP0v89upId2U1QGEGNhBlCe/JC9Zdqvqo='
Inyectores de orígenes para servicios verificados:
default-srcDirectivas de carga (fetch)Sin fallback (aislado)
Universal fallback boundary for all fetch directives when omitted.
'self'
script-srcDirectivas de carga (fetch)Hereda de default-src
Governs valid sources for JavaScript execution and inline scripts.
'self''strict-dynamic''nonce-dG9vbHNhYS1zZWN1cmUtbm9uY2UtMjAyNg=='https:'unsafe-inline'
style-srcDirectivas de carga (fetch)Hereda de default-src
Governs valid sources for stylesheets, inline styles, and CSS fonts.
'self''unsafe-inline'
img-srcDirectivas de carga (fetch)Hereda de default-src
Governs valid sources of images, SVG vectors, and favicons.
'self'data:https:
connect-srcDirectivas de carga (fetch)Hereda de default-src
Restricts script interfaces: fetch(), XMLHttpRequest, WebSocket, and sendBeacon.
'self'
font-srcDirectivas de carga (fetch)Hereda de default-src
Governs sources for web fonts loaded via @font-face rules.
'self'data:
object-srcDirectivas de carga (fetch)Hereda de default-src
Restricts plugins (<object>, <embed>, <applet>). OWASP mandates 'none'.
'none'
media-srcDirectivas de carga (fetch)Hereda de default-src
Governs valid sources for <audio> and <video> HTML5 media streams.
(Recurre a default-src si se deja vacío)
frame-srcDirectivas de carga (fetch)Hereda de default-src
Governs valid sources for nested browsing contexts (child <iframe> elements).
(Recurre a default-src si se deja vacío)
worker-srcDirectivas de carga (fetch)Hereda de default-src
Restricts Worker, SharedWorker, and ServiceWorker execution origins.
(Recurre a default-src si se deja vacío)
manifest-srcDirectivas de carga (fetch)Hereda de default-src
Governs valid sources of progressive web application (PWA) manifests.
(Recurre a default-src si se deja vacío)
base-uriDirectivas de documentoSin fallback (aislado)
Restricts URLs in <base> tags. CRITICAL: does NOT inherit from default-src!
'none'
form-actionNavegación y marcosSin fallback (aislado)
Restricts target submission endpoints for HTML <form> elements.
'self'
frame-ancestorsDirectivas de documentoSin fallback (aislado)
Clickjacking Armor: restricts parents embedding this site. HTTP header only!
'none'
report-uriReportingSin fallback (aislado)
Legacy URI collector endpoint for W3C CSP Level 2 violation reports.
(Sin restricciones explícitamente; no recomendado)
report-toReportingSin fallback (aislado)
Modern W3C Reporting API endpoint group identifier.
(Sin restricciones explícitamente; no recomendado)
Directivas activas: 11Orígenes permitidos totales: 18
Estricto moderno (strict-dynamic)
Content-Security-Policy: upgrade-insecure-requests; default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-dG9vbHNhYS1zZWN1cmUtbm9uY2UtMjAyNg==' https: 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self'; font-src 'self' data:; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; require-trusted-types-for 'script'; trusted-types default dompurify

# Recommended Defense-in-Depth Headers:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cabecera HTTP: Content-Security-Policy
Procesamiento 100% en memoria local
Métrica principal100Escala de puntuación OWASP
Eficiencia y capacidad11 directivas18 orígenes
Resultado netoBloqueando (Enforce)

Procesamiento en el cliente

Cálculo de alto rendimiento ejecutado íntegramente en la memoria del navegador.

Cero subida al servidor

Todos los datos permanecen estrictamente locales sin comunicación con servidores externos.

Exportación para producción

Formatos de salida limpios y optimizados listos para su despliegue inmediato.

Referencia técnica y guía de arquitectura

Generador Content Security Policy (CSP) — Guía de referencia

Genera cabeceras Content Security Policy (CSP) seguras al instante. Configura script-src, style-src, nonces y hashes para mitigar ataques XSS y resolver errores de CSP.

Generador Content Security Policy (CSP) — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos
Generador Content Security Policy (CSP) — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos

Parámetros clave y controles

default-src (Límite de Reserva Fetch)lista de orígenes (reserva fetch W3C)

Actúa como la directiva de reserva universal para todas las directivas de obtención de recursos (script-src, style-src, img-src, connect-src, font-src, object-src, media-src, frame-src, worker-src, manifest-src). Configurar 'self' restringe las categorías no asignadas al origen actual, mientras que establecer 'none' impone declaraciones explícitas y obligatorias en todos los tipos de recursos.

Por defecto: 'self' (Reserva solo mismo origen)
script-src & 'strict-dynamic' (Blindaje contra Ejecución XSS)lista de orígenes y expresiones de palabras clave

Controla los orígenes de ejecución de JavaScript, previniendo ataques de cross-site scripting (XSS). En W3C CSP Nivel 3, combinar un nonce criptográfico o hash con 'strict-dynamic' instruye a los navegadores modernos para que confíen en scripts creados dinámicamente por scripts raíz autorizados, ignorando al mismo tiempo las listas de dominios permitidos heredadas y 'unsafe-inline'.

Por defecto: 'self' 'strict-dynamic' 'nonce-...' (Estricto moderno)
object-src & base-uri (Defensa contra Plugins y Navegación)lista de orígenes (integridad del documento)

object-src restringe la ejecución de plugins como Flash, Java y Silverlight; configurarlo en 'none' es una directriz de referencia obligatoria de OWASP. base-uri limita las URL permitidas en etiquetas HTML <base href>; de forma crítica, base-uri NO hereda de default-src, lo que implica que omitirlo deja el sitio expuesto a inyecciones de etiquetas base que secuestran las URL relativas de los scripts.

Por defecto: object-src 'none'; base-uri 'none'
frame-ancestors (Protección contra Clickjacking y UI Redressing)directiva de enmarcado (solo cabecera de respuesta HTTP)

Especifica los elementos padre válidos que pueden incrustar la página mediante etiquetas <frame>, <iframe>, <embed> o <applet>, sustituyendo la cabecera obsoleta X-Frame-Options. Declarar 'none' impide que cualquier sitio web incruste la página (evitando ataques de clickjacking), mientras que 'self' permite la incrustación únicamente desde el mismo origen. Nota: frame-ancestors se ignora por completo dentro de etiquetas HTML <meta>.

Por defecto: 'none' o 'self' (Protección anticlickjacking)
connect-src (Límite de API y Exfiltración de Datos)lista de orígenes URL (fetch / XHR / WebSocket)

Restringe los destinos URL hacia los cuales los scripts pueden emitir peticiones a través de interfaces como fetch(), XMLHttpRequest, WebSocket (wss://), EventSource y navigator.sendBeacon(). Resulta esencial para mitigar la exfiltración de datos confidenciales por parte de scripts de terceros comprometidos que intenten enviar tokens de sesión a servidores externos no autorizados.

Por defecto: 'self' (Solo API del origen actual)
upgrade-insecure-requests & report-to (Transporte y Telemetría)indicador de directiva y grupo de reportes

upgrade-insecure-requests ordena a los navegadores transformar automáticamente todas las URL HTTP a HTTPS antes de iniciar la petición, suprimiendo advertencias por contenido mixto. report-to define el grupo de puntos de enlace de la Reporting API hacia los cuales el navegador envía reportes JSON estructurados sobre violaciones de directivas, modernizando y sustituyendo gradualmente la directiva obsoleta report-uri.

Por defecto: upgrade-insecure-requests (Habilitado)

Consejos profesionales y mejores prácticas

'strict-dynamic' Inhabilita las Listas de Dominios en CSP3

Cuando se incluye 'strict-dynamic' junto con un nonce o hash en script-src, la especificación W3C CSP Nivel 3 estipula que los navegadores modernos ignoren automáticamente las listas de orígenes permitidos como https: o https://*.google.com, así como 'unsafe-inline'. Las listas de dominios se conservan en la cabecera únicamente como respaldo de compatibilidad con navegadores antiguos (CSP Nivel 2). Si utilizas 'strict-dynamic', no confíes en listas blancas de dominios para habilitar scripts de terceros: ¡el script cargador raíz debe portar obligatoriamente el atributo nonce!

Omitir base-uri Permite el Secuestro de Scripts Mediante Inyección HTML

Muchos desarrolladores asumen erróneamente que declarar default-src 'self' protege todo el documento. Sin embargo, base-uri NO hereda de default-src. Si se omite base-uri, un atacante que descubra una vulnerabilidad leve de inyección HTML (como un comentario o etiqueta markdown sin sanear) puede inyectar <base href='https://evil-attacker.com/'>. El navegador resolverá entonces todos los scripts con rutas relativas (como <script src='/static/app.js'>) apuntando hacia evil-attacker.com, eludiendo por completo la política script-src 'self'. Declara siempre de forma explícita base-uri 'none' o 'self'.

'unsafe-inline' se Ignora de Forma Segura en Presencia de un Nonce o Hash en CSP2+

Si necesitas dar soporte a navegadores antiguos que solo implementan CSP Nivel 1 manteniendo la máxima seguridad en navegadores modernos, puedes especificar de forma segura: script-src 'nonce-XYZ123' 'unsafe-inline'. De acuerdo con los estándares W3C CSP Nivel 2 y Nivel 3, siempre que se define un nonce o un hash, cualquier navegador moderno descarta por completo 'unsafe-inline'. Esto garantiza retrocompatibilidad impecable sin comprometer la seguridad en clientes actuales.

default-src NO Protege contra Ataques de Clickjacking ni Secuestro de Formularios

Existe la creencia equivocada de que default-src 'none' bloquea todas las superficies del documento. En la práctica, default-src únicamente gobierna las directivas de obtención de recursos (fetch directives). No tiene efecto alguno sobre frame-ancestors (que impide que tu sitio sea incrustado en iframes maliciosos para clickjacking) ni sobre form-action (que restringe los destinos a los que los formularios <form> pueden enviar credenciales sensibles). Debes declarar frame-ancestors 'none'/'self' y form-action 'self' de manera explícita.

Problemas comunes y soluciones

⚠️La consola del navegador muestra: Refused to execute inline script because it violates the following Content Security Policy directive: 'script-src 'self''

Este error ocurre porque se está ejecutando una etiqueta <script> en línea o un controlador de eventos HTML inline (como onclick o onload) sin autorización. Para solucionarlo según los estándares modernos: (1) Añade un nonce criptográfico a la etiqueta del script (<script nonce='...'>) y declara dicho nonce coincidente en script-src 'nonce-...'; (2) Alternativamente, calcula el hash SHA-256 exacto del contenido del script e incorpora 'sha256-...' en script-src; o (3) Refactoriza los manejadores inline extrayéndolos a archivos JavaScript externos vinculados mediante addEventListener.

⚠️La llamada a la API falla con: Refused to connect to 'https://api.example.com' because it violates connect-src

Los navegadores modernos restringen las peticiones originadas por fetch(), XMLHttpRequest, WebSocket (wss://) y sendBeacon a los orígenes declarados en connect-src. Si connect-src no se declara explícitamente, el navegador recurre a default-src. Si tu interfaz frontend se comunica con un backend independiente o con servicios de terceros (por ejemplo, Stripe, Sentry o una pasarela API externa), añade el origen exacto (por ejemplo, connect-src 'self' https://api.example.com https://api.stripe.com) a tu configuración de CSP.

⚠️El hash SHA-256 declarado en script-src sigue fallando con error de violación de CSP en Google Chrome o Firefox

El cálculo del hash en CSP se valida a nivel de bits de forma estricta. Una simple diferencia en un salto de línea final, retornos de carro (\r\n frente a \n) o espacios en blanco entre el hash calculado y el contenido real del script inline provocará una discrepancia criptográfica. Asimismo, no debes incluir las etiquetas de apertura <script> ni de cierre </script> al generar el hash: calcula únicamente el resumen del código interno. Comprueba además que tu motor de plantillas en el servidor no reformatee ni minifique el script tras computar el hash.

⚠️La directiva frame-ancestors parece ignorarse cuando se define en una etiqueta HTML <meta>

Según la especificación W3C Content Security Policy, las directivas frame-ancestors, report-uri y report-to están terminantemente prohibidas y se ignoran dentro de elementos HTML <meta http-equiv='Content-Security-Policy'>. Para mitigar el clickjacking y aplicar frame-ancestors, la directiva DEBE emitirse obligatoriamente como una cabecera de respuesta HTTP real configurada en tu servidor web (por ejemplo, mediante add_header en Nginx, Header set en Apache o un middleware en Next.js).

Preguntas frecuentes (FAQ)

¿Cómo crear una Content Security Policy para frenar ataques XSS?▼

Para bloquear ataques de Cross-Site Scripting (XSS), implementa una política CSP estricta basada en nonces o hashes criptográficos junto con 'strict-dynamic' y object-src 'none'. Una cabecera inicial sólida es: Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-RANDOM_BASE64' 'unsafe-inline'; object-src 'none'; base-uri 'none'; frame-ancestors 'none';. Esta estructura previene la ejecución de scripts inline no autorizados, neutraliza exploits en plugins y bloquea el secuestro de URL mediante la etiqueta base.

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

default-src es la directiva de reserva general que se aplica a todos los tipos de recursos que carecen de una directiva explícita (abarcando script-src, style-src, img-src, connect-src y font-src). En cambio, script-src regula de forma exclusiva los orígenes desde los cuales se pueden cargar y ejecutar scripts en JavaScript y código inline. Si script-src está definida, prevalece sobre default-src para todos los recursos de script; si se omite, el navegador recurre a default-src.

¿Por qué 'unsafe-inline' se considera peligroso en Content Security Policy?▼

'unsafe-inline' resulta peligroso porque autoriza al navegador a ejecutar cualquier bloque o atributo JavaScript inline que se encuentre en el documento, incluidos los scripts inyectados por atacantes mediante vulnerabilidades de XSS reflejado o almacenado. Permitir 'unsafe-inline' desmantela la principal barrera de defensa de CSP, a menos que se acompañe de un nonce criptográfico o de 'strict-dynamic', lo cual fuerza a los navegadores modernos a ignorar dicha palabra clave.

¿Cómo funcionan los nonces de CSP y cómo deben generarse?▼

Un nonce de CSP (número de un solo uso o 'number used once') es un token aleatorio con entropía criptográfica (típicamente de 128 bits codificado en Base64) generado dinámicamente en el servidor web para cada petición HTTP individual. El servidor emite este token en la cabecera HTTP (script-src 'nonce-abc123xyz') y agrega el atributo idéntico a los scripts inline autorizados (<script nonce='abc123xyz'>). Dado que los atacantes no pueden predecir el nonce, los scripts inyectados son bloqueados al instante.

¿Cuál es la diferencia entre Content-Security-Policy y Report-Only?▼

Content-Security-Policy aplica la directiva de manera activa, bloqueando scripts, conexiones y hojas de estilo infractoras mientras registra las violaciones. Por su parte, Content-Security-Policy-Report-Only permite que los recursos no conformes se carguen y ejecuten con normalidad sin interrumpir la experiencia del usuario, enviando reportes detallados a los endpoints configurados (report-to / report-uri). Report-Only constituye el estándar de oro de la industria para auditar entornos de producción antes de activar el bloqueo estricto.

¿Es posible configurar una Content Security Policy mediante una etiqueta meta de HTML?▼

Sí, es posible declarar una política mediante el elemento HTML <meta http-equiv='Content-Security-Policy' content='...'> dentro de la etiqueta <head> del documento. Sin embargo, las especificaciones de la W3C prohíben estrictamente las directivas de enmarcado y telemetría dentro de etiquetas meta; directivas como frame-ancestors, report-uri y report-to serán ignoradas por el navegador. Para disponer de una protección integral contra clickjacking y supervisión de incidentes, CSP debe enviarse siempre como cabecera HTTP de respuesta.

Herramientas y utilidades relacionadas

Todas las herramientas →