Guía completa de cabeceras HTTP de seguridad (2026)

Las cabeceras HTTP de seguridad son una de las medidas de hardening más efectivas y menos conocidas. Se configuran en 5 minutos y protegen tu web contra ataques reales: XSS, clickjacking, sniffing de contenido, downgrade a HTTP y fugas de información entre sitios.

En esta guía te explico las 5 cabeceras imprescindibles, para qué sirve cada una, cómo implementarlas con ejemplos reales y qué errores evitar.

1. ¿Qué son las cabeceras HTTP de seguridad?

Cuando un navegador pide una página web, el servidor responde con dos cosas: el contenido (HTML, CSS, JS...) y un conjunto de cabeceras HTTP que le dicen al navegador cómo comportarse. Esas cabeceras son invisibles para el usuario, pero definen el comportamiento de seguridad del sitio.

Las cabeceras de seguridad son instrucciones específicas que refuerzan la protección del usuario:

• Fuerzan HTTPS incluso si el usuario escribe http://.
• Bloquean scripts maliciosos inyectados por un atacante.
• Previenen clickjacking (que tu web se cargue dentro de otra).
• Controlan qué información se filtra cuando el usuario navega entre sitios.

2. Las 5 cabeceras imprescindibles

Las guías OWASP Secure Headers Project y los benchmarks PCI-DSS, ISO 27001 y ENS recomiendan estas cinco como mínimo:

1. Strict-Transport-Security (HSTS)
2. Content-Security-Policy (CSP)
3. X-Frame-Options
4. X-Content-Type-Options
5. Referrer-Policy

Vamos una por una.

3. HSTS — Strict-Transport-Security

Sin HSTS, un usuario que escribe tuweb.com en el navegador puede ser víctima de un ataque SSL stripping: el atacante intercepta la primera petición HTTP (antes de la redirección a HTTPS) y la mantiene en HTTP plano, robando cookies de sesión.

Con HSTS, el navegador recuerda que tu web solo debe cargarse por HTTPS y bloquea cualquier intento de conexión HTTP.

Ejemplo

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

Parámetros:

• max-age=31536000: 1 año en segundos. Durante ese tiempo, el navegador no permitirá HTTP.
• includeSubDomains: aplica también a subdominios.
• preload: solicita incluir tu dominio en la lista de preload de Chrome.

Recomendación: empieza con max-age=86400 (1 día), sube a 31536000 (1 año) cuando estés seguro, y luego añade preload.

4. CSP — Content Security Policy

CSP es la cabecera más potente y más compleja de todas. Permite crear una lista blanca de qué scripts, desde qué dominios, qué estilos y qué conexiones puede hacer el navegador. Si un atacante inyecta un script desde un dominio no autorizado, el navegador lo bloquea.

Ejemplo básico

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.tuweb.com; style-src 'self' 'unsafe-inline'

Directivas más comunes:

• default-src: política por defecto para todo.
• script-src: orígenes autorizados para JavaScript.
• style-src: orígenes autorizados para CSS.
• img-src: orígenes autorizados para imágenes.
• connect-src: orígenes autorizados para fetch/XHR/WebSocket.
• font-src: orígenes autorizados para fuentes web.
• frame-ancestors: qué webs pueden embeber tu web en un iframe.
• form-action: a qué URLs pueden enviar formularios.

CSP de ejemplo (buena base)

Content-Security-Policy:
    default-src 'self';
    script-src 'self' https://cdn.tuweb.com https://www.googletagmanager.com;
    style-src 'self' 'unsafe-inline';
    img-src 'self' data: https:;
    font-src 'self' https://fonts.gstatic.com;
    connect-src 'self' https://api.tuweb.com;
    frame-ancestors 'none';
    form-action 'self';
    base-uri 'self';
    upgrade-insecure-requests

Modo seguro para empezar:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://tuweb.com/csp-report

Así el navegador no bloquea nada, pero te envía un reporte con todo lo que bloquearía si estuviera activo. Tras una semana analizando reportes, quitas el -Report-Only y ya tienes una CSP segura.

5. X-Frame-Options

Clickjacking es un ataque en el que el atacante carga tu web dentro de un iframe invisible en su web, engañando al usuario para que haga clic en botones de tu web sin saberlo (por ejemplo, "Confirmar transferencia").

X-Frame-Options le dice al navegador si tu web puede o no cargarse dentro de un iframe.

Valores posibles

• DENY: nunca permitir iframes. Máxima seguridad.
• SAMEORIGIN: permitir iframes solo desde tu mismo dominio.
• ALLOW-FROM https://ejemplo.com: permitir solo desde un dominio específico (obsoleto, poco soportado).

Ejemplo

X-Frame-Options: SAMEORIGIN

Recomendación: SAMEORIGIN para la mayoría de webs. DENY solo si tu web no se embebe nunca.

Equivalente moderno en CSP:

Content-Security-Policy: frame-ancestors 'self'

Se recomienda poner ambas para compatibilidad con navegadores antiguos.

6. X-Content-Type-Options

Los navegadores antiguos intentaban "adivinar" el tipo de un fichero (MIME sniffing) cuando el servidor no declaraba un Content-Type válido. Esto permitía ataques: subir un fichero .jpg que en realidad es HTML+JavaScript ejecutable.

Con esta cabecera, el navegador deja de adivinar y respeta estrictamente el Content-Type declarado.

Ejemplo

X-Content-Type-Options: nosniff

El único valor válido es nosniff. Es la cabecera más fácil de implementar y no rompe nada. No hay excusa para no tenerla.

7. Referrer-Policy

Cuando un usuario hace clic en un enlace de tu web, el navegador envía al sitio de destino una cabecera Referer con la URL desde la que vino. Esa URL puede contener información sensible: tokens de sesión, IDs de usuario, rutas internas...

Referrer-Policy controla cuánta información se envía.

Valores más usados

• no-referrer: nunca enviar Referer.
• same-origin: solo enviar dentro del mismo dominio.
• strict-origin: enviar solo el origen (sin ruta), y solo si es HTTPS.
• strict-origin-when-cross-origin: la opción recomendada por defecto.
• no-referrer-when-downgrade: navegador por defecto antiguo (menos seguro).

Ejemplo

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

Recomendación: strict-origin-when-cross-origin. Es el estándar moderno que respeta la privacidad sin romper el tracking analítico que necesitan muchas webs.

8. Tabla resumen

9. Cómo implementarlas

Apache

En el fichero .htaccess o en la configuración del VirtualHost:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Content-Security-Policy "default-src 'self'; frame-ancestors 'none'"
</IfModule>

Nginx

En el bloque server de tu configuración:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'none'" always;

Cloudflare (sin tocar el servidor)

Cloudflare permite añadir cabeceras desde el panel: Rules → Transform Rules → Modify Response Header. Añades una regla que se aplique a tudominio.com/* e inyectas las cabeceras que quieras. Ideal si no tienes acceso al servidor.

PHP

header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
header('X-Frame-Options: SAMEORIGIN');
header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');

Node.js / Express

La forma más sencilla es usar el paquete helmet:

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

Helmet añade automáticamente 11 cabeceras de seguridad, incluyendo las 5 de esta guía.

10. Errores comunes

Error 1 · Activar HSTS antes de tener SSL renovable

Si activas HSTS con max-age=31536000 y tu certificado caduca, tu web quedará inaccesible durante un año para los usuarios que ya visitaron el sitio. Configura renovación automática (Let's Encrypt, Cloudflare SSL) antes de activar HSTS.

Error 2 · CSP demasiado estricta desde el primer día

Una CSP con default-src 'none' romperá tu web. Usa Content-Security-Policy-Report-Only durante 1-2 semanas y analiza los reportes antes de activar la política real.

Error 3 · Olvidar la cabecera always en Nginx

En Nginx, las cabeceras solo se aplican a respuestas 200 por defecto. Si tu web devuelve errores 404 o redirecciones, las cabeceras no se envían. Añade siempre always al final.

Error 4 · Confiar solo en X-Frame-Options

X-Frame-Options está obsoleta en favor de frame-ancestors de CSP. Pon las dos para máxima compatibilidad.

Error 5 · No verificar que se aplican

Muchas webs configuran las cabeceras pero solo en la home, olvidando las rutas internas, los assets o las APIs. Verifica todas las rutas.

11. Cómo verificar que las tienes

Tienes varias opciones:

1. Con la auditoría gratuita de Sealgrade: en 30 segundos te dice si tienes las 5 cabeceras y cuáles te faltan.
2. Con curl desde terminal:

   curl -I https://tuweb.com

   Verás todas las cabeceras HTTP que devuelve tu servidor.
3. Con DevTools del navegador: F12 → Network → clic en la primera petición → Headers → Response Headers.
4. Con Security Headers de Scott Helme: securityheaders.com da una nota A+ a F.

Conclusión

Las cabeceras HTTP de seguridad son una de las mejoras más rápidas y efectivas que puedes hacer. En 5 minutos proteges tu web contra ataques reales y subes tu Health Score de forma notable.

El resumen en 5 líneas:

1. Empieza con las 3 fáciles: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin.
2. Añade HSTS solo si tienes renovación SSL automática.
3. CSP con Report-Only durante 1-2 semanas.
4. Verifica con Sealgrade o curl -I.
5. Repite para todas las rutas (home, subpáginas, APIs).