¿Qué es un Creador de cabeceras CSP?
Content Security Policy (CSP) es un patrón de seguridad de los navegadores que ayuda a prevenir el uso de cross-site scripting (XSS), clicjacking y otros ataques de inyección de código al definir qué fuentes de contenido se pueden cargar en una página web. Un Creador de cabeceras CSP ofrece una interfaz visual para construir cadenas de cabecera CSP válidas sin necesidad de memorizar la sintaxis de las directivas. Usted activa o desactiva directivas, selecciona valores de fuente permitidos como 'self', 'unsafe-inline' o dominios específicos, y la herramienta genera la string correcta de la cabecera en tiempo real. También advierte sobre configuraciones conflictivas o inseguras, como combinar 'unsafe-inline' con 'strict-dynamic' o usar 'unsafe-eval', que rehabilita la ejecución peligrosa de JavaScript.
Cómo usar el Creador de cabeceras CSP
- 1Activa las directivas necesarias. Comience con 'default-src' como política de fallback básica.
- 2Para cada directiva activada, haga clic en los valores de fuente que desea permitir (por ejemplo, 'self', https:, fecha:). Los valores seleccionados se destacan en azul.
- 3Añada dominios personalizados que se escriben en el campo de entrada y presionando Enter o haciendo clic en Add (por ejemplo, https://cdn.example.com)._
- 4Revise las advertencias amarillas que se muestran, indican combinaciones de directivas conflictivas o inseguras.
- 5Copie la cadena de cabecera CSP o la meta tag HTML generada usando los botones de copia.
- 6Opcionalmente, indique una URL de prueba para comprobar si se le permite o bloquearía la política actual.
Casos de uso comunes
Refuerzo de la seguridad de aplicaciones web
Crea una política CSP estricta para su sitio web en producción para bloquear scripts en línea, restringir los orígenes de recursos y prevenir ataques XSS. Comience con una default-src 'none'strictiva y permita selectivamente sólo las fuentes necesarias para la aplicación.
Migración gradual a CSP
Al añadir CSP a una aplicación existente, utilice el creador para experimentar diferentes combinaciones de directivas, identificar las fuentes exigidas por la aplicación y hacer que la política sea más rigurosa gradualmente sin comprometer la funcionalidad.
Depuración de violaciones de CSP
Cuando la consola del navegador muestra errores de violación de CSP, utilice el recurso de prueba de URL para comprobar si la URL de un recurso específico está permitida por la política actual y ajuste las directivas como sea necesario.
Generación de etiquetas para sitios estáticos
En sitios estáticos alojados en plataformas en las que no es posible definir cabeceras HTTP, copie la meta tag HTML generada para incorporar la política CSP directamente a la sección head del documento HTML.
Preguntas frecuentes
¿Cuál es la diferencia entre proporcionar CSP por cabecera HTTP y por meta tag?
Los dos métodos proporcionan la misma política al navegador. La cabecera HTTP (Content-Security-Policy) está definida por el servidor y acepta todas las directivas. La meta tag HTML (meta http-equiv Content-Security-Policy) es incorporada a la página y funciona con la mayoría de las directivas, pero no acepta frame-ancestors, report-uri ni sandbox. En general, la cabecera HTTP es preferible porque se aplica antes del análisis de HTML de la página.
¿Qué 'strict-dynamic' hace y por qué ignora 'unsafe-inline'?
'strict-dynamic' instruye al navegador a confiar en scripts cargados por scripts ya confiables, por medio de nonce o hash, incluso si vienen de nuevos orígenes. Cuando se encuentra el strict-dynamic, el navegador ignora las «unsafe-inline» y las listas de hosts permitidas en script-src. Ese comportamiento es intencional: viabiliza un abordaje basado en nonce, en el cual sólo scripts con nonce explícito son ejecutados y pueden cargar otros scripts dinamicamente.
¿Debo definir siempre default-src?
Sí. default-src funciona como fallback para cualquier directiva no definida explícitamente. Si define script-src, pero no style-src, el navegador usará default-src para los estilos. Establecer default-src como 'none' o 'self'_ establece una base segura, que puede ser flexibilizada para cada directiva según sea necesario.
¿Por qué 'unsafe-eval' es peligroso?
'unsafe-eval' permite el uso de eval(), new Function(), setTimeout con cadenas y otras API de ejecución dinámica de código. Estos recursos son vectores comunes de ataques XSS porque permiten que un invasor ejecute JavaScript arbitrario si puede inyectar una cadena en la aplicación. Evite 'unsafe-eval', a menos que sea absolutamente necesario para su framework o sus bibliotecas.
¿Esta herramienta valida la cabecera CSP de acuerdo con la especificación oficial?
La herramienta genera encabezados CSP sintaticamente correctos y alerta sobre combinaciones comunes que sean conflictivos o inseguras. Sin embargo, no ejecuta una validación completa de la especificación W3C. Antes de implantar en producción, prueba su CSP en un entorno de staging usando la consola de desarrollador del navegador para identificar violaciones.
¿Los datos de la política se envían a un servidor?
No. La creación, validación y pruebas de política se realizan localmente en el navegador.