Cabeceras de seguridad HTTP
Compruebe si su web tiene correctamente configuradas las cabeceras de seguridad HTTP.
Cómo funciona la comprobación de cabeceras
La herramienta envía una petición HTTPS GET normal a la URL que introduzca y lee las cabeceras de la respuesta - las mismas cabeceras que recibe cualquier navegador. No se analiza nada del cuerpo de la página; las cabeceras de seguridad viven íntegramente en la respuesta HTTP.
Después buscamos las cabeceras que controlan las protecciones del navegador: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options y Referrer-Policy. Cada cabecera presente suma puntos y las ausentes se listan con una explicación del riesgo que dejan abierto.
Como la comprobación sigue las redirecciones, el resultado refleja la URL final. Si su sitio redirige de HTTP a HTTPS o del dominio raíz a www, las cabeceras que ve pertenecen al destino.
Cómo interpretar los resultados
La puntuación es una orientación rápida, no una certificación. Lo que importa en la práctica:
- HSTS - indica a los navegadores que usen siempre HTTPS para su dominio. Un max-age de al menos medio año es práctica habitual; añada includeSubDomains solo si todos los subdominios sirven HTTPS.
- CSP - la defensa más fuerte contra XSS, pero también la más difícil de escribir. Incluso una política básica que restrinja las fuentes de scripts es una gran mejora frente a no tener ninguna.
- X-Content-Type-Options: nosniff y X-Frame-Options (o la directiva CSP frame-ancestors) - protecciones baratas de una línea contra el MIME sniffing y el clickjacking.
Problemas frecuentes
Cabecera configurada, pero reportada como ausente. Un reverse proxy o CDN delante de su aplicación puede eliminar o sobrescribir cabeceras. Compare la respuesta con curl -I directamente contra el origen y contra la URL pública para encontrar qué capa la elimina.
CSP presente, pero ineficaz. Content-Security-Policy-Report-Only registra las violaciones sin bloquear nada. Es útil para pruebas, pero no ofrece protección - cambie a la cabecera de aplicación efectiva cuando su registro de informes esté limpio.
Distintas rutas devuelven distintas cabeceras. Las cabeceras establecidas en el middleware de la aplicación pueden no aplicarse a los archivos estáticos servidos directamente por el servidor web, ni a las páginas de error. Pruebe también una URL de un recurso estático y una página 404.
Preguntas frecuentes
¿Qué cabeceras de seguridad debería tener todo sitio web?
Una base razonable: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy y protección de frames mediante X-Frame-Options o CSP frame-ancestors. Las API se benefician además de Cache-Control: no-store en respuestas sensibles.
¿Sigue siendo necesaria la cabecera X-XSS-Protection?
No. Los navegadores modernos eliminaron el auditor XSS que controlaba, y en navegadores antiguos la cabecera podía incluso introducir vulnerabilidades. Use en su lugar una Content-Security-Policy estricta.
¿Protege HSTS la primera visita?
Por sí solo no - el navegador solo aprende la regla de la primera respuesta HTTPS. Para cubrir la primera visita, envíe su dominio a la lista de precarga HSTS (hstspreload.org) y use la directiva preload junto con includeSubDomains.
¿Puede una cabecera mal puesta romper mi sitio?
Sí, dos casos clásicos: una CSP demasiado estricta bloquea sus propios scripts o estilos inline, y HSTS con includeSubDomains rompe cualquier subdominio que aún funcione con HTTP plano. Despliegue la CSP primero en modo report-only y empiece HSTS con un max-age corto.
Monitorea cambios de cabeceras continuamente
ePulz.io le avisa cuando una cabecera cambia (por ejemplo tras un despliegue que eliminó CSP por error).
Empezar con ePulz.io →Acerca de esta herramienta
Las cabeceras de seguridad le indican al navegador cómo proteger a tus visitantes. Esta auditoría comprueba si HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options y Referrer-Policy están realmente presentes y puntúa el resultado, para que detectes huecos de clickjacking y MIME-sniffing tras un despliegue.