Defaults.Exposed › Soluciones › Content-Security-Policy (CSP)

Cómo arreglar Content-Security-Policy (CSP)

Una Política de Seguridad de Contenido es una regla de seguridad que tu web entrega al navegador de cada visitante, indicándole exactamente qué código tiene permiso para ejecutarse. Sin ella, si algo malicioso aterriza alguna vez en una página —a través de un cuadro de comentarios, un complemento pirateado o un script de terceros—, el navegador lo ejecutará sin restricciones, incluido el código que copia en silencio los números de tarjeta y las contraseñas de tus clientes mientras los escriben, con el candado aún visible.

En resumen, para tu negocio: Si tu web es manipulada alguna vez, el código malicioso puede leer los datos de tarjeta y de inicio de sesión de tus clientes directamente de tu propio pago mientras todo parece completamente normal, dejándote con devoluciones de cargo, reclamaciones de fraude, una brecha de datos notificable y un suspenso en la comprobación que los equipos de seguridad de los clientes mayores usan para atascar o tumbar un acuerdo.

Lo que esto te puede costar

• Código oculto se cuela en una de tus páginas y copia en silencio cada número de tarjeta y contraseña que tus clientes introducen al pagar, enviándolo a un atacante mientras tu web parece completamente normal: solo te enteras cuando llegan las quejas de fraude.
• Un estafador planta un formulario falso de «pagar aquí» en tu web real que captura los pagos en su propia cuenta; los clientes creen que te pagaron, te culpan cuando la mercancía no llega, y exigen su dinero de vuelta.
• El equipo de seguridad de un cliente mayor escanea tu web, ve que esta protección básica está apagada, y la señala: atascando o haciéndote perder el contrato hasta que puedas demostrar que está arreglado.
• Una brecha rastreada hasta una salvaguarda estándar ausente se convierte en un incidente notificable: preguntas del regulador, notificaciones a clientes, y un golpe a la reputación que cuesta mucho más que la solución gratuita.

Por qué importa. El candado demuestra que la conexión a tu web es privada, pero no hace nada por controlar qué código se ejecuta una vez que un visitante está en la página. Una Política de Seguridad de Contenido es la salvaguarda que sí lo hace: le dice a los navegadores que ignoren cualquier script que no venga de una fuente en la que confías, para que un único campo, anuncio o complemento manipulado no pueda convertirse en una herramienta para robar el dinero y los datos de tus clientes. Es una comprobación calificada en tu informe, vale puntos de verdad, y es de las primeras cosas que busca una revisión de seguridad profesional.

Qué es esto, en palabras sencillas

Cuando alguien visita tu web, su navegador descarga tu página y ejecuta el código que haya en ella: los scripts que hacen desplegarse los menús, funcionar los botones, enviarse los formularios de pago, y demás. Por defecto, el navegador confía en todo ello. No tiene forma de saber qué código es genuinamente tuyo y cuál coló otra persona.

Una Política de Seguridad de Contenido (a menudo abreviada como CSP) es una breve lista de reglas que tu web adjunta a cada página, indicándole al navegador: «ejecuta solo código de estas fuentes que he aprobado, y rechaza todo lo demás». Es la diferencia entre una discoteca que deja entrar a cualquiera y una con una lista de invitados en la puerta.

La razón por la que esto importa tanto es que las webs son manipuladas constantemente, no siempre pirateando tu servidor, sino a través de las puertas traseras que la mayoría de las webs dejan abiertas: un campo de comentarios, un cuadro de búsqueda, un complemento desactualizado, un script de terceros para anuncios o analíticas, o un widget de chat. Si un atacante consigue meter siquiera una línea de su propio código en una de tus páginas, el navegador la ejecuta como si fuera tuya. A partir de ahí puede leer todo lo que tus clientes escriben —números de tarjeta, contraseñas, direcciones— y enviarlo en silencio a otro sitio. Una Política de Seguridad de Contenido cierra esa puerta negándose a ejecutar nada de una fuente que no aprobaste.

Lo que esto te puede costar

Esto no es abstracto. El ataque que una Política de Seguridad de Contenido previene —código inyectado en una página que roba datos de tus propios clientes— está detrás de algunas de las mayores brechas de robo de tarjetas registradas. Así es como tiende a desarrollarse para una empresa normal:

• El robador de pagos invisible. Un atacante cuela unas líneas de código en tu página de pago a través de un complemento vulnerable o un script de terceros comprometido. Cada número de tarjeta, nombre y CVV que tus clientes escriben se copia y se envía al atacante en tiempo real. Tu web se ve y funciona a la perfección; el candado está ahí. Lo descubres semanas después, cuando tu proveedor de pagos llama por un grupo de reportes de fraude que se rastrean todos hasta tu tienda. Ahora te enfrentas a devoluciones de cargo, una auditoría de seguridad forzada, posible pérdida de los derechos de procesamiento de tarjetas, y una brecha que puede que estés legalmente obligado a notificar.

• El formulario de pago falso. Un estafador inyecta un convincente cuadro de «pagar aquí» en tu web real. Los clientes introducen sus datos confiando en tu marca; el dinero y los datos van al atacante. Los clientes te culpan a ti, y no se equivocan al hacerlo, porque ocurrió en tu web.

• El contrato perdido. El equipo de seguridad de un cliente potencial mayor hace un escaneo automatizado de tu web como parte de la diligencia debida sobre proveedores. Una Política de Seguridad de Contenido ausente aparece de inmediato como un hueco de severidad alta. Para un revisor de compras o seguridad, esa única salvaguarda ausente se lee como «este proveedor no hace lo básico», y el acuerdo se atasca mientras piden una corrección, o se va en silencio a un competidor que pasó.

• La brecha notificable. Cuando una brecha de datos se rastrea hasta una salvaguarda estándar, gratuita y ausente, deja de ser mala suerte y empieza a parecer negligencia. Eso cambia las preguntas del regulador, la obligación de notificar a los clientes y el coste, tanto la multa como el daño reputacional, que perdura mucho después de cerrar el incidente.

• El anuncio o widget comprometido. Muchas webs cargan código de partes externas: redes de anuncios, fuentes, chat de soporte, analíticas. Si cualquiera de ellos es comprometido, el código malicioso entra directo en tus páginas. Una Política de Seguridad de Contenido limita el radio de impacto permitiendo solo las fuentes externas concretas en las que confías, para que la brecha de un proveedor no se convierta automáticamente en la tuya.

Qué es en realidad (el detalle)

Una Política de Seguridad de Contenido se entrega como una única cabecera de respuesta HTTP: una línea que tu servidor web envía con cada página. Su valor es un conjunto de directivas, cada una nombrando un tipo de contenido y las fuentes permitidas para él. Por ejemplo:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

En términos sencillos, eso dice: por defecto carga solo cosas de mi propia web; ejecuta solo scripts de mi propia web; no permitas complementos de estilo antiguo; y no dejes que otras webs incrusten la mía en un marco.

Cómo se ve lo «bueno». Nuestra comprobación no solo busca la presencia de la cabecera: lee la política directiva por directiva y puntúa lo fuerte que es de verdad, como lo haría un revisor de seguridad. Una política fuerte:

• Establece una base restrictiva (default-src 'self') y solo la amplía para los terceros de confianza concretos que de verdad usas.
• Evita los agujeros. No usa 'unsafe-inline' ni 'unsafe-eval' para scripts, y no usa comodín (*) ni fuentes de esquema pelado (como https:) para scripts: estos reabren de hecho la puerta que la política debía cerrar. Donde de verdad se necesitan scripts en línea, usa un nonce o un hash para que solo se ejecute tu código aprobado concreto.
• Bloquea el enmarcado con frame-ancestors 'self' (esto también bloquea el ataque de «incrustar tu web para engañar a tus clientes») y deshabilita los complementos heredados con object-src 'none'.
• Es de imposición, no de solo informe. Una cabecera Content-Security-Policy-Report-Only solo observa; ofrece cero protección en tiempo de ejecución. Nuestra comprobación le da una pequeña fracción del crédito y nunca lo registra como aprobado. Solo estás protegido una vez que la política está en imposición.

Una política que existe pero se apoya en 'unsafe-inline', 'unsafe-eval' o comodines puntuará igualmente mal, porque en la práctica ofrece poca protección real. El objetivo es una política ajustada, no una política cualquiera.

Cómo solucionarlo (gratis, ~1–2 horas)

Pásale esto a tu informático o a quien lleve tu web: la solución en sí es completamente gratis. Solo cobramos por vigilar que se mantenga en su sitio y correcta con el tiempo; activarla no cuesta nada. La razón por la que esto lleva una hora o dos en lugar de minutos es el cuidadoso paso de prueba que evita que bloquee por accidente partes de tu propia web.

1. Empieza en modo de solo informe — no impongas todavía. Añade una cabecera de respuesta Content-Security-Policy-Report-Only. Esto observa y registra lo que se bloquearía sin bloquear nada de verdad, para que la web en vivo siga funcionando mientras aprendes de qué depende genuinamente cada página. (Importante: el solo informe por sí solo no da protección a los visitantes; es solo el primer paso seguro.)

2. Construye la política a partir de lo que tu web usa de verdad. Revisa los informes para encontrar cada fuente legítima de scripts, estilos, fuentes e imágenes —tu propio dominio, tus analíticas, tu proveedor de pagos, tu host de fuentes, tu widget de chat— y enuméralas como fuentes permitidas. Un buen punto de partida es default-src 'self' más entradas explícitas para los terceros de confianza que de verdad usas.

3. Evita los agujeros que arruinan todo el propósito. Mantente alejado de 'unsafe-inline' y 'unsafe-eval' para scripts, y evita las fuentes con comodín como * y los esquemas pelados como https: para scripts: estos reabren el mismo hueco que la política debía cerrar. Donde los scripts en línea sean inevitables, usa un nonce o un hash para que solo se ejecute tu código aprobado concreto.

4. Bloquea el enmarcado y los complementos. Añade frame-ancestors 'self' (esto también impide que otras webs incrusten la tuya para engañar a tus clientes, y satisface la comprobación relacionada de secuestro de clics) y object-src 'none' para bloquear los ataques basados en complementos heredados.

5. Cambia de solo informe a imposición. Una vez que los informes estén limpios y la web funcione, cambia el nombre de la cabecera de Content-Security-Policy-Report-Only a Content-Security-Policy. Este es el paso que de verdad entrega protección: una política de solo informe por sí sola no lo hace, y no pasará la comprobación.

   Dónde configuras la cabecera depende de tu plataforma:

   • Cloudflare: Rules → Transform Rules → Modify Response Header → configura Content-Security-Policy. (También puedes usar Cloudflare para la prueba de solo informe.)
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): añade una cabecera de respuesta HTTP personalizada llamada Content-Security-Policy con la política como su valor.
   • Google Workspace / Microsoft 365: estos hacen funcionar tu correo, no tu web pública, así que la política se configura allá donde esté alojada de verdad tu web (Cloudflare o tu host web de arriba), no en el panel de administración de tu correo.

6. Vuelve a comprobar tu dominio para confirmar que la política ahora aparece como activada y en imposición, sin agujeros que la debiliten.

Errores habituales

• Quedarse en el solo informe. El error más común con diferencia: se añade una política en modo de solo informe, todos siguen adelante, y la web nunca queda protegida de verdad. El solo informe no bloquea nada. Debes cambiar a imposición.
• Recurrir a 'unsafe-inline' para que «simplemente funcione». Cuando la política bloquea un script en línea legítimo, la solución rápida es permitir todos los scripts en línea, pero eso reabre el mismo agujero que la política debía cerrar. Usa un nonce o un hash en su lugar.
• Usar un comodín. Un * pelado (o https:) en script-src permite scripts de cualquier sitio, lo que significa que la política casi no da protección real y seguirá puntuando bajo.
• Olvidar las fuentes de terceros. Imponer una política estricta sin enumerar primero los servicios externos legítimos que usas (analíticas, fuentes, widgets de pago) puede romper partes de tu propia web, que es exactamente por lo que existe el paso de prueba de solo informe.
• Configurarla solo en la portada. La política necesita cubrir cada página, especialmente las de pago, inicio de sesión y cuenta: esas son las que vale la pena atacar.
• Tratarla como un sustituto del candado. Una Política de Seguridad de Contenido y HTTPS/HSTS protegen cosas distintas. Las quieres todas; una no cubre por otra.

Preguntas frecuentes