Guías
Auditar cabeceras HTTP de seguridad
Las cabeceras reducen riesgos concretos pero no demuestran seguridad total.
Empieza por HTTPS y revisa CSP, anti-frame, nosniff y referente; una ausencia pide revisión, no prueba compromiso.
Proteger la capa de transporte con HTTPS y HSTS
Sirve todo el tráfico público mediante HTTPS con certificados válidos y renovados. Implementa la cabecera Strict-Transport-Security con un periodo positivo (por ejemplo, max-age=31536000). Evita totalmente max-age=0, ya que anula la política HSTS según la RFC 6797 y desactiva la protección en visitas futuras.
Construir una política Content-Security-Policy restrictiva
Configura CSP en las cabeceras HTTP de respuesta para limitar la ejecución de scripts y recursos ajenos. Prohíbe directivas permisivas como 'unsafe-inline' y 'unsafe-eval', sustituyéndolas por nonces o hashes criptográficos, y acota frame-ancestors para controlar la integración en marcos.
Prevenir ataques de clickjacking y sniffing de tipos MIME
Define frame-ancestors en la CSP (junto a X-Frame-Options: DENY para navegadores antiguos) para bloquear la incrustación maliciosa en iframes de terceros. Añade obligatoriamente X-Content-Type-Options: nosniff para forzar al navegador a respetar los tipos MIME declarados.
Implementar aislamiento Cross-Origin y cabeceras de privacidad
El aislamiento cross-origin completo exige simultáneamente Cross-Origin-Opener-Policy: same-origin y Cross-Origin-Embedder-Policy: require-corp (o credentialless). Refuerza la seguridad con Referrer-Policy: strict-origin-when-cross-origin y una Permissions-Policy que desactive APIs innecesarias del navegador.
Comunicar con transparencia los límites de la auditoría de cabeceras
El análisis de cabeceras de respuesta es una comprobación fundamental de defensa en profundidad, pero no equivale a una prueba de penetración. Las vulnerabilidades en código backend, inyecciones en base de datos, autenticación y lógica de negocio exigen auditorías de seguridad específicas y continuas.