El Cross-Site Scripting (XSS) permanece en el OWASP Top 10 año tras año. Content Security Policy (CSP) es un potente header HTTP que le dice a tu navegador qué recursos pueden y no pueden cargarse. En este artículo aprenderás a implementar CSP de forma efectiva, evitar errores comunes y proteger tu aplicación web contra ataques XSS.
¿Qué es Content Security Policy?
Content Security Policy es un estándar W3C que comunica al navegador mediante un header HTTP o meta tag qué fuentes son de confianza. Cuando un script, hoja de estilos o imagen de una fuente no autorizada intenta cargarse, el navegador lo bloquea automáticamente. Esto convierte a CSP en uno de los mecanismos de defensa más potentes contra XSS, clickjacking y ataques de inyección de datos.
CSP funciona con directivas como script-src, style-src, img-src y default-src, cada una especificando qué fuentes están permitidas para ese tipo de contenido. Puedes incluir dominios específicos en la lista blanca, usar nonces o hashes para scripts inline, e incluso habilitar reporting para monitorizar violaciones sin bloquear tráfico.
# Ejemplo de header CSP en Nginx
add_header Content-Security-Policy "
default-src 'self';
script-src 'self' 'nonce-abc123' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.example.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self';
";Errores comunes de CSP y cómo evitarlos
El error más común en la implementación de CSP es usar unsafe-inline y unsafe-eval para scripts. Estas directivas socavan todo el propósito de CSP, ya que dejan abiertos exactamente los vectores de ataque que CSP debería bloquear. En su lugar, usa políticas basadas en nonces o hashes que permitan scripts inline específicos.
Otro error común es una directiva script-src demasiado amplia, como incluir dominios CDN completos en la lista blanca. Si un atacante puede alojar un script malicioso en el mismo CDN, elude tu CSP por completo. Usa strict-dynamic combinado con nonces para un enfoque más robusto.
- Evita unsafe-inline y unsafe-eval — usa nonces o hashes
- Comienza con Content-Security-Policy-Report-Only para probar sin bloquear
- Usa strict-dynamic para compatibilidad con frameworks modernos
- Configura report-uri o report-to para monitoreo continuo
- No olvides frame-ancestors — reemplaza X-Frame-Options
- Implementa base-uri para prevenir el secuestro de etiqueta base
CSP en producción: monitoreo e iteración
Un CSP efectivo no es una configuración única sino un proceso continuo. Comienza con Content-Security-Policy-Report-Only para recopilar violaciones sin romper la funcionalidad. Analiza los informes, refina tu política y solo cambia a enforcement cuando estés seguro de que todas las fuentes legítimas están permitidas.
Usa herramientas como CSP Evaluator de Google o Report URI para validar tu política y agregar informes. En un pipeline CI/CD, puedes agregar tests automatizados que verifiquen que el header CSP esté presente y correcto después de cada despliegue. No olvides actualizar tu CSP cuando integres nuevos servicios de terceros.
Consejo Pro
Comienza hoy agregando un header Content-Security-Policy-Report-Only a tu aplicación. Usa un enfoque basado en nonces para scripts y configura report-to para monitorear violaciones. En una semana, tendrás suficientes datos para implementar un CSP estricto que bloquee el 90% de todos los ataques XSS.
Compartir este artículo