Security headers checklist 2026 — CSP, HSTS, X-Frame, Referrer-Policy y más

Respuesta rápida

Security headers son la primera línea de defensa contra XSS, clickjacking, MITM y info leaks. Audit mínimo en 2026: CSP (con frame-ancestors + sin unsafe-inline), HSTS (preload + includeSubDomains), X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, Cookies Secure + HttpOnly + SameSite=Lax, Permissions-Policy explícita. Reports de headers solos suelen ser info/low (€50-€200), pero como chain con otro bug pueden disparar la severity 2 niveles.

Tabla completa — headers que mirar

Content-Security-Policy — el header rey

CSP es el más complejo y el más impactante. Una CSP mal hecha pasa todos los XSS; una CSP bien hecha bloquea incluso XSS reflejados.

Ejemplo de CSP correcta (SPA moderna)

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-RANDOM123' https://js.stripe.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' data:;
  connect-src 'self' https://api.target.com wss://ws.target.com;
  frame-src https://js.stripe.com https://hooks.stripe.com;
  frame-ancestors 'none';
  form-action 'self';
  base-uri 'self';
  object-src 'none';
  upgrade-insecure-requests;
  report-uri /csp-report

Errores que matan la CSP

[!danger] frame-ancestors NO es suficiente frame-ancestors 'none' previene iframing tradicional, pero no previene window.open() popups con clickjacking via UI confusion. Para cerrar el vector completo: añade Cross-Origin-Opener-Policy: same-origin + verificación de window.top === window.self en JS crítico.

Test CSP

# Ver el header
curl -sI https://target.com | grep -i content-security

# Evaluator oficial Google
# Pega la CSP en https://csp-evaluator.withgoogle.com/

# Buscar bypasses según las whitelisted domains
# https://github.com/PortSwigger/csp-bypass

HSTS — el header simple pero crítico

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

Preload list

Inscríbete en hstspreload.org. Requisitos:

• Servir HSTS con max-age >= 31536000, includeSubDomains, preload.
• Redirect HTTP → HTTPS en root + en todos los subdomains.
• Soportar HTTPS en todos los subdomains (incluso mail.target.com).

Cookies — los flags que cuentan

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

[!tip] SameSite Lax vs Strict en 2026 Chrome y Firefox ya hacen SameSite=Lax por default si no se especifica. Pero todavía hay endpoints en frameworks viejos que setean sin SameSite explícito → reportable. Strict rompe flows de OAuth/SSO porque la cookie no llega tras redirect → Lax es el sweet spot.

Referrer-Policy — el leak silencioso

Referrer-Policy: strict-origin-when-cross-origin

Sin esta header, el browser envía el Referer completo (incluyendo path + query) a cualquier sitio externo al que linkees. Resultado: tokens de password reset, session IDs en query, OAuth codes — todos filtrados a third-parties.

Reportable

URLs con tokens en query (?reset_token=, ?session=, ?code=) + sin Referrer-Policy restrictiva → al user hacer click en link externo, token se filtra al third-party. Severity Medium si el token sigue siendo válido.

Permissions-Policy — el moderno (ex Feature-Policy)

Antes era Feature-Policy. Renamed a Permissions-Policy en 2020+ y soporta más APIs.

Permissions-Policy:
  camera=(),
  microphone=(),
  geolocation=(),
  payment=(self),
  usb=(),
  accelerometer=(),
  gyroscope=(),
  magnetometer=(),
  interest-cohort=()

• camera=() → ningún origen puede acceder.
• camera=(self) → sólo same-origin.
• camera=(self "https://trusted.com") → same-origin + ese específico.
• interest-cohort=() → opt-out de FLoC/Topics API tracking.

Reportable si la app embedded en iframe puede activar mic/camera/geolocation sin que el usuario lo espere → defense in depth.

COEP / COOP / CORP — cross-origin isolation

Necesarios para usar SharedArrayBuffer, performance.now() de alta precisión, y mitigar Spectre/Meltdown.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin

• COOP same-origin: tu window no comparte browsing context con popups cross-origin → cierra window.opener attacks.
• COEP require-corp: todos los recursos cargados deben tener Cross-Origin-Resource-Policy o CORS. Activa "cross-origin isolation".
• CORP same-origin: tus recursos sólo pueden ser cargados desde same-origin.

[!info] Cuándo activarlos Si tu app usa SharedArrayBuffer (WebAssembly, threading), necesitas COOP+COEP. Si tu app NO los usa, COOP same-origin es win gratuito para cerrar window.opener attacks. COEP rompe muchas apps third-party — implementar con cuidado.

Cómo testear todo de una

Herramientas

# CLI rápido
curl -sI https://target.com

# Online — el estándar de facto
# https://securityheaders.com/?q=target.com
# https://observatory.mozilla.org/analyze/target.com

# CSP específico
# https://csp-evaluator.withgoogle.com/

Script manual de audit

#!/bin/bash
URL="$1"

echo "=== Headers de $URL ==="
curl -sI "$URL" | grep -iE "(strict-transport|content-security|x-content-type|x-frame|referrer-policy|permissions-policy|cross-origin|set-cookie)"

echo -e "\n=== Cookies analysis ==="
curl -sI "$URL" | grep -i "set-cookie:" | while read -r line; do
    name=$(echo "$line" | sed 's/.*Set-Cookie: \([^=]*\)=.*/\1/i')
    flags=""
    echo "$line" | grep -qi "HttpOnly" || flags+="[NO HttpOnly] "
    echo "$line" | grep -qi "Secure" || flags+="[NO Secure] "
    echo "$line" | grep -qi "SameSite" || flags+="[NO SameSite] "
    [ -n "$flags" ] && echo "Cookie '$name': $flags"
done

Cómo reportarlo (sin ser low-info spam)

Headers sueltos casi siempre son info / low. Para que el report tenga valor:

1. No mandes 10 reports separados. Un report con tabla de headers faltantes + impacto agregado.
2. Demuestra impacto real. "CSP permite unsafe-inline" no es accionable. "CSP permite unsafe-inline Y existe un reflected XSS en /search → bypass directo" → Medium.
3. Chain con otro bug. Header faltante + bug funcional = severity disparada.
4. Bug bounty programs específicos. Algunos (Shopify, GitHub) explícitamente dicen "Missing security headers = N/A". Lee el scope.

Template de report headers

## Summary
La aplicación carece de las siguientes security headers, exponiendo a usuarios a clickjacking, XSS amplificado y leak de tokens via Referer.

## Headers afectados
| Header | Esperado | Actual |
|---|---|---|
| CSP | `default-src 'self'; frame-ancestors 'none'` | Ausente |
| HSTS | `max-age=31536000; includeSubDomains` | `max-age=300` |
| X-Frame-Options | `DENY` | Ausente |

## Impact
- Sin CSP: cualquier XSS reflejado/stored ejecuta sin restricción.
- HSTS débil: ventana de 5 min para MITM downgrade.
- Sin X-Frame-Options: clickjacking en /transfer endpoint posible.

## PoC clickjacking
[HTML con iframe del /transfer endpoint + overlay malicioso]

Hunting checklist

• curl -sI al target → listar todos los response headers
• securityheaders.com para grade objetivo (A+ es target)
• CSP en csp-evaluator.withgoogle.com → buscar unsafe-inline, unsafe-eval, * whitelisted
• HSTS: max-age >= 31536000 + includeSubDomains + preload
• Cookies de auth: Secure + HttpOnly + SameSite=Lax|Strict
• Referrer-Policy presente y restrictiva
• X-Frame-Options o CSP frame-ancestors en TODAS las pages
• Permissions-Policy disabling APIs no usadas
• COOP same-origin mínimo en pages auth-críticas
• Cache-Control en endpoints autenticados: no-store, private
• Probar chain con XSS/CSRF/clickjacking para subir severity

Labs relacionados

Practica explotación de aplicaciones con headers mal configurados y chains de XSS → CSP bypass en labs de Security Headers.