Los encabezados seguros son encabezados de respuesta HTTP que indican a los navegadores cómo manejar diversos aspectos de seguridad del contenido web. Estos incluyen encabezados como HSTS, CSP, X-Frame-Options y otros. Los encabezados de seguridad configurados correctamente proporcionan una capa adicional de defensa contra diversos ataques, como XSS, clickjacking y ataques de degradación de protocolo.
Las cabeceras de seguridad son cabeceras de respuesta HTTP que un servidor envía para indicarle al navegador cómo tratar el contenido y las conexiones de una página. En lugar de residir en el cuerpo de la página, configuran las propias defensas del navegador: Content-Security-Policy restringe qué scripts y recursos pueden cargarse, Strict-Transport-Security fuerza HTTPS, X-Frame-Options (o CSP frame-ancestors) bloquea el enmarcado, X-Content-Type-Options impide el sniffing de MIME, y Referrer-Policy y Permissions-Policy limitan qué datos y APIs expone una página. Cada cabecera apunta a una clase concreta de ataque. Como el navegador las aplica, añaden defensa en profundidad por encima de la validación del lado del servidor y la lógica de la aplicación, y suelen ser baratas de desplegar en el servidor web, la CDN o el edge.
Unas cabeceras de seguridad ausentes o débiles dejan abiertas clases de ataque conocidas incluso cuando el código de la aplicación es sólido. Sin HSTS a un usuario se le puede degradar a HTTP plano e interceptar; sin una restricción de enmarcado la página puede sufrir clickjacking; sin una Content Security Policy un script inyectado se ejecuta libremente. Las cabeceras son un control de bajo esfuerzo y amplia cobertura, y por eso aparecen en las comprobaciones de cumplimiento y en los escáneres automatizados. Pero son solo una base: una CSP permisiva que mantiene unsafe-inline, o una cabecera HSTS sin includeSubDomains, da una falsa sensación de seguridad. El detalle de la configuración importa tanto como su presencia, y las cabeceras protegen el documento first-party, no el comportamiento de los scripts de terceros que carga.
Configura una Content-Security-Policy estricta (basada en nonce o hash, sin unsafe-inline), HSTS con un max-age largo e includeSubDomains, X-Content-Type-Options: nosniff, una restricción de enmarcado y una Referrer-Policy ajustada; pruébalo con un escáner de cabeceras y despliega la CSP primero en modo report-only. Recuerda que las cabeceras pueden eliminarse o debilitarse aguas abajo, ya que las extensiones de navegador maliciosas y el código inyectado pueden retirarlas del lado del cliente. El papel de cside es más acotado y complementario: gestiona y monitoriza la CSP, y al enrutar los scripts de terceros a través de un método Script y analizar la carga detecta el comportamiento malicioso de los scripts que las cabeceras por sí solas permiten, conservando registros forenses útiles para PCI DSS 6.4.3 y 11.6.1.
Una Content-Security-Policy estricta, Strict-Transport-Security, X-Content-Type-Options con el valor nosniff y un control de enmarcado como X-Frame-Options o CSP frame-ancestors cubren los riesgos de mayor impacto: inyección de scripts, degradación de protocolo, confusión de MIME y clickjacking. Referrer-Policy y Permissions-Policy son añadidos valiosos para limitar las fugas de datos y restringir APIs potentes del navegador.
Sí. Los proxies, las CDN mal configuradas y, sobre todo, las extensiones de navegador maliciosas o con privilegios excesivos pueden retirar o alterar las cabeceras de respuesta antes o después de que lleguen al navegador. Por eso las cabeceras son una capa de defensa y no una garantía, y por eso sigue importando monitorizar lo que los scripts hacen realmente en el navegador.
We answer client-side security questions every day. Bring yours.