5 HTTP security headers your site probably doesn't have

Cuando una página carga en el navegador, el servidor envía — junto con el HTML — una serie de cabeceras HTTP invisibles. Algunas de esas cabeceras sirven para decirle al navegador: "oye, no confíes en cualquier cosa, yo te oriento sobre qué es seguro aquí."

Sin ellas, el navegador opera en modo por defecto, que es demasiado permisivo para el mundo moderno. Veamos cinco que puedes añadir sin tocar el código de la aplicación — solo configuración de servidor o middleware.

1. Strict-Transport-Security (HSTS)

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

Qué hace: le dice al navegador "usa HTTPS para este dominio por X segundos". Aunque el usuario escriba http://tusitio.com, el navegador cambia automáticamente a https:// sin siquiera hacer la petición insegura.

Por qué importa: sin HSTS, el primer acceso a un dominio ocurre por HTTP (aunque luego redirija a HTTPS). Eso abre una ventana corta para un ataque de SSL stripping en redes hostiles.

Cuidado: un max-age alto + includeSubDomains es un compromiso pesado. Empieza con 1 hora (3600), luego 1 día, luego 1 año. Si desactivas HTTPS en algún subdominio después, se romperá.

2. Content-Security-Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; img-src 'self' data: https:;

Qué hace: controla desde dónde el navegador puede cargar recursos (scripts, imágenes, fuentes). Bloquea la inyección de script desde dominios no autorizados.

Por qué importa: es la defensa más fuerte contra XSS (cross-site scripting). Aunque un atacante logre inyectar <script> en tu página, el navegador se niega a ejecutarlo si el dominio no está autorizado.

Cuidado: un CSP estricto rompe cosas — scripts inline, eval, Google Fonts. Empieza permisivo ('unsafe-inline' en script-src) y ve endureciendo. Usa report-only primero: Content-Security-Policy-Report-Only: ... hace que el navegador reporte violaciones sin bloquear.

3. X-Frame-Options

X-Frame-Options: DENY

Qué hace: impide que tu sitio sea cargado dentro de un <iframe> en otras páginas.

Por qué importa: sin esto, un atacante puede embeber tu sitio en un iframe transparente superpuesto a botones falsos — clickjacking. El usuario cree que hace clic en "OK, acepto cookies" en el sitio del atacante, pero hace clic en "Transferir R$ 1.000" en el tuyo.

Alternativa moderna: Content-Security-Policy: frame-ancestors 'none' hace lo mismo con más flexibilidad. Hoy quieres ambos — algunos navegadores antiguos solo leen X-Frame-Options.

4. X-Content-Type-Options

X-Content-Type-Options: nosniff

Qué hace: impide que el navegador "adivine" el tipo de un archivo. Si el servidor dijo Content-Type: text/plain, el navegador lo trata como texto — no como script HTML, aunque el contenido parezca HTML.

Por qué importa: sin nosniff, los atacantes pueden subir un archivo .txt con contenido <script> e inducir al navegador a ejecutarlo. Con nosniff, el navegador respeta el Content-Type declarado.

Cuidado: ninguno. Esta cabecera no rompe nada. Si aún no la tienes, añádela ahora.

5. Referrer-Policy

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

Qué hace: controla cuánta información sobre la URL actual se envía cuando el usuario hace clic en un enlace que sale de tu sitio.

Por qué importa: sin esta policy, la cabecera Referer filtra la URL completa — incluyendo query strings que pueden tener tokens, emails, IDs. Imagina https://tusitio.com/reset?token=abc123 enviado a Google Analytics, a Facebook, a cualquier enlace en el que se haga clic.

strict-origin-when-cross-origin es el mejor default: envía el origen completo para peticiones dentro del sitio, solo el origen (sin path) para peticiones cross-origin, y nada para HTTP saliendo de HTTPS.

Cómo verificar ahora

Puedes comprobarlo manualmente abriendo el DevTools del navegador → Network → clic en el documento → pestaña Headers. Pero es tedioso hacerlo para cada página.

Herramientas que lo automatizan:

• securityheaders.com — comprobación pública, da una nota A-F
• Sentinela — el probe de Headers verifica las 5 anteriores + calidad del CSP (unsafe-inline, wildcards, Trusted Types), HSTS preload, COOP/COEP, y marca disclosure (Server, X-Powered-By)

La línea base mínima

Si solo vas a añadir una cosa hoy, añade:

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin

Estos tres no rompen nada y cierran las puertas más obvias. HSTS y CSP merecen más cuidado pero el ROI es altísimo — especialmente CSP para apps que procesan datos sensibles.

Las cabeceras HTTP son literalmente la defensa más barata de la web. Cambias la configuración del servidor, haces deploy, y listo. No hay excusa para no tenerlas.