Content Security Policy (CSP): cómo configurarla

Q: ¿Qué significa unsafe-inline y por qué es un problema?

'unsafe-inline' permite ejecutar cualquier script escrito directamente en el HTML, y eso es justo lo que hace un ataque XSS: colar código en la página. Con esa palabra en script-src, la CSP sigue controlando los dominios externos, pero pierde buena parte de su protección. La alternativa son los nonces o los hashes, que autorizan solo los scripts que has puesto tú.

Por qué importa

Es la principal defensa contra el cross-site scripting (XSS): ataques en los que alguien consigue colar su propio JavaScript en tu página, por ejemplo a través de un comentario, un plugin vulnerable o un script de terceros comprometido. Ese código puede robar sesiones, cambiar el contenido o capturar lo que tus clientes escriben en los formularios. Con una buena CSP, aunque el código llegue a la página, el navegador se niega a ejecutarlo o a cargar recursos de dominios que no has autorizado.

Es la cabecera de seguridad más potente y también la más delicada: una política mal hecha bloquea tu propia analítica, la pasarela de pago o el chat. Por eso se empieza siempre en modo de prueba.

Cómo lo comprueba Posiciona

Leemos la cabecera Content-Security-Policy de la página. Sin CSP, la puntuación es 60: es un refuerzo que la mayoría de webs no tiene, no un fallo. Si solo tienes la versión de prueba (Content-Security-Policy-Report-Only), 70: avisa pero no bloquea. Con una CSP activa que incluye 'unsafe-inline' y 'unsafe-eval' (en cualquier directiva), 75; con solo uno de los dos, 85; sin ninguno, 100. No vemos una CSP declarada con una etiqueta <meta>, ni evaluamos si cada directiva es lo bastante estricta.

En la nota de Seguridad esta comprobación cuenta como “recomendable” (peso 2 de 5).

Cómo solucionarlo

Haz inventario de lo que carga tu web: tus propios ficheros, analítica, píxeles de publicidad, pasarela de pago, chat, vídeos y fuentes. La pestaña Red de las herramientas de desarrollo (F12) te lo muestra.
Escribe una primera política y envíala como Content-Security-Policy-Report-Only. En este modo el navegador no bloquea nada: solo avisa en la consola y, si configuras una dirección de informes, te envía cada infracción.
Recorre toda la web (fichas de producto, carrito, pago, formularios) y añade a la política los dominios legítimos que aparezcan en los avisos.
Cuando pase varios días sin avisos inesperados, cambia el nombre de la cabecera a Content-Security-Policy para que se aplique de verdad.
Después, trabaja para quitar 'unsafe-inline' de script-src: mueve los scripts incrustados a ficheros o autorízalos con nonces (un valor aleatorio distinto en cada carga) o con hashes. Evita 'unsafe-eval', que permite ejecutar texto como código.
Incluye desde el principio tres directivas de poco riesgo y mucho valor: object-src 'none', base-uri 'self' y frame-ancestors 'self', que además hace el trabajo de X-Frame-Options.

Punto de partida en modo prueba (adáptalo a tu web)Cabecera HTTP

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

NginxNginx

add_header Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

En WordPress

WordPress, los constructores visuales y muchos plugins usan scripts incrustados, así que una CSP sin 'unsafe-inline' es difícil de conseguir. Un objetivo realista es una política con la lista de dominios bien cerrada, aunque de momento mantenga 'unsafe-inline'.
Puedes enviarla desde el .htaccess (en hostings con Apache) o con un plugin de cabeceras de seguridad que permita editar la CSP. Pruébala primero en modo Report-Only y vacía la caché del sitio después de cada cambio.

En Shopify

En Shopify no puedes añadir cabeceras HTTP desde el tema, así que la CSP depende de la plataforma y esta comprobación queda en buena parte fuera de tu control.
Lo que sí reduce el riesgo de XSS es limitar los scripts: desinstala las apps que no uses, borra del tema el código que dejaron y no pegues en theme.liquid scripts de origen dudoso.

Preguntas frecuentes

¿Por qué mi CSP bloquea Google Analytics o el píxel de Meta?

Porque esas herramientas cargan scripts y envían datos a varios dominios, y cada uno tiene que estar autorizado en la directiva adecuada: script-src para los scripts, connect-src para los envíos de datos e img-src para los píxeles de imagen. Los proveedores suelen documentar qué dominios necesita su herramienta; el modo Report-Only te dirá exactamente cuáles faltan en tu política.

¿Qué significa unsafe-inline y por qué es un problema?

'unsafe-inline' permite ejecutar cualquier script escrito directamente en el HTML, y eso es justo lo que hace un ataque XSS: colar código en la página. Con esa palabra en script-src, la CSP sigue controlando los dominios externos, pero pierde buena parte de su protección. La alternativa son los nonces o los hashes, que autorizan solo los scripts que has puesto tú.