HTTP Headers

Las cabeceras de seguridad HTTP son instrucciones que el servidor envía al navegador en cada respuesta para indicarle cómo debe comportarse frente a ciertos riesgos. Content-Security-Policy (CSP) define qué orígenes pueden cargar scripts, estilos o imágenes en la página, bloqueando así la ejecución de código inyectado por un atacante. Strict-Transport-Security (HSTS) obliga al navegador a usar siempre HTTPS con ese dominio, evitando ataques de downgrade a HTTP. X-Frame-Options impide que la página se cargue dentro de un <iframe> ajeno, X-Content-Type-Options evita que el navegador reinterprete el tipo de un archivo de forma insegura, y Referrer-Policy controla cuánta información de la URL de origen se comparte al navegar hacia otro sitio.

Estas cabeceras importan porque mitigan directamente dos de las familias de ataque más comunes en aplicaciones web: el XSS (Cross-Site Scripting), donde un atacante consigue ejecutar JavaScript malicioso en el navegador de la víctima aprovechando una entrada de datos mal saneada, y el clickjacking, donde se engaña al usuario para que haga clic en un elemento invisible superpuesto sobre una página legítima cargada dentro de un iframe. Una CSP bien configurada reduce drásticamente el impacto de un XSS aunque exista una vulnerabilidad en el código, y X-Frame-Options (o la directiva frame-ancestors de CSP) neutraliza el clickjacking por completo.

La ausencia de estas cabeceras no siempre significa que un sitio sea vulnerable, pero sí que carece de una capa de defensa adicional que actúa incluso si otras protecciones fallan. Por eso conviene auditarlas de forma periódica con herramientas especializadas como Mozilla Observatory o securityheaders.com, que analizan automáticamente las cabeceras de un dominio, señalan las que faltan o están mal configuradas, y asignan una puntuación orientativa del nivel de protección alcanzado, muy similar a la pestaña "Seguridad" que ofrece esta misma herramienta.

Configurar bien estas cabeceras suele requerir varias iteraciones: una CSP demasiado restrictiva puede romper funcionalidades legítimas del sitio (scripts de terceros, fuentes externas, widgets), por lo que conviene desplegarla primero en modo Content-Security-Policy-Report-Only para detectar qué bloquearía sin afectar todavía a los usuarios reales. Del mismo modo, activar HSTS con un valor de max-age alto es una decisión que conviene tomar con HTTPS ya estable en todo el dominio, porque revertirla antes de que expire el plazo declarado no es inmediato para los navegadores que ya lo memorizaron. En conjunto, estas cabeceras forman una defensa en profundidad que complementa —nunca sustituye— un desarrollo seguro del propio código de la aplicación.