Los 10 errores más comunes en cabeceras de seguridad (y cómo corregirlos)

Las cabeceras de respuesta HTTP son ese raro control de seguridad que cuesta unas líneas de configuración y protege a cada visitante de inmediato. Por eso también es tan común equivocarse: son fáciles de copiar y pegar y difíciles de probar. Estos son los diez problemas que aparecen una y otra vez en los análisis.

1. Sin HSTS (o HSTS sin la ruta de preload)

Sin Strict-Transport-Security, una sola petición en texto plano puede interceptarse antes de la redirección a HTTPS. Define un max-age largo e incluye subdominios:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Añade preload solo cuando cada subdominio sea exclusivamente HTTPS: es difícil de revertir con rapidez.

2. Una Content-Security-Policy que permite unsafe-inline

script-src 'unsafe-inline' vuelve a abrir el mismo agujero XSS que la CSP existe para cerrar. Pasa a nonces o hashes:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'

3. Dejar la CSP en modo report-only para siempre

Content-Security-Policy-Report-Only es para la fase de despliegue. Muchos sitios la dejan ahí durante meses, recogiendo informes sin aplicar nada. Usa report-only para encontrar violaciones y cambia a la cabecera que aplica cuando esté en silencio.

4. X-Frame-Options en vez de frame-ancestors

X-Frame-Options es heredado y no puede expresar una lista de permitidos. Prefiere la directiva de CSP, que los navegadores modernos respetan:

Content-Security-Policy: frame-ancestors 'self'

5. Falta X-Content-Type-Options

Sin X-Content-Type-Options: nosniff, un navegador puede hacer MIME-sniffing de una respuesta y ejecutar algo que serviste como texto. Es una sola cabecera sin inconvenientes: ponla siempre.

6. Una Referrer-Policy peligrosa o ausente

El valor por defecto filtra URLs completas (incluidos tokens en la cadena de consulta) a terceros. Una opción segura y muy compatible:

Referrer-Policy: strict-origin-when-cross-origin

7. Permissions-Policy en el valor por defecto del navegador

Si tu aplicación no usa la cámara, el micrófono ni la geolocalización, decláralo explícitamente para que un script comprometido tampoco pueda:

Permissions-Policy: camera=(), microphone=(), geolocation=()

8. Poner cabeceras en el HTML pero no en la API

Las cabeceras que aplica un framework de frontend suelen omitir rutas de API, redirecciones y páginas de error. Los escáneres prueban esas rutas directamente. Define las cabeceras de seguridad en el borde —un proxy inverso, un CDN o el middleware de la plataforma— para que la cobertura sea uniforme.

9. Cabeceras en conflicto desde varias capas

Cuando tu aplicación y tu CDN definen Content-Security-Policy, el navegador puede ver dos cabeceras y aplicar la *intersección*, rompiendo funciones en silencio. Decide una capa autoritativa y elimina los duplicados.

10. Cachear respuestas sensibles

Las páginas autenticadas y las respuestas de API con datos personales no deben ser cacheables por proxies compartidos:

Cache-Control: no-store

Confírmalo con un nuevo análisis

Las cabeceras interactúan, así que cámbialas en lotes pequeños y vuelve a analizar tras cada uno. Si eres nuevo leyendo resultados, empieza por Cómo leer un informe de análisis de seguridad web; para la capa de transporte bajo estas cabeceras, consulta Configuraciones de SSL/TLS que ponen en riesgo tu sitio. La comprobación completa de cabeceras se ejecuta en cada análisis: consulta todas las comprobaciones en la página de funciones.