En la mayoría de organizaciones, las cabeceras de seguridad se configuran “a ojo”: un plugin aquí, un snippet allá y, con el tiempo, inconsistencias entre la web corporativa, WordPress, SPAs y APIs. El resultado es predecible: exposición evitable a XSS, clickjacking, fugas de información o degradaciones a HTTP por configuraciones incompletas.

Esta guía propone un baseline estandarizado: un set coherente de cabeceras, verificable (con criterios claros) y aplicable por rutas para que puedas desplegarlo con control, medir impacto y endurecer progresivamente sin romper funcionalidades.

📌 Guía completa: Seguridad WordPress (checklist + prioridades).

✅ Acción rápida: Iniciar auditoría gratis y recibir evidencias en minutos.

1) Qué son y qué alcance tienen

Las cabeceras HTTP de seguridad son directivas que el servidor entrega al navegador para forzar políticas de protección. Su valor reside en que actúan en el cliente (navegador), limitando superficies de ataque habituales.

Lo que sí mitigamos:

  • Cargas de recursos no autorizadas (según política).
  • Enmarcado en iframes (clickjacking).
  • Conexiones accidentales por HTTP cuando debería ser HTTPS.
  • Fugas de referrer y ciertos vectores de interpretación de contenido.

Lo que no sustituyen:

  • Saneamiento de entradas, control de acceso, hardening del servidor, ni corrección de vulnerabilidades en backend.
  • Una configuración TLS correcta y mantenida.
  • Un proceso de gestión de dependencias y parches.

2) Principios de implementación (estándar corporativo)

  1. Prioridad por impacto y reversibilidad
    • Primero cabeceras “seguras y estables” (nosniff, referrer-policy, frame protection).
    • Después políticas “potentes pero sensibles” (CSP, COOP/COEP).
  2. Aplicación consistente por rutas
    • No siempre conviene “mismo set” para todo.
    • Ejemplo: el panel de administración o una SPA pueden requerir CSP distinta a un blog.
  3. Despliegue controlado
    • CSP: comenzar en modo Report-Only (si se habilitan reportes) y pasar a enforced tras validar.
    • COOP/COEP: habilitar por aplicación/páginas concretas, evaluando terceros.
  4. Evitar contradicciones
    • Si usamos CSP frame-ancestors, debemos mantener coherencia con X-Frame-Options.

3) Cabeceras base recomendadas (baseline “mínimo serio”)

3.1 Strict-Transport-Security (HSTS)

Propósito: forzar HTTPS en visitas futuras y reducir downgrade/MITM.

Recomendación estándar (si todo el sitio y subdominios están en HTTPS estable):

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

Notas operativas:

  • includeSubDomains solo si todas las subzonas tienen HTTPS correcto.
  • preload es una decisión estratégica (difícil de revertir). Solo se recomienda cuando existe plena certeza.

3.2 X-Content-Type-Options

Propósito: evitar MIME sniffing (interpretaciones peligrosas del navegador).

X-Content-Type-Options: nosniff

3.3 Referrer-Policy

Propósito: reducir fuga de URL completas hacia terceros.

Recomendación equilibrada:

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

3.4 Protección anti-clickjacking

Opción A (clásica):

X-Frame-Options: DENY

Opción B (preferente en entornos modernos): usar CSP frame-ancestors (ver CSP).
Si mantenemos ambas, debemos asegurar que no se contradigan.

4) Content-Security-Policy (CSP): estándar seguro y desplegable

CSP es la cabecera más potente y, a la vez, la que más rompe cosas si se aplica sin análisis. Recomendamos un enfoque por fases.

4.1 CSP inicial (conservadora y útil)

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; upgrade-insecure-requests

Qué aporta este baseline:

  • Bloquea plugins peligrosos (object-src 'none').
  • Impide cambio de base URL malicioso (base-uri 'self').
  • Evita embedding en iframes (frame-ancestors 'none').
  • Eleva cargas HTTP a HTTPS cuando sea posible (upgrade-insecure-requests).

4.2 CSP con terceros (realista)

Si usamos analítica, tag managers, chats, YouTube, fuentes externas, etc., debemos incorporar dominios explícitos. Ejemplo orientativo (no universal):

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Advertencias:

  • style-src 'unsafe-inline' se utiliza con frecuencia por compatibilidad (frameworks/temas), pero no es ideal.
  • Para endurecer, se recomienda migrar a nonces/hashes en scripts inline y minimizar inline.

4.3 Despliegue recomendado de CSP

  • Fase 1: Content-Security-Policy-Report-Only (si se dispone de endpoint de reportes).
  • Fase 2: endurecer reglas y eliminar permisos excesivos.
  • Fase 3: pasar a Content-Security-Policy (enforced).

5) Cabeceras avanzadas (según aplicación y dependencia de terceros)

Estas cabeceras son especialmente relevantes en apps modernas que buscan aislamiento robusto.

5.1 COOP (Cross-Origin-Opener-Policy)

Cross-Origin-Opener-Policy: same-origin

5.2 COEP (Cross-Origin-Embedder-Policy)

Cross-Origin-Embedder-Policy: require-corp

5.3 CORP (Cross-Origin-Resource-Policy)

Cross-Origin-Resource-Policy: same-origin

Riesgo operativo: COOP/COEP/CORP pueden romper integraciones con recursos de terceros que no ofrezcan CORS/CORP adecuados. Recomendamos habilitarlas por rutas o por aplicaciones donde haya control total del ecosistema de recursos.

6) Cabeceras complementarias recomendables

6.1 Permissions-Policy

Propósito: limitar APIs del navegador (cámara, micrófono, geolocalización, etc.) cuando no son necesarias.

Permissions-Policy: camera=(), microphone=(), geolocation=()

6.2 Clear-Site-Data (para logout o incident response)

Propósito: limpieza de cookies/storage/cache bajo escenarios controlados.

Clear-Site-Data: "cache", "cookies", "storage"

6.3 Reducción de fingerprinting (hardening)

Recomendamos evitar exponer tecnología/versión en cabeceras (p. ej. Server, X-Powered-By) cuando el stack lo permita.

7) Set estandarizado recomendado (lista final)

Baseline corporativo (recomendado para la mayoría)

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; upgrade-insecure-requests

Endurecimiento avanzado (bajo control de terceros)

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

8) Ejemplos de configuración (Nginx / Apache)

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "DENY" always;

add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; upgrade-insecure-requests" always;

Apache (mod_headers)

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Frame-Options "DENY"

Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; upgrade-insecure-requests"

9) Validación y control de calidad

Verificación rápida

  • curl -I https://dominio.tld (comprobar presencia y valores).
  • DevTools → Network → Response Headers (confirmar por ruta).

Criterios de aceptación (QA)

  • No existen recursos críticos bloqueados tras aplicar CSP.
  • No hay contenido mixto (si lo hay, upgrade-insecure-requests puede enmascarar parcialmente; conviene corregir origen).
  • HSTS no rompe subdominios (si se usa includeSubDomains).
  • No hay contradicción entre XFO y CSP frame-ancestors.

10) Errores comunes que debemos evitar

  1. HSTS con includeSubDomains sin inventario de subdominios (riesgo de indisponibilidad).
  2. CSP excesivamente permisiva (pierde valor) o excesivamente estricta sin fase de transición (rompe funcionalidades).
  3. Aplicar COOP/COEP “a ciegas” en sitios con múltiples terceros (roturas inesperadas).
  4. No separar por rutas (admin/app/api suelen requerir políticas distintas).