Cabeceras de Seguridad HTTP: Guía Completa 2026

Por qué importan las cabeceras de seguridad

Las cabeceras de seguridad HTTP son directivas que envía tu servidor web y que indican a los navegadores cómo deben comportarse al mostrar tu sitio web. Añadirlas no requiere ningún cambio en el código de tu aplicación - solo configuración del servidor web - y, sin embargo, son una de las defensas más eficaces frente a una amplia variedad de ataques web habituales, entre ellos el Cross-Site Scripting (XSS), el clickjacking y la inyección de contenido.

Muchos sitios web descuidan por completo las cabeceras de seguridad. Un análisis del millón de sitios web más importantes muestra de forma reiterada que la mayoría carece de al menos algunas cabeceras críticas. Es una oportunidad desaprovechada, porque estas cabeceras son gratuitas y fáciles de añadir.

HSTS - HTTP Strict Transport Security

HSTS es una cabecera que le dice a los navegadores: no te conectes nunca a este sitio web a través de HTTP sin cifrar, pase lo que pase. Una vez que un navegador ha visto una cabecera HSTS de tu sitio, actualizará automáticamente cualquier solicitud HTTP futura a HTTPS, incluso si el usuario escribe "http://" en la barra de direcciones o hace clic en un enlace HTTP. Esta es una de las cabeceras de seguridad más importantes que puedes añadir.

La cabecera tiene tres parámetros importantes. El valor "max-age" le indica al navegador durante cuánto tiempo (en segundos) debe recordar esta política; deberías fijarlo en al menos un año (31536000 segundos). El indicador "includeSubDomains" extiende esta protección a todos tus subdominios. El indicador "preload" le comunica a los navegadores que quieres formar parte de la lista de precarga de HSTS, una lista integrada directamente en Chrome, Firefox y otros navegadores para que incluso la primera visita a tu sitio esté protegida.

En nginx, añades esta cabecera con la directiva add_header dentro de tu bloque server. En Apache, usas la directiva Header dentro de un bloque VirtualHost. Incluye siempre la palabra clave "always" para asegurarte de que la cabecera se envíe incluso en las respuestas de error.

Antes de establecer un max-age largo, asegúrate por completo de que todo tu sitio - incluidos todos los subdominios - funciona correctamente sobre HTTPS. Establecer HSTS con un max-age largo y descubrir después que un subdominio no admite HTTPS puede dejar a los usuarios sin acceso durante meses.

CSP - Content Security Policy

Content Security Policy es la cabecera de seguridad más potente disponible y, también, la más compleja de configurar correctamente. Le indica a los navegadores exactamente qué fuentes de contenido tienen permiso para cargarse en tu página: scripts, hojas de estilo, imágenes, fuentes tipográficas y más. Es tu defensa principal frente a los ataques de Cross-Site Scripting (XSS), en los que un atacante logra inyectar JavaScript malicioso en tu página.

Una CSP funciona mediante una lista blanca de fuentes de confianza. Por ejemplo, podrías especificar que los scripts solo pueden cargarse desde tu propio dominio y desde Google Analytics, que las hojas de estilo solo pueden provenir de tu propio dominio y que las imágenes pueden proceder de cualquier lugar a través de HTTPS. Cualquier contenido que no se ajuste a estas reglas es bloqueado por el navegador antes de que pueda ejecutarse.

La forma más eficaz de implementar CSP es de manera gradual. Empieza añadiendo una cabecera "Content-Security-Policy-Report-Only" en lugar de "Content-Security-Policy". Esto significa que la política no se aplica de forma obligatoria: las infracciones se te notifican, pero el contenido se sigue cargando. Así puedes recopilar informes de infracciones, identificar todos los recursos de terceros legítimos que tu sitio carga realmente y construir tu política sin romper nada. Tras una o dos semanas recopilando datos, cambia a la versión que sí se aplica.

Un error frecuente es "unsafe-inline", una directiva que permite scripts y estilos en línea. Aunque facilita implementar CSP sin romper tu sitio, reduce drásticamente la protección que ofrece, porque la mayoría de los ataques XSS se basan en inyectar scripts en línea. Un mejor enfoque consiste en usar "nonces" o "hashes" para permitir scripts en línea específicos y, al mismo tiempo, bloquear los inyectados.

X-Frame-Options

La cabecera X-Frame-Options controla si tu sitio web puede incrustarse dentro de un iframe en otro dominio. Esto protege frente a los ataques de clickjacking, en los que un atacante coloca tu sitio web en un iframe invisible superpuesto sobre su propia página. El visitante cree que está haciendo clic en algo de la página del atacante, pero en realidad está haciendo clic en tu sitio, lo que podría autorizar una transacción, pulsar un botón de "aceptar" o realizar alguna otra acción sin darse cuenta.

El valor recomendado es "SAMEORIGIN", que permite que tu sitio se incruste en iframes únicamente desde páginas de tu propio dominio. "DENY" impide por completo la incrustación. La antigua opción "ALLOW-FROM" está obsoleta y no es compatible con los navegadores modernos.

Ten en cuenta que, si tienes una CSP moderna configurada, puedes usar la directiva CSP "frame-ancestors" en lugar de X-Frame-Options, ya que ofrece un control más detallado. No obstante, para lograr la máxima compatibilidad en todos los navegadores, es una buena práctica incluir ambas.

X-Content-Type-Options

Esta cabecera, sencilla pero importante, tiene un único valor: "nosniff". Impide que los navegadores realicen "MIME sniffing", es decir, que adivinen qué tipo de contenido contiene un archivo basándose en su contenido real en lugar de en la cabecera Content-Type declarada.

El MIME sniffing parece inofensivo, pero puede explotarse. Si un atacante consigue que alojes un archivo que, para el detector de contenido de un navegador, parezca HTML o JavaScript - aunque tú creas que es una imagen o un archivo de texto, el navegador podría ejecutarlo como un script. Añadir "nosniff" le indica a los navegadores que respeten siempre el tipo de contenido declarado y que nunca lo adivinen.

Referrer-Policy

Cuando un usuario hace clic en un enlace de tu sitio web hacia otro sitio, los navegadores incluyen automáticamente una cabecera "Referer" (fíjate en la errata: es histórica) que le indica al sitio de destino de dónde procede el usuario. Esto puede filtrar información sensible de forma inadvertida si tus URL contienen tokens de sesión, consultas de búsqueda u otros datos privados en la cadena de consulta.

La cabecera Referrer-Policy controla qué información se envía. El valor recomendado "strict-origin-when-cross-origin" envía la URL completa en las solicitudes del mismo origen (útil para tu propia analítica), pero solo envía el dominio (no la URL completa) en las solicitudes de origen cruzado. Esto protege los parámetros sensibles de la URL al tiempo que conserva información de referencia útil para tu propio sitio.

Permissions-Policy

Permissions-Policy (antes llamada Feature-Policy) controla qué funciones y API del navegador puede utilizar tu página. Esto incluye capacidades potencialmente sensibles como la cámara, el micrófono, la geolocalización, la API de solicitud de pago y más. Al desactivar de forma explícita las funciones que no utilizas, impides que los scripts de terceros (redes publicitarias, herramientas de analítica, contenido incrustado) accedan a esas funciones aunque lo intenten.

Preguntas frecuentes

¿Añadir una CSP romperá mi sitio web? Podría hacerlo, al principio. La CSP bloquea todo lo que no se permite de forma explícita. Si tienes scripts en línea, estilos en línea o recursos de terceros que no has incluido en la lista blanca, quedarán bloqueados. La solución es usar primero el modo Report-Only y dedicar tiempo a recopilar informes de infracciones antes de pasar a la aplicación obligatoria.

¿Qué es la cabecera Server y debería ocultarla? La cabecera Server revela el software y la versión de tu servidor web; por ejemplo, "nginx/1.24.0". Esta información resulta útil para los atacantes que quieren aprovechar vulnerabilidades conocidas en versiones concretas del software. Deberías suprimir o generalizar esta cabecera. En nginx, establece "server_tokens off". En Apache, usa "ServerTokens Prod".

¿Afectan estas cabeceras al rendimiento del sitio? De forma insignificante. Las cabeceras añaden unos pocos bytes a cada respuesta HTTP, pero no tienen un impacto apreciable en el tiempo de carga. Los beneficios de seguridad superan con creces cualquier sobrecarga marginal.

¿Debería añadir cabeceras de seguridad tanto a las respuestas HTTP como a las HTTPS? Sí, configúralas en ambas, pero recuerda que HSTS solo debe enviarse sobre HTTPS. El HSTS enviado sobre HTTP se ignora y podría generar confusión.