¿Es la CSP un sustituto de la desinfección de insumos?

No, defensa en profundidad. La higienización de la entrada previene la inyección; CSP evita que se ejecute la inyección si falla la desinfección. Ambos deberían estar en su lugar. Depender únicamente de la CSP es frágil; Depender únicamente de la desinfección ha estado fallando durante dos décadas.

¿Debo usar nonces o hashes?

Nonces para contenido dinámico (el caso común); hashes para scripts en línea fijos cuyo contenido nunca cambia. La mayoría de los marcos modernos incluyen soporte nonce de forma nativa. Los hashes son conceptualmente más simples, pero se convierten en una carga de mantenimiento si cambia el contenido del script.

¿Por qué sigue siendo común el uso inseguro en línea?

Código heredado que lo requiere (bibliotecas con controladores de eventos en línea, marcos más antiguos). La refactorización lleva mucho tiempo. La solución honesta es la refactorización; El atajo común es mantener la inseguridad en línea y confiar en otras defensas.

¿Cómo superviso las infracciones del CSP?

Establezca report-to o report-uri en un punto final del recopilador. Muchas plataformas de seguridad (Cloudflare, Sucuri, personalizadas) aceptan y analizan informes de CSP. El tráfico del mundo real genera mucho ruido (extensiones de navegador, bloqueadores de publicidad); Separar los ataques reales del ruido es parte de la carga de trabajo operativa.

¿Existen generadores de mejores prácticas de CSP?

Herramientas como CSP Evaluator de Google analizan una política propuesta y señalan sus debilidades. El Observatorio Mozilla califica páginas que incluyen la calidad de CSP. Utilícelos para auditar; ayudan a resaltar errores comunes pero no sustituyen la comprensión de la política.

Explicación de la política de seguridad de contenido: el encabezado HTTP que define lo que puede hacer su página

La política de seguridad de contenido es el encabezado HTTP que permite a las páginas web declarar lo que se permite cargar y ejecutar. Un CSP estricto convierte a XSS en un riesgo mucho menor: incluso si un atacante inyecta un script, el navegador se niega a ejecutarlo. La contrapartida es la complejidad de la implementación, razón por la cual la CSP se adopta menos de lo que debería.

El cuerpo completo del artículo se proporciona en inglés a continuación.

Política de seguridad de contenido (CSP) es un encabezado de respuesta HTTP (y equivalente a una metaetiqueta) que le indica al navegador qué orígenes pueden cargar recursos, qué scripts en línea pueden ejecutarse y dónde deben enviarse los informes de violaciones. Un CSP bien configurado reduce drásticamente el impacto de las vulnerabilidades de inyección; uno mal configurado proporciona confianza falsa con poca protección real.

Qué controla el CSP

La política se compone de directivas, cada una de las cuales especifica fuentes permitidas para un tipo de recurso:

script-src: fuentes de JavaScript permitidas para cargar y ejecutar
style-src: CSS fuentes
img-src - fuentes de imágenes
connect-src - XHR, búsqueda, objetivos WebSocket
font-src - fuente fuentes
media-src — fuentes de audio y video
frame-src — qué se puede cargar en iframes
frame-ancestors — qué se puede enmarcar esta página (reemplaza X-Frame-Options)
form-action: dónde se pueden enviar los formularios
base-uri: qué URL se pueden configurar como base
upgrade-insecure-requests: actualización automática de HTTP a HTTPS
default-src: respaldo para directivas no especificadas

Una política inicial razonable

Content-Security-Policy:
  default-src 'yo';
  script-src 'self' 'nonce-randomBase64Value';
  style-src 'self' 'inseguro-en línea';
  img-src datos 'propios': https:;
  connect-src 'auto' https://api.example.com;
  ancestros del marco 'ninguno';
  base-uri 'yo';
  forma-acción 'yo';
  report-uri https://example.com/csp-reports

Esta política dice: de forma predeterminada, cargar solo desde el mismo origen, los scripts deben ser del mismo origen o llevar el nonce coincidente, no se deben incrustar en iframes de otros sitios, etc. El enfoque basado en nonce evita la mayoría de los XSS de scripts en línea y al mismo tiempo permite scripts en línea legítimos que el servidor emite con la información correcta. nonce.

Nonces vs hashes vs listas blancas

Tres formas de permitir scripts en línea específicos:

Nonce-based. El servidor genera un nonce aleatorio nuevo por solicitud y lo incluye en CSP plus en cada script en línea permitido. Estricto y dinámico, recomendado para nuevas implementaciones.
Hash-based. CSP especifica hashes SHA de scripts en línea permitidos. El navegador codifica scripts en línea y los compara. Funciona para scripts estáticos cuyo contenido no cambia.
Lista blanca de orígenes. Permite scripts de dominios externos específicos. Fácil, pero crea grandes superficies de ataque: si algún dominio incluido en la lista blanca se ve comprometido o tiene redireccionamientos abiertos, se omite la política.

La palabra clave dinámica estricta (agregada en CSP 3) restringe aún más los scripts: solo los scripts no permitidos pueden cargar otros scripts, rompiendo las cadenas XSS comunes.

The cargo-cult anti-pattern

Muchos sitios implementan CSP con unsafe-inline y unsafe-eval en script-src para evitar romper el código existente. Básicamente, esto no es un CSP en absoluto: el objetivo es evitar que se ejecuten scripts en línea, y unsafe-inline elimina esa protección. Los sitios con esta configuración tienen encabezados CSP sin beneficios de CSP.

La ruta al valor CSP real: elimine el código inseguro en línea, refactorice para usar nonces o hashes y trate las infracciones una por una. Doloroso pero real.

Modo de solo informe

CSP se puede implementar en modo de solo informe: el navegador informa violaciones a un URI configurado pero no las aplica. Útil para probar una nueva política contra el tráfico real sin dañar el sitio:

Content-Security-Policy-Report-Only: ...

La implementación estándar: implementar en modo de solo informe, recopilar infracciones durante algunas semanas, corregir las legítimas, cambiar al modo de aplicación. Muchos sitios grandes tienen implementaciones de CSP de varios meses a través de este ciclo de iteración.

CSP y XSS

El beneficio principal: incluso cuando la inyección XSS tiene éxito, el script inyectado no se puede ejecutar si no tiene un nonce válido. La carga útil del atacante llega a la página; el navegador se niega a ejecutarlo. La vulnerabilidad sigue presente, pero el impacto se reduce drásticamente.

Esto no sustituye a la reparación del XSS: es una defensa en profundidad. Ambas capas deben estar presentes.

Compatibilidad con navegadores CSP

Todos los principales navegadores desde 2016+. Las características de CSP 3 (nonces, dinámica estricta, hashes) tienen un amplio soporte. Las brechas restantes se encuentran en el manejo de casos extremos: interacción de los ancestros del marco con X-Frame-Options, comportamiento variable de report-uri versus report-to, peculiaridades específicas del navegador en los informes de errores. fail

Los controladores de eventos en línea (onclick="...") violan CSP a menos que se permita explícitamente

Las aplicaciones de una sola página con contenido dinámico necesitan un manejo cuidadoso del nonce

Las extensiones del navegador a veces pueden inyectar contenido que viola CSP, generando ruido

Diferentes equipos pueden necesitar diferentes fragmentos de CSP; fusionar políticas no es trivial

Muchos sitios que deberían tener CSP no lo tienen, porque el costo operativo parece mayor que el beneficio de seguridad percibido. El costo es real; el beneficio también es real pero invisible (no ves los ataques que no ocurrieron).

Preguntas frecuentes

¿Es la CSP un sustituto de la desinfección de insumos?: No, defensa en profundidad. La higienización de la entrada previene la inyección; CSP evita que se ejecute la inyección si falla la desinfección. Ambos deberían estar en su lugar. Depender únicamente de la CSP es frágil; Depender únicamente de la desinfección ha estado fallando durante dos décadas.
¿Debo usar nonces o hashes?: Nonces para contenido dinámico (el caso común); hashes para scripts en línea fijos cuyo contenido nunca cambia. La mayoría de los marcos modernos incluyen soporte nonce de forma nativa. Los hashes son conceptualmente más simples, pero se convierten en una carga de mantenimiento si cambia el contenido del script.
¿Por qué sigue siendo común el uso inseguro en línea?: Código heredado que lo requiere (bibliotecas con controladores de eventos en línea, marcos más antiguos). La refactorización lleva mucho tiempo. La solución honesta es la refactorización; El atajo común es mantener la inseguridad en línea y confiar en otras defensas.
¿Cómo superviso las infracciones del CSP?: Establezca report-to o report-uri en un punto final del recopilador. Muchas plataformas de seguridad (Cloudflare, Sucuri, personalizadas) aceptan y analizan informes de CSP. El tráfico del mundo real genera mucho ruido (extensiones de navegador, bloqueadores de publicidad); Separar los ataques reales del ruido es parte de la carga de trabajo operativa.
¿Existen generadores de mejores prácticas de CSP?: Herramientas como CSP Evaluator de Google analizan una política propuesta y señalan sus debilidades. El Observatorio Mozilla califica páginas que incluyen la calidad de CSP. Utilícelos para auditar; ayudan a resaltar errores comunes pero no sustituyen la comprensión de la política.