Cabeceras de seguridad HTTP: ¿cuáles necesita tu web?

Cada vez que alguien abre una página de tu web, el servidor no envía solo el HTML. Antes manda un bloque de cabeceras: líneas de texto que el visitante no ve y que le dicen al navegador cómo tratar lo que viene detrás. Algunas hablan de caché o de idioma. Otras, las de seguridad, le dan instrucciones del tipo «no cargues esta web por http», «no dejes que otra página me meta en un marco» o «no ejecutes scripts de orígenes que no conozco».

Ninguna de ellas arregla un sitio mal programado. Lo que hacen es cerrar puertas que el navegador deja abiertas por defecto, y son de las pocas mejoras de seguridad que se configuran una vez, en el servidor, sin tocar el código de la web.

¿Por qué el navegador no se protege solo?

Porque la web nació permisiva y los navegadores tienen que seguir mostrando sitios de hace veinte años. Si mañana bloquearan los marcos de terceros o los scripts en línea, se romperían millones de páginas. Así que la decisión se delega en quien sirve la web: tú dices qué restricciones acepta tu sitio y el navegador las aplica.

Eso explica también por qué faltar una cabecera no produce ningún error visible. La web funciona igual; simplemente queda expuesta a ataques que con una línea de configuración estarían cerrados.

HSTS: siempre por https

Strict-Transport-Security le dice al navegador que, durante un tiempo, solo debe entrar a tu dominio por https. Aunque alguien escriba la dirección con http o siga un enlace antiguo, el navegador cambia a https antes de hacer la petición.

La diferencia con una simple redirección de http a https es sutil pero importante: con la redirección, la primera petición sigue saliendo sin cifrar, y en una red wifi pública alguien podría interceptarla. Con HSTS, a partir de la segunda visita esa petición ya no existe.

Un valor típico es max-age=31536000; includeSubDomains: un año, y también para los subdominios.

¿Qué es la lista de precarga?

HSTS tiene un hueco: la primera visita. El navegador no sabe que tu dominio exige https hasta que lo ha visitado una vez. Para cerrarlo existe la lista de precarga, que los navegadores llevan incorporada. Para entrar hace falta un max-age de al menos un año, includeSubDomains, la directiva preload y que todo el dominio funcione por https.

Conviene pensarlo dos veces: salir de la lista tarda meses, y cualquier subdominio que aún dependa de http (un panel antiguo, una herramienta interna) dejará de abrirse.

CSP: de dónde puede venir el código

Content-Security-Policy es la más potente y la más delicada. Define una lista de orígenes permitidos para scripts, estilos, imágenes, fuentes o marcos. Si alguien consigue inyectar código en tu página, por un formulario mal filtrado o un plugin vulnerable, el navegador se niega a ejecutarlo porque no viene de un origen autorizado.

El problema es que una web real carga cosas de muchos sitios: analítica, chat, mapas, vídeos, fuentes. Una política demasiado estricta los bloquea a todos, y una demasiado laxa (default-src * o 'unsafe-inline' en script-src) existe pero no protege. Por eso una CSP se construye por fases, nunca de golpe.

X-Frame-Options y frame-ancestors: contra el clickjacking

El clickjacking consiste en cargar tu web dentro de un marco invisible en otra página y engañar al usuario para que haga clic donde no cree. Si tu sitio tiene un panel con botones de «confirmar» o «borrar», es un riesgo real.

X-Frame-Options: DENY (o SAMEORIGIN, si tú mismo usas marcos) lo impide. Hoy la forma moderna es la directiva frame-ancestors dentro de la CSP, que la sustituye en los navegadores actuales. Tener las dos no estorba: la antigua cubre navegadores viejos.

Las tres sencillas: nosniff, Referrer-Policy y Permissions-Policy

X-Content-Type-Options: nosniff impide que el navegador «adivine» el tipo de un archivo. Sin ella, un fichero subido como imagen podría acabar interpretándose como script. Tiene un único valor válido y casi nunca rompe nada.

Referrer-Policy controla cuánta información de la URL de tu página se envía a los sitios que enlazas. Si tus URLs llevan datos (un número de pedido, un término de búsqueda interna), no tienen por qué viajar a terceros. Los navegadores actuales ya aplican un valor prudente por defecto, pero declararlo con strict-origin-when-cross-origin deja el comportamiento fijado en todos.

Permissions-Policy apaga funciones que tu web no usa: cámara, micrófono, ubicación, pagos. Si un script de terceros intenta pedir la ubicación del visitante, el navegador lo bloquea. Un valor como camera=(), microphone=(), geolocation=() basta para la mayoría de sitios corporativos.

Lo que sobra: Server, X-Powered-By y X-XSS-Protection

Algunas cabeceras no protegen, sino que cuentan cosas. Server: Apache/2.4.41 o X-Powered-By: PHP/7.4 le dicen a cualquiera qué software usas y en qué versión, lo que ahorra trabajo a quien busque fallos conocidos. Quitar la versión, o la cabecera entera, es una configuración de un minuto.

X-XSS-Protection es herencia: los navegadores modernos la ignoran o la retiraron. Si aparece, se puede eliminar sin consecuencias.

¿Por dónde empezar sin romper la web?

El orden importa más que la ambición. Una secuencia razonable:

1. Las inocuas primero: X-Content-Type-Options, Referrer-Policy, Permissions-Policy y X-Frame-Options. Rara vez afectan a nada y cierran varios frentes a la vez.
2. HSTS con un max-age corto, de minutos u horas. Comprueba que todo el sitio y sus subdominios funcionan por https y que la redirección de http a https es de un solo salto. Después súbelo a un año.
3. CSP en modo informe (Content-Security-Policy-Report-Only). El navegador avisa de lo que bloquearía, pero no bloquea. Revisa los avisos, añade los orígenes legítimos y, cuando dejen de aparecer, pasa a la cabecera real.
4. Precarga de HSTS, si procede, cuando lleves un tiempo con HSTS estable y tengas inventariados tus subdominios.

Dónde se configuran depende de tu alojamiento: en el panel del hosting, en el .htaccess de Apache, en la configuración de Nginx, en un fichero _headers en plataformas como Cloudflare Pages o Netlify, o en las reglas de tu CDN. En un WordPress también hay plugins que las añaden, aunque es preferible hacerlo en el servidor, que no depende de que el plugin siga instalado.

¿Cómo comprobar las tuyas?

Nuestro comprobador de cabeceras de seguridad lee las cabeceras que devuelve cualquier URL, las puntúa una a una con una explicación de qué está bien, qué falta y qué está mal configurado, y consulta si el dominio ya figura en la lista de precarga de HSTS. Es útil antes y después de cada cambio: compruebas el punto de partida, aplicas una fase y vuelves a mirar.

Revisa también alguna página interna, no solo la portada. Hay servidores que aplican cabeceras distintas según la ruta, y es habitual encontrar la portada bien protegida y el resto del sitio sin nada.

---

Las cabeceras de seguridad no sustituyen a mantener el sitio actualizado, pero son una capa barata y duradera. Una tarde de configuración, hecha en el orden correcto, deja cerrados ataques que de otro modo dependerían de que nadie los intente.