Validador de cabecera CSP

Pega el valor de una cabecera Content-Security-Policy para validar de una sola vez sus directivas y valores de origen. Detecta configuraciones de riesgo como unsafe-inline, la falta de un default-src de respaldo y errores tipográficos en los nombres de directivas, y muestra en un desglose visual las fuentes permitidas de cada directiva.

Última actualización: 2026-09-20

Examinar el contenido de una cabecera CSP

Una Content-Security-Policy es una sola cadena larga separada por puntos y comas, y seguirla a simple vista hace fácil pasar por alto lo arriesgado. Esta herramienta toma el valor que usted pega, lo descompone en directivas y fuentes, saca a la luz los ajustes peligrosos, las declaraciones ausentes y las faltas de ortografía, y expone qué permite realmente cada directiva.

**Una directiva mal escrita es, de todos, el caso más traicionero.** Los navegadores ignoran en silencio las directivas que no reconocen, de modo que escribir `scipt-src` en lugar de `script-src` **no provoca error alguno mientras esa parte de la política sigue sin hacer absolutamente nada.** Igual de fácil de pasar por alto es la ausencia de `default-src`: sin ella, toda directiva que usted no haya detallado queda sin restricción y se abre un hueco en la defensa. Y meter `unsafe-inline` en script-src **anula casi por completo el bloqueo de los scripts en línea, que es el motivo principal para adoptar CSP.**

Cómo se usa

Pegue el valor de la cabecera CSP Introduzca una cadena de la forma `default-src 'self'; script-src ...` tal como está.
Pruebe antes con los ejemplos Se ofrecen un ejemplo bueno y uno malo, de modo que puede ver en qué difieren los dictámenes antes de empezar.
Lea los puntos señalados **Se señalan `unsafe-inline`, la falta de `default-src` y las faltas de ortografía.**
Revise las fuentes permitidas por directiva Puede ver de un vistazo desde dónde se permite cargar.

Consejos para aprovecharla mejor

CSP normalmente se entrega como cabecera de respuesta HTTP, pero también puede establecerse mediante una etiqueta <meta http-equiv="Content-Security-Policy"> (aunque directivas como report-uri no tienen efecto ahí).
Antes de implantar CSP en producción, prueba primero la cabecera Content-Security-Policy-Report-Only: solo recopila informes de violaciones, lo que te permite medir el impacto en la funcionalidad existente sin romper nada.
Los comodines (*) y 'unsafe-inline' facilitan el desarrollo, pero anulan buena parte de la protección de CSP frente a XSS. Endurece siempre una política laxa antes de pasar a producción.
Repetir la misma directiva dos veces no combina los valores: solo se aplica la primera aparición. Para añadir o sobrescribir fuentes, mantén todo dentro de una única directiva.
La consola de DevTools del navegador muestra los recursos bloqueados con un mensaje rojo del tipo "Refused to load...", por lo que es el primer lugar donde mirar al depurar una CSP demasiado restrictiva.

Cuándo resulta útil

Al introducir una CSP por primera vez

Puede confirmar que la política escrita hace lo que pretendía antes de que se acerque siquiera a producción.

Al hacer inventario de una política existente

**Una política crecida por acumulación suele conservar permisos de dominios que ya nadie usa.**

Al pasar de solo informar a exigir

Un valor probado bajo `Content-Security-Policy-Report-Only` puede examinarse antes de imponerlo.

Al asistir una revisión de código

Pegue la política modificada y confirme que no ha quedado debilitada.

Términos de CSP

Directiva: Una entrada como `script-src` o `img-src` que **declara desde dónde puede cargarse una clase dada de recurso.**
Default-src: El valor al que recurre toda directiva no declarada por separado. **Omítala y toda clase que no haya detallado queda sin restricción.**
'self': Una expresión de fuente que solo permite cargas del mismo origen.
'unsafe-inline': Una expresión de fuente que permite scripts y estilos escritos directamente en el HTML. **Sacrifica casi por entero la defensa frente al XSS, por lo que se aconseja sustituirla por un nonce o un hash.**
Nonce: Un esquema que escribe un valor aleatorio de un solo uso tanto en la etiqueta del script como en la política, para que ambos se correspondan. Es la manera segura de permitir código en línea.
Frame-ancestors: Una directiva que nombra a quién le está permitido incrustar su sitio en un marco. **Es la sucesora de X-Frame-Options.**

Preguntas frecuentes

CSP le indica al navegador exactamente qué fuentes están autorizadas a proporcionar scripts, imágenes, estilos y otros recursos en la página. Cualquier cosa que no esté en la lista de permisos —incluidos los scripts en línea— se bloquea al cargarse o ejecutarse, lo que reduce drásticamente el riesgo de que un ataque XSS ejecute un script controlado por un atacante.

Sí: tanto las fuentes de tipo nonce ('nonce-') como las de tipo hash ('sha256-') funcionan. Al añadir un atributo nonce a una etiqueta de script que coincida con el valor de la cabecera de respuesta, puedes autorizar esa etiqueta concreta mientras sigues bloqueando cualquier otro script en línea no autorizado.

CSP bloqueó un recurso porque su origen no estaba en la lista de permisos. La consola del navegador muestra un mensaje del tipo "Refused to load...because it violates the following Content Security Policy directive", que indica el origen exacto; añade ese origen a la lista de permisos de la directiva correspondiente para solucionarlo.

Normalmente no. default-src solo actúa como valor de respaldo para las directivas que no has definido explícitamente. Directivas de alto riesgo como script-src y object-src deberían configurarse cada una de forma explícita y estricta, ya que representan una superficie de ataque mucho mayor que la mayoría de las demás directivas.

Ambas especifican adónde debe enviar el navegador los informes de violaciones, pero report-uri es la directiva más antigua y apunta directamente a una URL de notificación. report-to se basa en la más reciente Reporting API y, en su lugar, hace referencia a un grupo con nombre definido en una cabecera Report-To independiente. Como el soporte de los navegadores para ambas difiere, es habitual especificar las dos por compatibilidad.

A propósito — Por qué existe CSP: escapar la salida nunca bastó por sí solo para frenar el XSS

Content Security Policy se remonta a una idea que Robert Hansen planteó hacia 2004, que el ingeniero de Mozilla Brandon Sterne convirtió después en una especificación formal a partir de 2008 aproximadamente, dando lugar a la primera Candidate Recommendation del W3C (Level 1) en 2012. El cross-site scripting (XSS) era una de las vulnerabilidades web más urgentes de la época, y quedó claro que confiar únicamente en la disciplina del desarrollador —"escapar correctamente cada salida"— no era una defensa lo bastante robusta. CSP se diseñó como un mecanismo de defensa en profundidad que permite al propio navegador imponer restricciones sobre de dónde pueden proceder los scripts.

CSP Level 2 introdujo permisos basados en nonce y hash para scripts en línea, permitiendo a los sitios autorizar código en línea específico sin recurrir a 'unsafe-inline'. Level 3 añadió después 'strict-dynamic', que confía automáticamente en los scripts cargados dinámicamente por un script ya confiable, reduciendo drásticamente la carga de mantenimiento de las listas de permisos basadas en hosts en sitios grandes.

Google ha seguido desplegando CSP estricta basada en nonce en sus propios servicios a gran escala, y ha publicado investigaciones de ese esfuerzo concluyendo que las listas de permisos basadas en hosts suelen poder eludirse, mientras que las políticas basadas en nonce o hash son mucho más efectivas en la práctica. Ese hallazgo se cita ampliamente hoy como buena práctica de CSP, y subraya que la verdadera decisión de diseño no es solo "qué valores prohibir", sino "sobre qué estrategia de lista de permisos construir" desde el principio.

Ver todas las curiosidades