CSP: qué es y cómo protege un sitio web

Una Content Security Policy, o CSP, es un conjunto de instrucciones que un sitio entrega al navegador para limitar qué recursos puede cargar y qué acciones puede ejecutar. La política suele viajar en el encabezado HTTP Content-Security-Policy y se aplica a la respuesta de la página.

También puede servirte: Qué es CORS y por qué el navegador bloquea una API

Su objetivo principal es reducir el impacto de ciertos ataques, en especial cuando un sitio termina interpretando como código un contenido que no debía ejecutarse. Una CSP no demuestra que la aplicación sea segura: agrega una capa que puede bloquear scripts, imágenes, marcos o conexiones que no estén permitidos.

La política se escribe con directivas separadas por punto y coma. Por ejemplo, default-src 'self' establece un origen predeterminado y img-src puede abrir una excepción para imágenes. Cada directiva debe reflejar los recursos reales que la aplicación necesita, porque una lista demasiado amplia pierde capacidad de protección.

Las directivas de recursos controlan fuentes de scripts, hojas de estilo, imágenes, fuentes, conexiones y marcos. default-src funciona como respaldo para varias directivas de carga, mientras que script-src, img-src o connect-src permiten especificar reglas más precisas. El navegador evalúa la política antes de completar cada carga.

Una CSP también puede restringir quién embebe una página con frame-ancestors, impedir objetos con object-src 'none' o pedir que las solicitudes inseguras se actualicen a HTTPS con upgrade-insecure-requests. Son controles distintos: agregar una directiva para marcos no autoriza automáticamente scripts ni conexiones.

Los navegadores informan una violación cuando un recurso no cumple la política. Ese reporte ayuda a descubrir dependencias que el equipo olvidó documentar, pero no conviene convertir cada dominio observado en una excepción. Una dependencia de terceros debe tener una razón concreta, una fuente confiable y una revisión cuando cambie.

El encabezado Content-Security-Policy-Report-Only permite observar qué bloquearía una política sin aplicarla todavía. Es útil para recopilar violaciones y corregir incompatibilidades antes de pasar a enforcement. Una política report-only no reemplaza a la política activa ni se puede entregar mediante una etiqueta meta.

Para controlar scripts, MDN describe las políticas estrictas basadas en nonce o hash. Un nonce aleatorio por respuesta autoriza un script concreto; un hash autoriza exactamente un contenido conocido. Si el script cambia, el hash debe recalcularse. Ambos enfoques reducen la dependencia de listas grandes de dominios permitidos.

Una CSP no reemplaza el escape de salida, la sanitización, la autorización, HTTPS ni una revisión de dependencias. Tampoco convierte en confiable un script de terceros por el solo hecho de estar en una allowlist. La defensa funciona mejor cuando la política coincide con el código real y las otras capas siguen activas.

Inventariá scripts, estilos, imágenes, fuentes, conexiones y marcos que una página necesita en producción. Separá recursos propios de terceros y anotá qué ruta los usa. Después redactá una política mínima con default-src y directivas específicas, en lugar de copiar una lista general que no responde a tu arquitectura.

Publicá primero una versión report-only y revisá los reportes con ejemplos reproducibles. Eliminá excepciones que ya no existan, reemplazá inline scripts por nonces o hashes cuando sea posible y comprobá formularios, workers, iframes y navegaciones. Una política que rompe una función legítima también necesita corrección antes de activarse.

Por último, pasá a Content-Security-Policy activa con una estrategia de cambio controlado. Conservá una prueba que cargue las rutas críticas, medí violaciones después del despliegue y documentá quién puede modificar la política. El objetivo no es que el encabezado sea largo: es que el navegador bloquee comportamientos inesperados sin esconder fallos de la aplicación.