Cabeceras de seguridad HTTP: qué revelan HSTS, CSP y X-Content-Type-Options sobre la madurez técnica de un sitio
Una guía sobre las cabeceras de respuesta HTTP que la OWASP recomienda como protección básica, qué previene realmente cada una y por qué su ausencia es una brecha de configuración, no una prueba de intrusión.
Confiabilidad y Seguridad
Lectura ejecutiva
Conclusiones principales
- Strict-Transport-Security (HSTS) indica al navegador que nunca vuelva a intentar HTTP en ese dominio, incluso si un enlace o una dirección escrita apunta a la versión insegura.
- Content-Security-Policy (CSP) declara desde dónde el navegador puede cargar scripts, estilos y otros recursos, reduciendo el efecto de una inyección de contenido incluso si ocurre.
- OWASP recomienda un conjunto núcleo de cabeceras de respuesta como protección básica, no como una certificación completa de seguridad de la aplicación.
- La ausencia de una cabecera es una brecha de configuración observable públicamente; no equivale a una vulnerabilidad explotable confirmada ni reemplaza una prueba de penetración.
Un sitio puede tener un certificado HTTPS válido, el candado verde en el navegador, y aun así responder sin ninguna de las cabeceras de seguridad que la OWASP recomienda como protección básica. El candado confirma que la conexión está cifrada. No confirma que se haya indicado al navegador que rechace un futuro intento de conexión insegura, ni que exista una política declarada sobre desde dónde pueden cargarse los scripts.
Estas cabeceras de respuesta HTTP son configuración de servidor, no código de aplicación. Eso las hace verificables públicamente, sin acceso a ninguna cuenta ni al repositorio del sitio — y por eso su ausencia es un hallazgo común en una auditoría orientada a evidencia.
Qué se puede observar, y qué prueba
El OWASP Secure Headers Project define un conjunto núcleo de cabeceras de respuesta recomendadas para cualquier aplicación web. Cinco de ellas son directamente observables en la respuesta HTTP de cualquier página pública:
| Cabecera | Qué declara | Qué reduce |
|---|---|---|
Strict-Transport-Security (HSTS) | Por cuánto tiempo el navegador debe exigir HTTPS en este dominio | Ataques de downgrade de protocolo y secuestro de cookies en un intento inicial de HTTP |
Content-Security-Policy (CSP) | Desde dónde pueden cargarse scripts, estilos y otros recursos | El efecto de una inyección de contenido, incluso si ocurre |
X-Content-Type-Options | Que el navegador no debe adivinar (sniff) el tipo de contenido de una respuesta | Ejecutar un archivo como un tipo distinto al declarado |
Referrer-Policy | Cuánta información de la URL de origen se envía al siguiente sitio | Fuga de parámetros sensibles de URL hacia terceros |
Permissions-Policy | Qué APIs del navegador (cámara, micrófono, geolocalización) puede usar la página | Uso no intencionado de APIs sensibles por scripts de terceros |
OWASP recomienda configurar HSTS con un max-age de dos años (63072000 segundos), la directiva includeSubDomains y, cuando aplique, preload — un plazo lo bastante largo para que el navegador nunca "olvide" la exigencia de HTTPS entre visitas.
Ninguna de estas cabeceras, por sí sola, prueba que la aplicación esté libre de vulnerabilidades. Cada una reduce una clase específica de riesgo en la capa de transporte y carga de contenido; ninguna audita la lógica de negocio, el control de acceso ni las dependencias de la aplicación.
Método: de la respuesta HTTP a la priorización
1. Captura la respuesta HTTP de la página real, no de una versión en caché
El inspector de red del navegador, o una solicitud directa, muestra las cabeceras exactamente como las envió el servidor. Las CDN y los proxies a veces eliminan o sobrescriben cabeceras configuradas en el origen — por eso la verificación debe hacerse contra la URL pública final, no contra un entorno de desarrollo.
2. Verifica presencia, no solo el nombre de la cabecera
Una cabecera presente con una directiva débil (por ejemplo, un CSP que permite unsafe-inline de forma amplia) reduce la protección que la cabecera debería ofrecer. Verificar la presencia es el primer filtro; leer la directiva es el paso siguiente, normalmente a cargo de ingeniería en una revisión dedicada.
3. Cruza con la base del documento HTML
Un doctype declarado, un charset definido al inicio del <head> y una etiqueta de viewport son prerrequisitos para un renderizado predecible — no son cabeceras de seguridad, pero suelen faltar en los mismos proyectos que tampoco configuran cabeceras de respuesta, porque ambas son decisiones de configuración de bajo nivel que quedan atrás en migraciones apresuradas.
4. No confundas la ausencia de una cabecera con una vulnerabilidad confirmada
La diferencia entre "la cabecera no fue encontrada" y "el sitio fue hackeado" es la diferencia entre una auditoría de configuración pública y una prueba de penetración. Trata la ausencia como un punto de investigación para ingeniería, no como un incidente de seguridad confirmado.
Falsos positivos y limitaciones
- Las CDN y los proxies inversos pueden agregar o eliminar cabeceras entre el origen y el navegador. Confirma la configuración tanto en el origen como en el punto de entrega final.
- Una cabecera presente puede estar mal configurada. La presencia no equivale a una directiva correcta; una política de CSP vacía o demasiado permisiva sigue contando como "presente" en una verificación simple de existencia.
- Ninguna de estas cinco cabeceras cubre autenticación, control de acceso o dependencias desactualizadas. Son una porción observable públicamente de la postura de seguridad, no una auditoría completa.
Plan de acción
- Verificar la respuesta HTTP de la página pública principal y confirmar cuáles de las cinco cabeceras núcleo están presentes. Responsable sugerido: Ingeniería.
- Priorizar HSTS y CSP primero — las dos con mayor reducción de riesgo de downgrade de protocolo e inyección de contenido, respectivamente.
- Revisar las directivas, no solo la presencia, en una sesión dedicada de ingeniería — especialmente CSP, cuya política incorrecta puede ser demasiado permisiva o romper funcionalidades legítimas.
- Reverificar después de cualquier cambio de CDN, proxy inverso o proveedor de hosting, ya que estos componentes pueden sobrescribir silenciosamente cabeceras configuradas en el origen.
Remountly verifica la presencia de estas cinco cabeceras en la respuesta HTTP pública de una página como parte de la categoría de Buenas Prácticas, junto con HTTPS, contenido mixto y patrones de API obsoletos como document.write. Esa verificación es evidencia de configuración observable — el mismo principio detrás de transformar problemas técnicos en impacto financiero: comienza por lo que se puede observar públicamente antes de asumir la causa.
Respuestas directas
Preguntas frecuentes
¿Remountly prueba si un sitio puede ser hackeado?
No. Remountly verifica, a partir de la respuesta HTTP pública, si cinco cabeceras de seguridad recomendadas por OWASP están presentes: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy y Permissions-Policy. Esto es una verificación de configuración observable, no una prueba de penetración ni una auditoría de vulnerabilidades de la aplicación.
¿Por qué HTTPS por sí solo no es suficiente?
HTTPS protege los datos en tránsito entre el navegador y el servidor, pero no impide que un usuario escriba o haga clic en un enlace a la versión http:// del mismo dominio antes de que ocurra la redirección. HSTS cierra esa ventana al indicar al navegador que nunca intente la versión insegura, incluso en el primer intento, una vez que ha visto la cabecera dentro del plazo de max-age.
¿Un sitio puede tener todas las cabeceras recomendadas y aun así ser vulnerable?
Sí. Estas cabeceras reducen clases específicas de riesgo, pero no cubren fallas de lógica de negocio, control de acceso roto, dependencias desactualizadas ni errores de autenticación. Son una capa de defensa observable públicamente, no una auditoría de seguridad completa de la aplicación.