Headers de seguridad imprescindibles: la base mínima para blindar cualquier web

Cuando un navegador carga tu web, el servidor no solo envía HTML, CSS e imágenes —envía también cabeceras HTTP invisibles para el usuario pero fundamentales para la seguridad. Sin las cabeceras correctas, el navegador no tiene instrucciones sobre cómo proteger al usuario ante ataques comunes como el clickjacking (engañar al usuario para hacer clic en elementos ocultos), la inyección de scripts de terceros maliciosos, o el sniffing de contenido. La buena noticia es que configurarlas correctamente es un trabajo de una tarde que mejora significativamente la seguridad de tu web.

Las 6 cabeceras de seguridad que todo web debería tener

La primera es Strict-Transport-Security (HSTS). Le dice al navegador que nunca debe conectarse a tu dominio via HTTP, siempre via HTTPS. Sin HSTS, un atacante podría hacer un ataque man-in-the-middle durante la primera conexión HTTP. Valor recomendado: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

La segunda es Content-Security-Policy (CSP). Es la cabecera más poderosa y la más compleja de configurar. Define desde dónde puede cargar el navegador scripts, estilos, imágenes, fuentes y frames. Una CSP bien configurada elimina prácticamente el riesgo de inyección XSS (Cross-Site Scripting), que es uno de los vectores de ataque más comunes. El problema es que una CSP mal configurada puede romper funcionalidades del web. Recomendamos empezar en modo report-only para detectar violaciones sin bloquear nada.

• Strict-Transport-Security: max-age=31536000; includeSubDomains — dice al navegador que uses HTTPS siempre durante el próximo año. Añade 'preload' y registra el dominio en la preload list de Chrome para máxima protección.
• X-Frame-Options: DENY — evita que tu web se pueda mostrar dentro de un iframe en otro dominio. Previene ataques de clickjacking. Si necesitas permitir iframes desde el mismo dominio, usa SAMEORIGIN.
• X-Content-Type-Options: nosniff — evita que el navegador intente "adivinar" el tipo de contenido de un recurso si no coincide con el Content-Type declarado. Previene ataques de MIME sniffing.
• Referrer-Policy: strict-origin-when-cross-origin — controla cuánta información de la URL de origen se envía cuando el usuario navega a otro sitio. Equilibrio entre privacidad y funcionalidad analítica.
• Permissions-Policy (antes Feature-Policy): restringe el acceso a APIs del navegador (cámara, micrófono, geolocalización, acelerómetro) que tu web no necesita. Ejemplo: Permissions-Policy: camera=(), microphone=(), geolocation=()
• Content-Security-Policy en modo report-only: empieza con Content-Security-Policy-Report-Only para ver las violaciones sin bloquear nada. Cuando entiendas qué contenido se carga, pasas al modo blocking.
• Cross-Origin-Opener-Policy (COOP): aísla tu contexto de navegación de otros orígenes. Necesario para webs que usan SharedArrayBuffer o ciertas APIs de rendimiento. Valor: same-origin.
• Cómo aplicarlas: via Nginx (add_header), Apache (.htaccess), Cloudflare (Rules → Transform Rules → Modify Response Headers) o directamente en tu framework (Nuxt.js via nitro.headers, Next.js via next.config.js headers).

Cómo verificar que las cabeceras están correctamente configuradas

Una vez las hayas configurado, verifícalas con Security Headers (securityheaders.com): introduce tu dominio y te indica qué cabeceras tienes, cuáles faltan y una nota global de A+ a F. El objetivo es A o A+. Una nota B es aceptable; C o inferior indica cabeceras críticas que faltan.

Ten en cuenta que algunas cabeceras pueden entrar en conflicto con herramientas de terceros que uses en tu web. Un píxel de Facebook o un chat de terceros normalmente requiere ajustes en la CSP para permitir cargar scripts desde sus dominios. Usa el modo report-only para detectar qué scripts de terceros usa tu web antes de bloquear nada.

Los security headers no protegen de todo, pero es una capa de protección con coste casi cero e impacto alto. No tenerlos es dejar puertas abiertas innecesariamente.