Los headers de seguridad son cabeceras de respuesta HTTP que instruyen a los navegadores a aplicar politicas de seguridad, protegiendo las aplicaciones web contra XSS, clickjacking, sniffing de tipos MIME y otros ataques comunes con un esfuerzo minimo de implementacion. Segun Mozilla Web Security Observatory, solo el 35% de los sitios web implementa correctamente la Content Security Policy (CSP), y el 45% carece de HTTP Strict Transport Security (HSTS). Segun OWASP, los headers de seguridad faltantes o mal configurados son responsables de aproximadamente el 30% de las vulnerabilidades de seguridad en aplicaciones web encontradas durante pruebas de penetracion. Las pruebas automatizadas con Mozilla Observatory o scripts de Playwright proporcionan validacion reproducible.

TL;DR: Prueba 8 headers de seguridad criticos: Content-Security-Policy, Strict-Transport-Security (HSTS), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Resource-Policy y Cross-Origin-Opener-Policy. Usa Mozilla Observatory, SecurityHeaders.com o pruebas automatizadas en tu pipeline CI/CD. Apunta a calificacion A+ en Mozilla Observatory.

Headers Esenciales

1. Content-Security-Policy (CSP) 

Content-Security-Policy: default-src 'self'; script-src 'self'

2. Strict-Transport-Security (HSTS) 

Strict-Transport-Security: max-age=31536000; includeSubDomains

3. X-Frame-Options 

X-Frame-Options: DENY

“Security headers are the easiest security wins a web team can implement — CSP, HSTS, and X-Frame-Options take an hour to configure but protect against entire classes of attacks that take years to discover in code.” — Yuri Kan, Senior QA Lead

Testing 

def test_security_headers():
    response = requests.get("https://example.com")

    assert 'Content-Security-Policy' (como se discute en [OWASP ZAP Automation: Security Scanning in CI/CD](/es/blog/owasp-zap-automation)) in response.headers
    assert 'Strict-Transport-Security' (como se discute en [Penetration Testing Basics for QA Testers](/es/blog/penetration-testing-basics)) in response.headers
    assert 'X-Frame-Options' in response.headers

Herramientas

  • SecurityHeaders.com
  • Mozilla Observatory
  • Custom scripts

Implementación

Node.js 

const helmet = require('helmet');
app.use(helmet());

Nginx 

add_header Content-Security-Policy "default-src 'self'" always;
add_header Strict-Transport-Security "max-age=31536000" always;

Conclusión

Los security headers son capa de defensa crucial. Testing regular asegura implementación correcta y protección contra vulnerabilidades web comunes.

FAQ

Cuales son los security headers mas criticos para implementar primero?

Comienza con Strict-Transport-Security (HSTS) para forzar HTTPS, Content-Security-Policy (CSP) para prevenir ataques XSS y X-Frame-Options en DENY para bloquear clickjacking. Estos tres headers protegen contra los vectores de ataque mas comunes. Luego agrega X-Content-Type-Options: nosniff y Referrer-Policy: strict-origin-when-cross-origin. Apunta a calificacion A+ en Mozilla Observatory como referencia.

Como pruebo security headers en un pipeline CI/CD?

Agrega verificaciones automaticas de headers a tu flujo CI/CD usando pytest con la libreria requests para validar cada header requerido. Alternativamente, usa la API de SecurityHeaders.com o Mozilla Observatory para calificacion automatizada. Ejecuta estas verificaciones contra tu entorno de staging despues de cada despliegue. Falla el pipeline si headers criticos como HSTS o CSP faltan o estan mal configurados.

Que es Content Security Policy y por que es dificil de implementar?

Content Security Policy (CSP) es un header HTTP que indica a los navegadores que fuentes de contenido pueden cargarse en tu pagina, previniendo efectivamente ataques XSS. Es dificil porque un CSP demasiado estricto rompe funcionalidad legitima (scripts inline, widgets de terceros), mientras que uno demasiado permisivo ofrece poca proteccion. Comienza con CSP en modo report-only para identificar violaciones sin romper tu sitio, luego ajusta las directivas progresivamente.

Debo eliminar los headers X-Powered-By y Server?

Si, siempre elimina o minimiza los headers que revelan informacion. X-Powered-By revela tu stack tecnologico (PHP, Express), y los headers Server detallados exponen la version de tu servidor web (Apache/2.4.51). Los atacantes usan esta informacion para apuntar a vulnerabilidades conocidas en versiones especificas. En Nginx, establece server_tokens off. En Express, usa el middleware helmet que elimina X-Powered-By por defecto.

Recursos Oficiales

See Also