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.

Consejos

  • 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.

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.

→ Leer curiosidades relacionadas

→ Ver todas las curiosidades

Más herramientas en esta categoría