Qué es CSP y cómo protege tu sitio web
Autor: Redacción Domeny.ForSale Publicado
En breve: CSP, o Content Security Policy, es un mecanismo de seguridad del navegador que permite definir de dónde puede obtener recursos una página y qué código puede ejecutar. Ayuda a limitar las consecuencias de XSS, es decir, la inyección de scripts ajenos en una página, y una directiva específica también impide que el sitio se incruste en marcos no deseados. Lo más recomendable es enviar la política en una cabecera de respuesta HTTP y probarla primero sin bloquear recursos.
¿Cómo funciona CSP y frente a qué protege?
Normalmente, el navegador descarga los recursos indicados en el código de la página: scripts, hojas de estilo, imágenes o fuentes. CSP añade un conjunto de reglas. Si un recurso o la forma de ejecutar el código no cumple la política, el navegador lo bloquea y registra la infracción en las herramientas de desarrollo.
La principal aplicación de CSP es limitar los ataques XSS (cross-site scripting). Estos ataques consiguen que el script de un atacante se ejecute en el contexto de un sitio ajeno. Por ejemplo, una vulnerabilidad en un formulario de comentarios puede permitir insertar código JavaScript en lugar de texto normal. Una CSP suficientemente restrictiva puede impedir que ese código se ejecute, incluso si la aplicación lo incluye por error en la página.
CSP también ayuda a combatir el clickjacking: incrustar una página en un marco y engañar al usuario para que pulse sus elementos mediante una capa superpuesta. La directiva frame-ancestors proporciona esta protección. Definir únicamente reglas para los scripts no basta para conseguirla.
Sin embargo, CSP no corrige las vulnerabilidades de la aplicación. Sigue siendo necesario codificar correctamente los datos de salida, procesar de forma segura el contenido de los usuarios y actualizar el software. La política es una capa adicional de protección, no un sustituto de estas medidas.
¿Dónde se configura la política CSP?
La opción recomendada es la cabecera de respuesta HTTP llamada Content-Security-Policy. Puede añadirla la aplicación, el servidor WWW, un proxy inverso o una CDN. La cabecera debe llegar al navegador junto con el documento HTML al que se aplica.
Algunas reglas también pueden enviarse mediante una etiqueta meta con el atributo http-equiv="Content-Security-Policy". Esta solución tiene limitaciones: la política solo empieza a aplicarse cuando se lee la etiqueta y no admite ni el modo de informes sin bloqueo ni la directiva frame-ancestors. Si tienes acceso a la configuración de las respuestas HTTP, utiliza la cabecera.
Comprueba también si otra capa de la infraestructura ya está añadiendo CSP. Si hay varias políticas, se aplican simultáneamente: una cabecera adicional no sustituye automáticamente a la anterior. Por tanto, puede restringir aún más el funcionamiento de la página.
Directivas principales y ejemplo de cabecera
Una directiva es una regla individual de la política. Las directivas se separan con punto y coma, y después de sus nombres se indican los orígenes permitidos o valores especiales.
| Directiva | Qué controla |
|---|---|
default-src | Orígenes predeterminados para muchos tipos de recursos que no tienen una regla propia |
script-src | Orígenes de los scripts y condiciones de ejecución de JavaScript |
style-src | Orígenes de las hojas de estilo y reglas para usar estilos incrustados |
img-src | Orígenes de las imágenes |
connect-src | Conexiones iniciadas, entre otros medios, mediante fetch y WebSocket |
object-src | Objetos incrustados mediante elementos como object |
base-uri | Direcciones permitidas en el elemento base |
frame-ancestors | Páginas que pueden incrustar el documento en un marco |
Para un sitio sencillo que utilice únicamente archivos propios, este puede ser un punto de partida:
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
El valor 'self' significa el mismo origen: deben coincidir el esquema, el nombre del host y el puerto. 'none' no permite ningún origen. El ejemplo anterior prohíbe incrustar la página en marcos y bloquea, entre otras cosas, los scripts escritos directamente en HTML y los atributos de eventos, como onclick.
No es una configuración universal. Si la página utiliza un sistema externo de pagos, herramientas de analítica o fuentes externas, hay que identificar los orígenes necesarios y añadirlos a las directivas correspondientes. default-src no sustituye a todas las reglas: por ejemplo, frame-ancestors requiere una declaración independiente.
¿Cómo implementar CSP sin bloquear la página por accidente?
Lo más seguro es conocer primero las dependencias reales del sitio y activar el bloqueo después.
- Haz un inventario de recursos e integraciones. Incluye no solo la página de inicio, sino también el inicio de sesión, los formularios, los pagos y el panel de usuario.
- Configura la cabecera
Content-Security-Policy-Report-Only. El navegador evaluará la política propuesta e informará de las infracciones, pero no bloqueará los recursos que la incumplan. La recopilación automática de informes requiere configurar además el mecanismo de informes y un receptor. - Prueba los recorridos completos del usuario. Revisa la consola y el panel de red del navegador. Distingue los recursos necesarios de las integraciones prescindibles y las solicitudes procedentes de extensiones del navegador.
- Corrige las reglas y el código. Tras las pruebas, pasa la política validada a
Content-Security-Policyy supervisa los errores después de implementarla.
No elimines las advertencias añadiendo sin criterio *, 'unsafe-inline' o 'unsafe-eval'. Estas excepciones pueden debilitar considerablemente la protección. Para los scripts incrustados que sean necesarios, puedes utilizar un nonce —un valor impredecible generado para cada respuesta— o un hash, es decir, una huella del contenido de un script concreto. El nonce debe coincidir en la cabecera y en el elemento del script; un valor fijo pegado en la configuración no cumple esta función.
Empieza con una política en modo de informes en un entorno de pruebas y recorre todo el proceso, desde la entrada en la página hasta el envío de un formulario o la finalización de una compra. Así sabrás qué permisos son realmente necesarios antes de que CSP empiece a bloquear recursos a los usuarios.
Consulta también: ¿Qué es MCP?
Lee también
