Cabeceras de seguridad HTTP: qué son y cómo comprobarlas

Puede que te haya llegado un informe de auditoría lleno de líneas en rojo con nombres como Strict-Transport-Security o Content-Security-Policy, o que un cliente te haya pedido que tu web «pase el test de cabeceras». La buena noticia es que esto se arregla en un rato y sin tocar el contenido de la web: son instrucciones que el servidor manda al navegador junto a cada página. La mala es que circula mucha guía antigua y es fácil acabar poniendo cabeceras que ya no sirven, o una tan estricta que te rompe la tienda. Vamos a ver qué cabeceras importan hoy, cómo comprobar en dos minutos cuáles tiene tu web y dónde se configuran según tu servidor.

Qué es una cabecera de respuesta y por qué el navegador le hace caso

Cuando alguien entra en tu web, el servidor no manda solo el HTML. Antes envía un bloque de texto con datos sobre esa respuesta: el tipo de contenido, la fecha, la caché y, si las has configurado, unas cuantas cabeceras de seguridad. El navegador las lee antes de pintar nada y ajusta su comportamiento en consecuencia.

Esa es toda la magia. No hay ningún componente vigilando ni ningún cortafuegos: le estás diciendo al navegador de tu visitante «para esta web, aplícate estas reglas», y obedece porque forma parte de los estándares web. Una cabecera bien puesta protege igual en Chrome, Firefox, Safari y Edge, sin instalar nada.

Lo importante que hay que entender desde el principio: las cabeceras protegen al visitante frente a ciertos abusos dentro del navegador. No protegen el servidor. Volveremos a esto al final, porque es la confusión que más dinero hace perder.

Las cabeceras que sí importan hoy (y las que ya están obsoletas)

Estas son las que tienen sentido en una web corporativa o una tienda española:

Strict-Transport-Security (HSTS). Obliga al navegador a usar siempre HTTPS con tu dominio, aunque alguien teclee la dirección sin https://. Elimina esa primera petición en claro que se podría interceptar en una red wifi pública. Tiene un detalle importante: una vez enviada, el navegador la recuerda durante el tiempo que indiques, así que conviene entender el max-age y la lista de precarga antes de subirlo, algo que desglosamos en la guía sobre qué es HSTS y cómo activarlo sin bloquearte el dominio.
Content-Security-Policy (CSP). La más potente y la más delicada: declara de qué orígenes puede cargar tu web scripts, estilos, imágenes o tipografías. Es la que de verdad limita el daño si alguien consigue inyectar un script en tus páginas. También es la que más fácilmente rompe cosas si la copias sin pensar, por eso tiene artículo propio sobre cómo montar una Content Security Policy sin cargarte la web.
X-Content-Type-Options: nosniff. Impide que el navegador adivine el tipo de un fichero e interprete como script algo que tú sirves como texto o como imagen. Es una línea, no rompe nada y siempre se pone.
Referrer-Policy. Controla cuánta información de la dirección de origen viaja cuando alguien hace clic para salir de tu web. Con strict-origin-when-cross-origin evitas filtrar rutas internas y parámetros a terceros.
Permissions-Policy. Declara qué funciones del navegador puede usar tu web: cámara, micrófono, geolocalización. Si tu web no necesita ninguna, desactivarlas cierra una vía de abuso a un script inyectado.
X-Frame-Options o, mejor, la directiva frame-ancestors dentro de CSP. Impiden que otra web meta la tuya dentro de un marco invisible para engañar a tus usuarios. Ese ataque tiene nombre y remedio propio: lo explicamos en el artículo sobre qué es el clickjacking y cómo se bloquea con X-Frame-Options.

Y estas ya no las pongas, aunque las veas en tutoriales de hace unos años:

X-XSS-Protection. Activaba un filtro que los navegadores modernos han retirado, y que en algunos escenarios llegó a introducir problemas propios. Hoy no aporta nada: ese trabajo lo hace CSP.
Expect-CT. Obsoleta. La transparencia de certificados ya se comprueba por defecto.
Public-Key-Pins (HPKP). Retirada y peligrosa: un error de configuración podía dejar el dominio inaccesible durante meses sin forma práctica de revertirlo.

Si tu informe de auditoría te reclama alguna de estas tres, el informe es viejo, o lo es la herramienta que lo generó.

Cómo ver las cabeceras de tu web en dos minutos

Tienes tres formas, de menos a más técnica.

Con el navegador

Abre tu web en Chrome, pulsa F12 para abrir las herramientas de desarrollador, ve a la pestaña Network (Red), recarga la página con F5, haz clic en la primera línea de la lista (la de tu dominio) y mira el bloque Response Headers. Ahí está todo lo que manda tu servidor.

Con la línea de comandos

Si tienes acceso a una terminal, una sola orden te lo enseña:

curl -sSI https://tudominio.es

Y si quieres seguir las redirecciones y quedarte solo con lo relevante:

curl -sSIL https://tudominio.es | grep -i -E "strict-transport|content-security|x-content-type|referrer-policy|permissions-policy|x-frame"

Si esa segunda orden no devuelve ninguna línea, es que no tienes puesta ninguna cabecera de seguridad.

Con un analizador externo

Hay servicios que puntúan las cabeceras de un dominio. Interpreta la nota con cabeza: premia tener cabeceras, no tenerlas ajustadas a tu web. Una nota alta con una CSP que en realidad lo permite todo no significa gran cosa.

Dónde se configuran: Apache, nginx, Cloudflare o plugin de WordPress

Depende de dónde viva tu web. Elige el punto más alto de la cadena al que tengas acceso y ponlas solo ahí, para no acabar con la misma cabecera duplicada y en conflicto.

Hosting compartido con cPanel o Plesk (Apache)

Se editan en el fichero .htaccess de la raíz de tu web, normalmente en /public_html/.htaccess. Descarga una copia del fichero antes de tocarlo. Añade el bloque al final, fuera de las marcas # BEGIN WordPress y # END WordPress, porque WordPress reescribe esa parte cuando le da la gana:

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

Guarda y recarga la web. Si te sale un error 500, tu servidor no tiene activado el módulo mod_headers: restaura la copia del fichero y pregunta a tu hosting. He dejado fuera HSTS y CSP a propósito: esas dos merecen leerse antes de activarlas.

Servidor propio o VPS con nginx

Van dentro del bloque server del fichero de tu sitio, habitualmente en /etc/nginx/sites-available/:

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Comprueba la sintaxis con nginx -t antes de recargar con systemctl reload nginx. Ojo con una trampa clásica de nginx: si defines un add_header dentro de un bloque location, se anulan todos los add_header heredados del nivel superior en ese bloque. Es la causa número uno del «las tengo puestas pero no salen».

Con Cloudflare delante

Si tu dominio pasa por Cloudflare, puedes añadir cabeceras de respuesta con sus reglas de transformación sin tocar el servidor, y algunas ya vienen como opción gestionada con un interruptor. Es cómodo y reversible, pero recuerda que si alguien accede al servidor de origen directamente por su IP, esas cabeceras no se aplican.

Desde WordPress

Es la opción menos recomendable, porque PHP se ejecuta después y no cubre los ficheros estáticos, pero existe. Varios plugins de seguridad lo ofrecen en su apartado de refuerzo, y también puede hacerse desde el tema hijo con el hook send_headers. Si tienes acceso al .htaccess, hazlo ahí y olvídate.

El error de copiar las cabeceras de otra web

Es tentador: miras las cabeceras de una web grande, las copias tal cual y ya tienes la nota alta. Y es exactamente así como se rompen los formularios, los mapas incrustados, la pasarela de pago o el chat de soporte.

El motivo es que las dos cabeceras potentes, CSP y Permissions-Policy, describen qué recursos externos usa esa web concreta. Si tú cargas tipografías de Google, un vídeo incrustado, un píxel de publicidad y una pasarela de pago, tu política tiene que contemplarlos todos. La de otro no los contempla, así que el navegador los bloqueará en silencio: la web parecerá cargada, pero el botón de pagar no hará nada y nadie te avisará.

La forma correcta es por fases: primero se publica en modo informe (Content-Security-Policy-Report-Only), se navega por la web durante unos días mirando los avisos en la consola del navegador, se apuntan los orígenes que reclama, se añaden a la política y solo entonces se activa en modo bloqueo. Requiere paciencia, pero es la diferencia entre proteger la web y sabotearla.

Qué NO arreglan las cabeceras (y por qué no bastan)

Aquí toca ser honestos, porque con esto se vende bastante humo. Las cabeceras de seguridad no:

Impiden que exploten un plugin desactualizado.
Detienen un ataque de fuerza bruta contra wp-login.php.
Eliminan una puerta trasera que ya esté subida en wp-content/uploads/.
Evitan que alguien entre con una contraseña robada.
Limpian una web que ya está comprometida.

Una web con las seis cabeceras perfectas y un plugin sin actualizar desde hace dos años sigue siendo una web que acabarán comprometiendo. Las cabeceras son la última capa, la que limita el daño hacia el visitante cuando algo ya ha fallado antes. La primera capa es el mantenimiento, los accesos y las copias de seguridad, y ese orden completo está desarrollado en la guía de configuración segura de una web: hosting, HTTPS, correo y DNS.

Dicho lo cual, cuestan una tarde y no caducan. Son de las pocas cosas en seguridad web que haces una vez y siguen trabajando solas durante años.

Por dónde empezar si solo vas a poner una

Si hoy solo vas a hacer un cambio, pon X-Content-Type-Options: nosniff: es una línea, no rompe absolutamente nada y cierra un abuso real. Si vas a hacer dos, añade Referrer-Policy. Con esas dos y el X-Frame-Options del ejemplo de arriba tienes cubierto lo fácil en diez minutos y sin riesgo.

HSTS es el siguiente paso lógico, siempre que tu HTTPS funcione bien en el dominio y en todos sus subdominios. Y CSP la dejas para cuando tengas una tarde tranquila y puedas hacer la fase de informe. Nadie sensato monta una CSP un viernes por la tarde en una tienda que está facturando.

Y una consideración honesta: si tu web la lleva una agencia, esto entra en lo que deberían haber dejado hecho, y pedírselo no debería costarte un euro. Si la llevas tú, tampoco necesitas contratar a nadie para poner tres líneas en un fichero.

Cuando termines, verifícalo desde fuera, no desde el navegador donde llevas media hora recargando con la caché caliente. Pasa PathScan a tu dominio y mira qué cabeceras te faltan: es gratuito, no pide registro y no toca la web, solo la mira como la vería cualquier visitante. Verás las cabeceras que estás enviando de verdad y, de paso, cómo está el certificado y qué más se ve de tu dominio desde el exterior.

Seguir leyendo en esta sección

Ver todo en Endurecer tu web → · Mapa completo del sitio