Cabeceras de seguridad HTTP que de verdad importan en 2026

Su aplicación puede tener un sistema de autenticación impecable, contraseñas con hash y un informe de pentest limpio, y aun así caer por una sola etiqueta de script inyectada. Las cabeceras de seguridad son el contrato del lado del navegador que limita el radio de daño cuando algo se cuela. La mayoría de los equipos, o las omite por completo, o pega un fragmento de un blog de 2018 y da el tema por cerrado. Ambas cosas son un error, y en 2026 la distancia entre "tener cabeceras" y "tener cabeceras que funcionan" es exactamente donde ocurren los incidentes reales.

Por qué las cabeceras son el control más barato que existe

Una cabecera de seguridad es una línea de configuración del servidor que convierte el navegador de cada visitante en un punto de aplicación de políticas. Sin agentes que instalar, sin SDK, sin un coste de latencia que merezca la pena medir. El navegador se niega a cargar el script del atacante, se niega a degradar la conexión a HTTP, se niega a que una página hostil enmarque su pasarela de pago.

El problema: las cabeceras son política declarativa, y la política que nadie prueba se pudre en silencio. En Innovation T auditamos muchas aplicaciones en producción y el patrón se repite una y otra vez. Una Content-Security-Policy con unsafe-inline que se anula a sí misma. Un HSTS presente en el host www pero ausente en el dominio raíz. Una cabecera X-Frame-Options duplicada tres veces por tres capas de infraestructura, con valores contradictorios. Las cabeceras son código. Trátenlas como código: versionadas, revisadas y probadas en CI.

Esta es la lista por niveles que usamos en nuestros proyectos, qué hace mecánicamente cada cabecera y cómo desplegar las difíciles sin romper producción.

Nivel 1: las dos cabeceras que frenan ataques reales

Strict-Transport-Security (HSTS)

HSTS cierra la ventana en la que un usuario escribe suapp.com y el navegador emite una petición HTTP en texto plano antes de la redirección. En esa primera petición viven los proxies de SSL stripping: la red Wi-Fi de una cafetería, un ISP hostil, los portales cautivos que abundan en aeropuertos y hoteles de toda la región.

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

La mecánica: en cuanto el navegador ve esta cabecera sobre HTTPS, reescribe internamente toda petición HTTP futura hacia ese origen como HTTPS, antes de que nada toque la red, durante max-age segundos. Con preload, pueden enviar el dominio a la lista de precarga de Chromium y la protección aplica incluso en la primera visita.

El coste que casi todo el mundo subestima: includeSubDomains junto con preload es prácticamente irreversible. Cada subdominio que creen en el futuro deberá servir HTTPS válido, para siempre. ¿Esa herramienta interna en legacy.suapp.com con un certificado autofirmado? Inutilizada para todos los navegadores que tengan el dominio fijado. Nuestra regla: empiecen con max-age=300 durante una semana, luego 86400, luego un año completo, y solo envíen el dominio a la lista de precarga cuando hayan inventariado hasta el último subdominio, incluidos los que marketing levantó sin avisar a nadie.

Content-Security-Policy (CSP)

CSP es la única cabecera que mitiga de forma significativa el cross-site scripting, y es la que más equipos configuran mal. Una política con script-src 'unsafe-inline' o con una larga lista blanca de CDN es puro teatro: las listas blancas se eluden de forma rutinaria mediante endpoints JSONP y redirecciones abiertas en los propios dominios permitidos. La herramienta CSP Evaluator de Google detecta estos fallos en segundos. Pasen su política por ella antes de confiar en su valor.

Lo que funciona en 2026 es la CSP estricta construida sobre nonces y strict-dynamic:

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'self';

La mecánica: cada etiqueta <script> legítima lleva un nonce único por respuesta. strict-dynamic significa "cualquier script cargado por un script de confianza también es de confianza", que es lo que hace viables los bundlers, los imports dinámicos y la mayoría de los gestores de etiquetas. El https: y el unsafe-inline finales son ignorados por los navegadores modernos y existen solo como respaldo para clientes prehistóricos, de modo que la política falla en abierto en navegadores de museo en lugar de romperlos.

Dos requisitos innegociables. Primero, el nonce debe ser criptográficamente aleatorio en cada respuesta, lo que implica que su HTML no puede cachearse tal cual en el CDN: necesitan inyección de nonces en el edge, renderizado por petición, o una política basada en hashes para sitios completamente estáticos. Segundo, frame-ancestors va aquí: sustituye a X-Frame-Options con un control más fino y es la verdadera defensa contra el clickjacking.

CSP es además su cable trampa contra ataques a la cadena de suministro. Cuando un script de terceros comprometido intenta exfiltrar datos hacia un dominio nuevo, un connect-src estricto convierte una brecha silenciosa en un informe de violación en su panel. Si están endureciendo el resto de esa cadena, nuestro artículo sobre cómo construir un pipeline DevSecOps explica dónde encaja el linting de cabeceras en CI.

Nivel 2: mucho valor, cero drama

Estas cabeceras se configuran en minutos y casi nunca rompen nada. Despliéguenlas esta misma semana.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Impide que el navegador adivine tipos MIME, lo que elimina toda una clase de ataques en los que una "imagen" subida por un usuario se interpreta como script. También es un requisito para que varias protecciones modernas del navegador se activen por completo. No existe ninguna razón legítima para omitirla.

Referrer-Policy

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

Los navegadores ya la aplican por defecto, pero conviene fijarla de forma explícita para que un proxy o un cliente antiguo no les haga retroceder. El modo de fallo que evita es feo: URL completas, a veces con tokens de restablecimiento de contraseña o identificadores de sesión en la query string, filtrándose hacia cada dominio de terceros del que cargan recursos. Si el RGPD o la LOPDGDD aplican a su negocio, esa filtración no es solo un problema técnico, es una transferencia de datos personales que tendrán que explicar. Si sus URL llegan a transportar tokens sensibles, consideren no-referrer en esas rutas concretas.

Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), browsing-topics=()

Denegación por defecto para las API más potentes del navegador. El punto no es que su código vaya a pedir de repente acceso a la cámara. El punto es que un script de terceros comprometido incrustado en su página hereda sus permisos. Denegar todo lo que no usan convierte "un atacante en un iframe publicitario activa los sensores" en una operación nula. Extra: browsing-topics=() excluye a sus usuarios de las API de seguimiento por intereses, un pequeño gesto de confianza que en el mercado europeo, además, suma puntos ante cualquier revisión de privacidad.

El trío de aislamiento cross-origin: COOP, COEP, CORP

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-site

Estas cabeceras existen por los ataques de la familia Spectre: cualquier dato cargado en su proceso puede, en teoría, ser leído por código atacante que corra en ese mismo proceso. COOP rompe la referencia de ventana entre su página y las páginas que la abren, lo que de paso elimina una clase de ataques de tab-nabbing. COEP exige que cada recurso incrustado consienta explícitamente ser incrustado. CORP es esa señal de consentimiento para sus propios recursos.

El coste, sin adornos: COEP con require-corp romperá imágenes, iframes y widgets de terceros que no envíen cabeceras CORP, y depurarlo es tedioso. Si manejan datos de pago, datos de salud o cualquier cosa que necesite SharedArrayBuffer, hagan el trabajo. Para un sitio de contenidos, COOP: same-origin a secas es un punto de llegada razonable.

Cabeceras para eliminar en 2026

Los fragmentos antiguos arrastran peso muerto, y parte de él es activamente dañino:

• X-XSS-Protection: el auditor que controlaba fue retirado de todos los navegadores principales hace años, y en navegadores antiguos el propio filtro habilitaba fugas de información. No configuren nada, o 0 si un escáner insiste.
• Expect-CT: obsoleta. Certificate Transparency es obligatoria en los navegadores desde hace años.
• X-Frame-Options: reemplazada por frame-ancestors. Consérvenla solo si de verdad dan soporte a clientes prehistóricos, y asegúrense de que no contradice su CSP.
• X-Powered-By y valores detallados de Server: no son cabeceras de seguridad, pero elimínenlas igualmente. Reconocimiento gratuito para los atacantes, valor cero para ustedes.

Desplegar CSP sin romper producción

Esta es la parte que todas las guías se saltan. Esta es la secuencia que ejecutamos en proyectos de clientes:

1. Primero, inventaríen la realidad. Desplieguen Content-Security-Policy-Report-Only con su política estricta objetivo y un endpoint de reportes. Nada se bloquea todavía; solo recopilan violaciones del tráfico real, incluidos los píxeles de marketing que nadie documentó.
2. Conecten los reportes como es debido. Usen la cabecera moderna Reporting-Endpoints y apunten report-to hacia ella. Alojen el colector ustedes mismos o usen un servicio; en cualquier caso, lleven los reportes al mismo lugar que el resto de sus alertas.
3. Hagan triaje durante dos a cuatro semanas. Las violaciones reales se agrupan rápido: extensiones del navegador (ruido, ignórenlas), inyecciones del gestor de etiquetas (se corrigen propagando el nonce), manejadores inline heredados tipo onclick= (refactorícenlos; suele ser el grueso del trabajo).
4. Arreglen la aplicación, no la política. Cada vez que sientan la tentación de ampliar la política, pregúntense si lo que debería cambiar es el código. El unsafe-inline añadido "de forma temporal" es permanente. Nunca hemos visto que se retire después.
5. Apliquen primero en una ruta de bajo riesgo. Pasen de Report-Only a modo de aplicación en las páginas de marketing o en una herramienta interna. Vigilen tasas de error y reportes durante una semana.
6. Apliquen en todas partes y mantengan Report-Only en marcha. Ejecuten ambas cabeceras en paralelo: la política aplicada como su suelo, y una candidata más estricta en Report-Only como su próxima iteración. Así se endurece la política con el tiempo sin apostar producción a una moneda.
7. Añadan una prueba de regresión. Un paso de CI que consulte las rutas clave y verifique las cabeceras se escribe en una hora. Les ahorrará el incidente de las dos de la madrugada en el que una migración de CDN eliminó en silencio todas las cabeceras que habían desplegado.

Ese último paso importa más que cualquier cabecera individual. En nuestra experiencia, las regresiones de cabeceras ocurren en las fronteras de infraestructura: un nuevo proxy inverso, un cambio de CDN, una migración de plataforma. Y nadie lo nota durante meses porque nada se rompe de forma visible. La verificación pertenece al pipeline, no a la memoria de alguien. Es el mismo argumento que planteamos sobre la seguridad de las API: los controles que no se verifican de forma continua no existen.

Dónde configurarlas y cómo verificarlas

Configuren las cabeceras en la capa más externa que controlen, una sola vez. Los valores contradictorios entre varias capas provocan comportamientos genuinamente extraños en el navegador, y con CSP, varias cabeceras se combinan por intersección, lo que suele traducirse en "gana la más estricta" de formas que nadie pretendía.

Para un edge con nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
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;

El indicador always importa: sin él, nginx omite las cabeceras en los 404 y los 500, justo las respuestas que los atacantes sondean. La CSP con nonces no puede vivir en configuración estática; genérenla por petición en la aplicación o en el worker del edge. Esto aplica igual si sirven desde un proveedor local en Madrid, São Paulo o Ciudad de México que si están detrás de un CDN global: la capa que responde al usuario final es la que manda.

Herramientas de verificación que se ganan su lugar: Mozilla Observatory y securityheaders.com para la vista desde fuera, el CSP Evaluator de Google para la calidad de la política, y un bucle de curl en CI para las regresiones. La caza de calificaciones tiene, eso sí, un modo de fallo conocido: una nota A+ con una CSP que se anula a sí misma es peor que una B con una política real, porque fabrica falsa confianza. Los escáneres comprueban presencia, no corrección. Esa es exactamente la brecha que un test de penetración serio está diseñado para exponer.

Un marco de decisión por tipo de aplicación

• Sitio de marketing estático: HSTS, nosniff, Referrer-Policy, Permissions-Policy y una CSP basada en hashes con frame-ancestors. Medio día de trabajo, riesgo casi nulo.
• Panel SaaS: todo lo anterior más una CSP estricta con nonces y reportes, y COOP. Presupuesten de tres a seis semanas de calendario para el despliegue de CSP, la mayor parte esperando datos de Report-Only. Si son una startup latinoamericana en plena ronda, este es de los pocos trabajos de seguridad que un due diligence técnico valora de inmediato.
• Fintech, salud, cualquier sector regulado: el conjunto completo, incluido el aislamiento COEP/CORP, un connect-src estricto y verificaciones de cabeceras en CI como puerta de despliegue. Las cabeceras pasan a formar parte de su evidencia de cumplimiento, ya sea ante el RGPD, la normativa bancaria local o el regulador de turno.
• Producto de widgets incrustables: están al otro lado de la mesa. Envíen cabeceras CORP correctas, diseñen pensando en las políticas CSP de sus clientes y documenten las directivas exactas que los integradores necesitan.

La regla de fondo: cada cabecera vigila una frontera concreta, y ustedes deberían saber cuál. Si nadie en el equipo puede explicar por qué está ahí una cabecera, es peso muerto o una avería latente.

Cómo puede ayudar Innovation T

Innovation T construye y endurece plataformas web para clientes de Europa y el norte de África: despliegues de CSP estricta sobre productos en producción, aislamiento cross-origin para aplicaciones de alta sensibilidad y pipelines de CI que tratan las cabeceras de seguridad como código probado. Hemos pasado por el triaje de Report-Only las veces suficientes como para comprimir semanas de conjeturas en un proceso predecible.

Si su última revisión de cabeceras fue un fragmento copiado y pegado, vean qué cubren nuestros servicios de ingeniería y seguridad o hablen con nosotros sobre una auditoría. La primera pasada suele tomar días, no meses, y es la reducción de superficie de ataque más barata que van a comprar este año.