Qué es CSP (Content Security Policy) y cómo configurarlo

Si alguna vez ejecutó un análisis de seguridad en su sitio, es muy probable que se haya topado con un ítem llamado Content Security Policy — o simplemente CSP. Es uno de los hallazgos más comunes en los informes de seguridad, y también uno de los más postergados: suena complicado, suena riesgoso, y "el sitio ya funciona, para qué tocarlo".

El punto es que CSP resuelve un problema real, y lo resuelve bien. Vale la pena entender qué hace antes de decidir si vale la pena implementarlo (spoiler: vale la pena).

Qué es, en la práctica

Content Security Policy es un header HTTP que su servidor envía junto con cada página, indicándole al navegador desde dónde tiene permiso para cargar cosas: scripts, imágenes, fuentes, estilos, iframes. Cualquier cosa que no esté en la lista, el navegador se niega a cargarla — incluso si el código malicioso ya fue inyectado en la página de alguna forma.

Esa es la diferencia que importa: CSP no impide que alguien inyecte un script malicioso en su HTML (eso es trabajo de la validación de entrada, el escapado, etc.). Lo que hace es garantizar que, incluso si la inyección ocurre, el navegador se niegue a ejecutar ese script, porque no vino de un origen autorizado.

Qué ataques mitiga una CSP

• XSS (Cross-Site Scripting) — el principal. Si un atacante logra inyectar un <script> malicioso en un campo de comentarios, una URL o cualquier entrada que termine renderizada sin escapar, una CSP bien configurada bloquea la ejecución de ese script.
• Clickjacking — a través de la directiva frame-ancestors, que impide que su sitio se cargue dentro de un <iframe> invisible en otra página, usado para engañar los clics del usuario.
• Inyección de datos — restringe hacia dónde pueden enviar datos los formularios (form-action) y desde dónde el sitio puede cargar recursos, dificultando la exfiltración de datos mediante scripts inyectados.
• Ataques de base tag — la directiva base-uri impide que un atacante reescriba la URL base de la página para redirigir recursos relativos hacia un dominio malicioso.

Las directivas que más importan

Una CSP es una lista de directivas, cada una controlando un tipo de recurso:

Una política mínima y razonable para la mayoría de los sitios institucionales restringe todo a 'self' (el propio dominio) y niega explícitamente lo que no debería existir:

default-src 'self';
object-src 'none';
frame-ancestors 'self';
base-uri 'self';

Por qué tanta gente evita implementarlo

El miedo más común es razonable: una CSP mal configurada rompe el sitio — bloquea un script de analítica, una fuente externa, un widget de terceros — y nadie se da cuenta hasta que un cliente se queja. Por eso existe el modo report-only: usted publica la política sin que bloquee nada realmente, solo reporta lo que habría sido bloqueado. Eso da visibilidad real de qué orígenes usa realmente su sitio, antes de aplicar la política de verdad.

El camino seguro, resumido:

1. Mapee los recursos externos que el sitio realmente carga (analítica, fuentes, CDNs, widgets).
2. Empiece en report-only, déjelo correr algunos días monitoreando los reportes de violación.
3. Ajuste las directivas según lo que aparezca — normalmente es una lista mucho más corta de lo que se imagina.
4. Aplíquela de verdad, primero en staging, después en producción.
5. Vuelva a ejecutar un análisis de seguridad para confirmar que la política está presente y bien estructurada.

Errores comunes

• Usar 'unsafe-inline' sin necesidad — habilita cualquier script inline, lo que anula buena parte de la protección contra XSS. Solo debería existir si el sitio realmente depende de scripts inline dinámicos (algunos frameworks con renderizado en el servidor a veces lo necesitan, pero siempre vale evaluarlo caso por caso).
• Olvidar object-src 'none' — incluso sitios que no usan Flash ni plugins dejan esta directiva afuera, abriendo una puerta innecesaria.
• Copiar la CSP de otro sitio — cada sitio tiene recursos diferentes. Una política copiada de otro proyecto tiende a ser demasiado permisiva (no protege nada) o demasiado restrictiva (rompe funcionalidades).
• Declararla y olvidarse — la CSP necesita acompañar los cambios del sitio. ¿Agregó un nuevo widget de terceros? La política necesita saberlo.

El resultado práctico

Un sitio con una CSP bien configurada no queda "más lento" ni "más difícil de mantener" — el header es solo una línea de configuración en el servidor. Lo que cambia es que, si algún día una vulnerabilidad de inyección pasa desapercibida en algún otro punto del sistema, la CSP es la capa que impide que se convierta en un ataque real contra quien visita el sitio.

Ese tipo de control — junto con otros headers de seguridad, DNS bien configurado y ausencia de secretos expuestos — es lo que compone el puntaje de seguridad de un sitio. Si quiere saber exactamente dónde está su sitio hoy, sin conjeturas, puede ejecutar un análisis completo y recibir un plan de corrección priorizado.