Una Content Security Policy (CSP) es una cabecera de respuesta HTTP que indica al navegador desde qué orígenes puede una página cargar scripts, estilos, imágenes y conexiones. Todo lo que no esté en esa lista de permitidos se bloquea antes de ejecutarse. Estandarizada por el W3C, la CSP es la principal defensa nativa del navegador frente al cross-site scripting (XSS) y la inyección de scripts.
TL;DR: qué es la CSP
- La CSP funciona declarando una lista de permitidos por tipo de recurso (script-src, img-src, connect-src, etc.). Cualquier cosa que no esté en la lista es bloqueada por el navegador antes de ejecutarse.
- Se envía como cabecera de respuesta HTTP o como etiqueta
<meta>en el<head>de la página, y el modo Report-Only permite probar una política sin romper el sitio. - La CSP es una base, no una defensa completa. Controla desde dónde se carga un script, no lo que el script hace una vez que se ejecuta, así que un dominio comprometido pero permitido sigue ejecutándose.
- La CSP por sí sola no basta para cumplir con PCI DSS 4.0.1. El requisito §6.4.3 exige inventario y autorización de scripts; el §11.6.1 exige detección de manipulaciones. Ambos van más allá de lo que la CSP puede imponer, especialmente frente a un dominio permitido que resulta comprometido, como en el incidente de Polyfill.io de 2024.
¿Qué significa CSP?
CSP significa Content Security Policy (Política de Seguridad de Contenidos). Es una cabecera de respuesta HTTP (también configurable mediante una etiqueta <meta> en el <head> de la página) que indica al navegador qué fuentes de scripts, estilos, imágenes y conexiones puede cargar una página, y bloquea todo lo que no esté en esa lista de permitidos antes de que se ejecute.
Entender la Política de Seguridad de Contenidos (CSP)
La Política de Seguridad de Contenidos (CSP) es una función de seguridad del navegador que se implementó para mitigar ciertos tipos de ataques basados en el navegador, como el cross-site scripting. La CSP fue estandarizada por el World Wide Web Consortium (W3C) en la especificación CSP Level 3; permite que un sitio web envíe un conjunto de reglas (mediante cabeceras de respuesta HTTP o etiquetas <meta> dentro del <head> del HTML) que indican al navegador qué fuentes de contenido están permitidas.
Estas reglas, llamadas directivas, especifican los orígenes aprobados para scripts, imágenes, estilos, iframes y más. El propósito principal de usar la CSP es tener control total sobre desde dónde se cargan los scripts, además de controlar qué scripts tiene permitido ejecutar una página, intentando así evitar que se ejecuten scripts inyectados o no autorizados.
Por ejemplo, una directiva CSP podría indicar que los scripts solo deben cargarse desde el propio dominio del sitio (usando ‘self’), o desde dominios de confianza concretos. El navegador bloqueará entonces cualquier archivo de script o script en línea que no proceda de una fuente permitida. Esto defiende frente a ataques XSS, en los que un atacante intenta inyectar etiquetas <script> o código malicioso en un sitio. Hoy en día, la mayoría de los navegadores también admiten el modo ‘Report-only’ de la CSP. Esto permite a los desarrolladores probar una política de forma segura. Cuando está activado, las violaciones de la política se registran en un endpoint de informes en lugar de bloquearse de inmediato. Esto es una buena práctica al implementar la CSP por primera vez.
Cómo funciona la Política de Seguridad de Contenidos (CSP)
Una Política de Seguridad de Contenidos se entrega al navegador mediante la cabecera de respuesta HTTP llamada Content-Security-Policy, o mediante una etiqueta meta en el <head> del HTML. La política consta de directivas separadas por punto y coma, y cada directiva controla un tipo de recurso específico.
- ‘script-src’ self: permite scripts solo desde el mismo origen. Cualquier
<script>de otro dominio (o código de script en línea) es bloqueado por el navegador. - ‘connect-src’ self https://api.domain.com : permite llamadas AJAX/XHR/fetch únicamente al mismo sitio, o al dominio de confianza api.domain.com. Esto evita que el código malicioso exfiltre datos desde el sitio hacia servidores desconocidos.
- img-src ‘self’ data: se puede usar para cargar imágenes solo desde el mismo sitio y bloquear imágenes externas, lo que ayuda a prevenir fugas de datos mediante solicitudes de imágenes.
Nonces y hashes de CSP
La CSP también admite mecanismos avanzados como los nonces (‘nonce-abc123’) y los hashes (‘sha256-xyz…’). Estos permiten que los scripts en línea se ejecuten de forma segura al demostrar criptográficamente su integridad. En lugar de prohibir todo el código en línea, los desarrolladores pueden autorizar de forma selectiva scripts concretos. Esto mejora la flexibilidad sin sacrificar la seguridad.
Existen multitud de otras directivas que se pueden usar para otros tipos de datos, como medios, fuentes, iframes, etc., pero la idea central de usar una Política de Seguridad de Contenidos es crear una lista de permitidos de fuentes de confianza. Cuando el navegador carga una página y decide qué contenido cargar, primero consulta la CSP y aplica estas reglas en cada carga. Cualquier script o recurso que cargue esta política no se cargará. Para una guía de implementación detallada, consulta la hoja de referencia OWASP sobre CSP.
Directivas CSP comunes y su propósito
| Directiva | Propósito | Caso de uso típico |
|---|---|---|
default-src | Establece una política base para todos los recursos cuando no se aplica ninguna otra regla. | Empieza de forma estricta: default-src 'none'; |
script-src | Controla qué fuentes de JavaScript están permitidas. | Permite 'self', CDNs, o usa scripts basados en nonce/hash. |
style-src | Limita desde dónde se puede cargar CSS. | Usa 'self'; evita 'unsafe-inline' cuando sea posible. |
img-src | Define fuentes de imagen de confianza. | Evita fugas de datos mediante llamadas a imágenes externas. |
connect-src | Restringe los destinos de AJAX, fetch y WebSocket. | Bloquea la exfiltración de datos a dominios desconocidos. |
frame-ancestors | Especifica qué sitios pueden incrustar tus páginas en iframes. | Evita el clickjacking: frame-ancestors 'none'; |
report-uri / report-to | Define a dónde se envían los informes de violación de la CSP. | Registra y analiza las infracciones de la CSP para ajustar la política. |
Ejemplos de cabeceras CSP que puedes copiar hoy mismo
A continuación tienes puntos de partida listos para copiar y pegar para los despliegues de CSP más comunes. Prueba primero en modo Content-Security-Policy-Report-Only, observa los informes para detectar scripts legítimos que se bloquearían y, después, pasa al modo de aplicación.
1. Política inicial estricta (denegar por defecto + lista de permitidos)
Content-Security-Policy:
default-src 'none';
script-src 'self' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
connect-src 'self' https://api.example.com;
font-src 'self' https://fonts.gstatic.com;
form-action 'self';
frame-ancestors 'none';
base-uri 'self';
upgrade-insecure-requests;
report-uri /csp-report;
report-to csp-endpoint;2. Scripts en línea basados en nonce
Content-Security-Policy: script-src 'nonce-r@nd0mNonceHere' 'strict-dynamic';<script nonce="r@nd0mNonceHere">
// this script executes; anything without the matching nonce does not
</script>3. Scripts en línea basados en hash
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8=';Genera el hash con: echo -n "your inline script contents" | openssl dgst -sha256 -binary | openssl base64
4. Modo Report-Only (sin bloqueo, solo monitorización)
Content-Security-Policy-Report-Only:
default-src 'self';
script-src 'self' https://cdn.example.com;
report-to csp-endpoint;5. Endpoint Report-To (informes modernos)
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
Content-Security-Policy: default-src 'self'; report-to csp-endpoint;6. Payload de ejemplo de una violación
{
"csp-report": {
"document-uri": "https://example.com/checkout",
"referrer": "",
"violated-directive": "script-src 'self'",
"effective-directive": "script-src",
"original-policy": "default-src 'self'; report-uri /csp-report",
"disposition": "enforce",
"blocked-uri": "https://malicious.example/skimmer.js",
"line-number": 42,
"source-file": "https://example.com/checkout",
"status-code": 200,
"script-sample": ""
}
}7. Middleware de Express.js
app.use((req, res, next) => {
res.setHeader(
"Content-Security-Policy",
"default-src 'self'; script-src 'self' https://cdn.example.com; report-uri /csp-report",
);
next();
});
app.post("/csp-report", express.json({ type: "application/csp-report" }), (req, res) => {
console.log("CSP violation", req.body);
res.sendStatus(204);
});8. Cloudflare Worker
export default {
async fetch(request, env) {
const response = await fetch(request);
const headers = new Headers(response.headers);
headers.set(
"Content-Security-Policy",
"default-src 'self'; script-src 'self' https://cdn.example.com; report-to csp-endpoint",
);
return new Response(response.body, { status: response.status, headers });
},
};Referencia ampliada de directivas
Más allá de las siete directivas anteriores, la CSP define varias más que aparecen en el hardening en producción:
| Directiva | Propósito |
|---|---|
strict-dynamic | Confía en los scripts cargados por un script ya de confianza (nonce o hash). Simplifica la carga desde CDN. |
upgrade-insecure-requests | Actualiza automáticamente los subrecursos http: a https:. Elimina los avisos de contenido mixto. |
require-trusted-types-for | Aplica Trusted Types en sinks peligrosos del DOM (por ejemplo, innerHTML, Function()). |
sandbox | Aplica un sandboxing estilo iframe a toda la página. Es potente y requiere pruebas cuidadosas. |
form-action | Restringe a dónde pueden enviarse (POST) los formularios <form>. Bloquea redirecciones de phishing. |
base-uri | Fija el elemento <base> a orígenes específicos. Evita ataques de inyección de <base>. |
manifest-src | Controla desde dónde puede cargarse el manifest de una web-app. |
media-src | Restringe las fuentes de <audio> y <video>. |
object-src | Restringe <object>, <embed>, <applet>. Fíjalo en 'none' en sitios modernos. |
worker-src | Restringe las fuentes de Web Worker y Service Worker. |
Ten cuidado con 'unsafe-inline' y 'unsafe-eval'. Ambas siguen siendo compatibles, pero desactivan la mayor parte de la protección de la CSP frente a XSS. 'strict-dynamic' combinado con nonces es la vía moderna de sustitución.
Compruébalo en tu propio sitio
La CSP es una capa de defensa del lado del cliente, y una capa crítica para el cumplimiento de PCI DSS 4.0.1. Pero la CSP por sí sola no detuvo el ataque a Polyfill.io en 2024, porque el dominio comprometido estaba en la lista de permitidos. cside añade inventario de scripts y análisis de payloads por encima de la CSP para cerrar esa brecha. Disponible en el plan gratuito.
¿Cómo previene la CSP los ataques basados en el navegador?
Mitigación de ataques XSS
En un ataque de cross-site scripting, o ataque XSS, un atacante suele encontrar una forma de inyectar y ejecutar código JavaScript malicioso en tu página (por ejemplo, a través de una entrada no saneada). Por defecto, una CSP bloqueará la ejecución de cualquier script en línea en la página, a menos que una directiva de la política lo permita explícitamente. Esto significa que, si un atacante inyecta algo como <script>evilCode()</script> en una página, no se ejecutará (¡a menos que ‘unsafe-inline’ esté prohibido en la CSP!)
Bloqueo de scripts de terceros no autorizados
Muchos sitios tienen scripts de terceros para cosas como analítica, seguimiento de usuarios y publicidad. Con una CSP, los propietarios del sitio pueden limitar qué sitios externos pueden entregar scripts. Por ejemplo, si solo quieres servir contenido desde analytics._example_.com y nada más de example.com, la directiva script-src de la CSP de tu sitio puede permitir explícitamente solo eso.
Prevención de la exfiltración de datos
Como se ha mencionado antes, una CSP puede restringir acciones en una página que se pueden usar para impedir que código JavaScript malicioso envíe datos a un dominio controlado por un atacante. Usar la directiva connect-src bloquea las solicitudes de red a servidores no autorizados, y se puede combinar con la directiva form-action para garantizar que los datos solo se envían a tu dominio.
Aplicar prácticas de navegación segura
Una CSP tiene directivas para imponer comportamientos seguros que mejoran la seguridad general de tu sitio.
- Un ejemplo es
upgrade-insecure-requests, que obliga al navegador a cargar todos los recursos por HTTPS, evitando problemas de contenido mixto e inseguro. - Otra directiva es
frame-ancestors, que puede prevenir ataques de clickjacking impidiendo que tu página se incruste en un marco controlado por un atacante.
En conjunto, estas políticas dan como resultado una base sólida del lado del cliente para las aplicaciones web modernas.
Limitaciones de seguridad de la CSP
Usar una Política de Seguridad de Contenidos ofrece una protección sólida, pero no es la solución definitiva para tu sitio, como se destaca en nuestra entrada «Por qué la Política de Seguridad de Contenidos no funciona».
Las políticas pueden desviarse con el tiempo, y las listas de permitidos no inspeccionan el comportamiento del código. Cada navegador principal implementa la CSP de forma ligeramente distinta. Chrome, Firefox, Safari y Edge admiten todos CSP Level 3; el comportamiento de los informes y los formatos de las violaciones pueden variar. Para validar y mantener tu política, pruébala regularmente con las herramientas de desarrollador del navegador y con escáneres automatizados como Mozilla Observatory o SecurityHeaders.io.
Combinar una CSP con un capa activa de seguridad del lado del cliente como cside, que añade inspección y bloqueo en tiempo real a los scripts de terceros de tu sitio, te ofrece una gran capa de defensa y tranquilidad para tus clientes. Desde el punto de vista de la gobernanza, documentar las actualizaciones de la CSP y monitorizar los informes de violaciones mejora la auditabilidad y el cumplimiento a largo plazo con marcos como ISO 27001 y OWASP ASVS.
¿La CSP sirve para cumplir con PCI DSS 6.4.3?
Según el Requisito 6.4.3 de PCI DSS 4.0.1, los comerciantes deben demostrar que cada script del lado del cliente está autorizado y probar su integridad. La CSP y SRI te acercan parte del camino. La CSP limita qué dominios pueden cargar scripts, y SRI comprueba que el código de un archivo no haya cambiado. Pero juntas son una solución estática para un problema dinámico. Los scripts dinámicos se actualizan y los hashes se rompen. El mantenimiento manual de las listas de la CSP es casi imposible.
La mayoría de los sitios modernos usan scripts de terceros dinámicos, por lo que estos controles se degradan rápidamente. Este enfoque, por lo general, no llega a la evidencia requerida para PCI 6.4.3.
Un ejemplo de Content Security Policy (CSP): cuando una CSP estricta rompió producción
El día que el checkout dejó de funcionar: cómo una CSP estricta rompió la producción
Todo empezó con un despliegue nuevo de lo más normal. Nada especial, solo una nueva Política de Seguridad de Contenidos para hacer más seguro un comercio electrónico e impedir que los atacantes colaran código malicioso.
Se configuró el limpio default-src ‘none’ sin pruebas previas. Así, en el momento en que se activó la CSP, el sitio web bloqueó servicios que realmente necesitaba. La analítica dejó de funcionar y, lo peor de todo, se bloqueó el sistema de pago. Los clientes no podían completar sus pedidos y el sistema de checkout se rompió. Los desarrolladores se pusieron a trabajar, cambiaron la cabecera a Content-Security-Policy-Report-Only y recopilaron los registros de violaciones. A partir de ahí, construyeron una lista de permitidos (script-src ‘self’ https://pay.examplecase.com) con todos los servicios que la tienda necesitaba para funcionar correctamente.
Tras refinar la CSP, el equipo desplegó sin ninguna interrupción. Este tipo de descuido es un problema habitual cuando los equipos gestionan la CSP internamente. Olvidar añadir a la lista de permitidos un nuevo script de marketing, errores técnicos de configuración, o problemas con scripts dinámicos que rompen los protocolos de hashing hacen que gestionar la CSP a gran escala sea una pesadilla.
Genera y mantén tu CSP automáticamente con cside
Escribir y mantener a mano una Política de Seguridad de Contenidos es donde la mayoría de los equipos se atascan: cada nueva etiqueta de marketing, script de terceros dinámico o cambio de endpoint de un proveedor puede romper la política o ampliar silenciosamente la lista de permitidos. cside elimina ese trabajo manual.
cside observa los scripts que tu sitio carga realmente y genera por ti una cabecera CSP lista para desplegar a partir de sesiones reales del navegador, y la mantiene actualizada a medida que esos scripts cambian, para que no tengas que perseguir a mano las actualizaciones de la lista de permitidos. Obtienes una Política de Seguridad de Contenidos que refleja lo que tu sitio ejecuta de verdad, además del inventario de scripts y la detección de manipulaciones que la CSP por sí sola no puede ofrecer para los requisitos §6.4.3 y §11.6.1 de PCI DSS 4.0.1.
No hay nada que programar. Regístrate en el plan gratuito, añade tu dominio y cside empezará a generar tu CSP a partir del tráfico real. Explora la solución de gestión de CSP o descubre cómo cside cubre las lagunas que deja una CSP.
