Guía práctica · seguridad básica
Cabeceras de seguridad web: qué indican y qué no
Las cabeceras permiten al servidor comunicar restricciones al navegador. AuditLume comprueba cuatro señales concretas en la respuesta final. Encontrarlas no descarta vulnerabilidades; no encontrarlas tampoco prueba por sí solo que exista una explotación.
Las cuatro cabeceras del diagnóstico
Strict-Transport-Security
Cuando la URL final usa HTTPS, AuditLume comprueba si existe HSTS. Esta cabecera indica al navegador que use HTTPS en conexiones futuras durante el periodo declarado. Antes de habilitarla, confirma que el dominio funciona íntegramente por HTTPS. Opciones como includeSubDomains o la precarga amplían el alcance y no deben activarse sin revisar todos los subdominios.
Content-Security-Policy
Comprueba la presencia de una cabecera CSP aplicada. Una política define desde qué orígenes pueden cargarse distintos recursos y otras restricciones. Su utilidad depende de sus directivas: una cabecera presente pero excesivamente permisiva puede aportar poco. AuditLume no interpreta actualmente el valor ni trata Content-Security-Policy-Report-Only como sustituto de una política aplicada.
X-Content-Type-Options
Comprueba que el valor sea nosniff. La instrucción pide al navegador respetar determinados tipos MIME declarados. Al activarla, el servidor debe entregar CSS, JavaScript y otros recursos con el tipo correcto; de lo contrario pueden dejar de cargarse.
Referrer-Policy
Comprueba únicamente si la cabecera está presente. Cada valor decide qué información de referencia se envía en diferentes contextos. La elección adecuada depende de las necesidades del sitio; AuditLume no valida actualmente si el valor es reconocido o si responde a esas necesidades.
Un despliegue gradual y reversible
- Inventaría. Captura cabeceras de las rutas principales, recursos y respuestas de error, no solo de la portada.
- Define el alcance. Identifica dominios, subdominios, terceros, iframes, formularios y scripts necesarios.
- Prueba CSP. Diseña una política específica. El modo report-only puede ayudar a observar incompatibilidades antes de aplicar, pero los informes requieren análisis.
- Corrige tipos MIME. Verifica recursos antes de exigir
nosniff. - Confirma HTTPS. Solo después plantea HSTS y valora por separado sus opciones de alcance.
- Publica y observa. Repite rutas críticas y conserva una forma de revertir la configuración.
No copies una política CSP de otro sitio: sus orígenes y funciones pueden ser distintos. Evita añadir 'unsafe-inline' o comodines solo para eliminar errores sin entender qué contenido autorizan.
Cómo verificar el cambio
| Comprobación | Resultado esperado | Limitación |
|---|---|---|
| Respuesta HTTPS final | HSTS presente tras decidir el alcance | No prueba que cada subdominio esté preparado. |
| Rutas con HTML | CSP aplicada y compatible con funciones necesarias | La mera presencia no evalúa la fuerza de la política. |
| CSS y JavaScript | Tipos MIME correctos con nosniff | No evalúa el contenido del recurso. |
| Navegación entre orígenes | Referencia limitada según la política elegida | No cubre todo el flujo de datos. |
MDN documenta tanto Content Security Policy como Strict-Transport-Security. Contrasta allí sintaxis y comportamiento antes de cambiar producción.
Qué queda fuera
AuditLume no hace pentesting, revisión de código, análisis de dependencias, autenticación, autorización, configuración TLS profunda ni explotación. Tampoco comprueba actualmente Permissions-Policy, X-Frame-Options, frame-ancestors o todas las respuestas del sitio. El resultado no declara que una web sea segura, insegura o esté libre de riesgos.
Estas cabeceras son capas defensivas. Deben acompañar una configuración adecuada del servidor, actualizaciones, controles de acceso, gestión de secretos, registros y pruebas ajustadas al riesgo real.