Por qué los headers de seguridad importan más de lo que parecen
Un sitio sin headers de seguridad es como una casa con buena cerradura pero ventanas abiertas. El servidor puede estar perfectamente protegido, pero si no le dice al navegador cómo debe comportarse al renderizar tu contenido, abrís la puerta a XSS, clickjacking, MitM y otros ataques. Los headers HTTP correctos cierran esas ventanas a nivel navegador.
El caso clásico es Strict-Transport-Security (HSTS). Sin HSTS, un usuario que tipea "ejemplo.com" sin https:// hace primer request por HTTP. Un atacante en wifi pública puede interceptar ese primer request y servir contenido malicioso aún si tu server redirige a HTTPS. HSTS le dice al navegador "para este dominio, siempre HTTPS, nunca HTTP" desde la próxima visita. Con preload activado, ni siquiera la primera visita va por HTTP.
El otro pilar es Content Security Policy (CSP). Aún si un atacante logra inyectar JavaScript en tu página (XSS), un CSP estricto con default-src 'self' impide que ese JS cargue scripts externos, abra iframes maliciosos o exfiltre datos a dominios no autorizados. Mozilla Observatory, SecurityHeaders.com y herramientas similares evalúan tu sitio con A+ solo si tenés CSP estricto correctamente configurado.
Headers críticos: el set mínimo recomendado
Para una app web moderna, OWASP recomienda al menos estos: Strict-Transport-Security con max-age 1 año + includeSubDomains + preload, Content-Security-Policy al menos con default-src self, X-Content-Type-Options nosniff para prevenir MIME sniffing, X-Frame-Options DENY o equivalente CSP frame-ancestors none para anti-clickjacking, y Referrer-Policy strict-origin-when-cross-origin para no leakear URLs sensibles.
El header Permissions-Policy (antes Feature-Policy) controla qué APIs del navegador puede usar tu sitio: cámara, micrófono, geolocalización. Si tu app no usa cámara, declarar camera=() impide que un script malicioso inyectado active la cámara aunque el usuario haya dado permiso al sitio antes. Es defensa en profundidad: aún si CSP falla, Permissions-Policy bloquea el siguiente paso.
Las cookies merecen tratamiento especial. Toda cookie de sesión debería tener Secure (solo HTTPS), HttpOnly (no accesible desde JS), SameSite=Strict o Lax (anti-CSRF). El prefijo __Host- en el nombre fuerza Secure + Path=/ + sin Domain, dándote la cookie más segura posible. Stripe, GitHub y Google usan __Host- y __Secure- prefixes en producción.
Errores comunes al configurar headers de seguridad
Error #1: activar HSTS preload sin estar listo. Una vez que tu dominio entra a la HSTS preload list (mantenida por Chromium), salir lleva semanas o meses. Si rompés HTTPS por cualquier razón, el sitio queda inaccesible para usuarios con esos navegadores hasta que se quite del preload. Empezá con max-age=300 (5 min), subí a 86400 (1 día), después 31536000 (1 año), y solo ahí agregás preload.
Error #2: CSP demasiado permisivo. script-src 'self' 'unsafe-inline' 'unsafe-eval' * es básicamente "todo permitido". Si tu CSP necesita unsafe-inline porque tu app usa estilos inline o event handlers en HTML, mejorá la app antes de relajar el CSP. Google recomienda usar nonces o hashes en vez de unsafe-inline. SecurityHeaders.com te da F si usás unsafe-inline incluso si el resto está bien.
Error #3: headers conflictivos o duplicados. Si tu app server setea X-Frame-Options DENY y tu nginx setea X-Frame-Options SAMEORIGIN, el navegador puede tomar cualquiera y romper iframes legítimos. Auditá la cadena completa: app server, reverse proxy, CDN. Cloudflare permite override de headers y sobrescribe los que pongas en nginx silenciosamente. Probá con curl -I el endpoint final público.
Testing y monitoreo de headers de seguridad
Tres herramientas para auditar headers en producción: SecurityHeaders.com da score A+ a F basándose en headers presentes y valores. Mozilla Observatory es más estricto y agrega análisis de TLS/SSH. Hardenize.com es el más completo, evalúa también CAA, DNSSEC y otras configuraciones de DNS. Apuntá a A+ en los tres antes de declarar el sitio "seguro".
Para CSP en particular, la estrategia es Report-Only mode primero. Empezás con Content-Security-Policy-Report-Only que reporta violaciones a un endpoint pero no bloquea nada. Eso te muestra qué scripts inline, recursos externos y comportamientos rompe el CSP propuesto. Después de ajustar la app o hacer allow-list correcta, cambiás a Content-Security-Policy normal que sí bloquea.
En CI/CD, agregá tests de headers con herramientas como helmet (Node), django-csp (Python) o secure-headers-rust. Esos middlewares aplican headers seguros por default y permiten configurar excepciones controladas. Más vale prevenir un mal deploy con headers laxos que descubrirlo en SecurityHeaders después de que un crawler indexó tu sitio inseguro durante 3 días. Vercel, Netlify y Cloudflare Pages permiten declarar headers en archivos de configuración versionados.