Cabeceras de seguridad: qué hace cada una y cómo configurarlas

En resumen: las cabeceras de seguridad son instrucciones que tu servidor envía con cada página y que le dicen al navegador que use siempre HTTPS, que ejecute scripts solo desde las fuentes que apruebes, que no permita que otros sitios incrusten tus páginas en un marco, que nunca adivine el tipo de archivo y que no exponga URL completas en la cabecera Referer. Empieza por HTTPS en todo el sitio y un certificado válido; después añade Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin y frame-ancestors o X-Frame-Options. Implanta Content-Security-Policy primero en modo solo informe (report-only). Todas se configuran en el servidor o en el CDN.

Las cabeceras de seguridad son un seguro barato. La mayoría requiere una sola línea de configuración del servidor, no cuesta nada en rendimiento y cierra categorías enteras de ataques: un script inyectado que roba sesiones, un marco invisible que engaña para que se haga clic, una red de cafetería que degrada al visitante a HTTP sin cifrar. Además, son de lo primero que revisan los escáneres de seguridad, los clientes corporativos y los cuestionarios de seguridad.

Esta guía explica cada cabecera y los fundamentos de conexión que las rodean, ofrece valores iniciales seguros, muestra cómo nuestro verificador de cabeceras de seguridad gratuito prueba tu sitio y repasa la solución a cada problema que informa.

Lo básico primero: HTTPS, certificado y contenido mixto

Las cabeceras funcionan sobre una conexión cifrada; sin ella, no sirven de nada. Hay tres puntos básicos que van primero:

• HTTPS en todas las páginas, con redirección desde HTTP. Desde Chrome 68, en julio de 2018, Chrome marca todas las páginas HTTP como «no seguras» (Chromium Blog), y la guía de experiencia de página de Google pregunta: «Are your pages served in a secure fashion?» (¿se sirven tus páginas de forma segura?).
• Un certificado válido que cubra todos los hostnames que uses, incluidos www y el dominio sin subdominio. Un certificado caducado o que no coincide muestra una advertencia a pantalla completa.
• Sin contenido mixto. Una página segura que carga archivos por http:// no es del todo segura. Según MDN, los navegadores actualizan automáticamente a HTTPS las imágenes, el audio y el vídeo, y bloquean por completo los scripts, las hojas de estilo, los iframes y otro contenido «bloqueable», lo que rompe la página.

Las cabeceras, una por una

Strict-Transport-Security (HSTS)

HSTS le indica al navegador que use HTTPS para tu host durante un número determinado de segundos, incluso cuando alguien escribe http:// o hace clic en un enlace antiguo. MDN señala tres cosas que conviene saber:

• Los navegadores ignoran la cabecera cuando llega por HTTP sin cifrar. Envíala en las respuestas HTTPS; tu redirección de HTTP a HTTPS no la necesita.
• Solo funciona después de la primera visita segura. La precarga (preload) cierra ese hueco.
• includeSubDomains aplica la política a todos los subdominios, así que revísalos todos antes.

La lista de precarga de HSTS incrusta tu dominio directamente en los navegadores. Exige un certificado válido, una redirección de HTTP a HTTPS en el mismo host, todos los subdominios en HTTPS y una cabecera con max-age de al menos 31536000, includeSubDomains y preload. También advierte de que «inclusion in the preload list cannot easily be undone» (la inclusión en la lista de precarga no se puede deshacer fácilmente): la retirada tarda meses en llegar a los usuarios. Activa la precarga solo cuando estés seguro.

Content-Security-Policy (CSP)

CSP es la más potente de las cabeceras y la más difícil de implantar. Enumera desde dónde pueden cargarse scripts, estilos, imágenes y otros recursos, y el navegador rechaza todo lo demás. MDN la describe principalmente como «a defense against cross-site scripting (XSS) attacks» (una defensa contra los ataques de cross-site scripting).

La forma moderna recomendada es una CSP estricta basada en nonces o hashes en lugar de largas listas de dominios permitidos:

Content-Security-Policy: script-src 'nonce-{RANDOM}'; object-src 'none'; base-uri 'none'

El nonce debe ser aleatorio y distinto en cada respuesta. MDN advierte de que 'unsafe-inline' «defeats much of the purpose of having a CSP» (anula gran parte del propósito de tener una CSP).

Como una política estricta puede romper etiquetas de analítica, widgets de chat y scripts en línea, impleméntala en dos pasos: envía Content-Security-Policy-Report-Only con un endpoint de informes, corrige lo que muestren los informes y después cambia a la cabecera que aplica la política. En CSP también vive upgrade-insecure-requests (una red de seguridad para el contenido mixto, no un sustituto de HSTS) y es donde frame-ancestors controla la inserción en marcos.

X-Frame-Options y frame-ancestors

El clickjacking carga tu página en un marco invisible dentro de otro sitio y engaña a la gente para que haga clic en tus botones. Hay dos maneras de impedirlo:

• X-Frame-Options: SAMEORIGIN (o DENY), la cabecera más antigua. ALLOW-FROM está obsoleta y hace que los navegadores modernos ignoren la cabecera.
• Content-Security-Policy: frame-ancestors 'self', la opción más flexible, que además permite enumerar orígenes de socios concretos.

Ninguna funciona desde una etiqueta <meta>. MDN indica que X-Frame-Options en un elemento meta «has no effect» (no tiene efecto) y que frame-ancestors «is not supported in the <meta> element» (no es compatible con el elemento <meta>). Ten en cuenta también que frame-ancestors no recurre a default-src: una política default-src 'none' sigue permitiendo que cualquiera incruste la página en un marco.

X-Content-Type-Options

nosniff indica a los navegadores que confíen en tu cabecera Content-Type. Con ella, una respuesta solicitada como script u hoja de estilos se bloquea si su tipo MIME no coincide, lo que impide que un archivo subido y disfrazado de imagen se ejecute como script. Solo tiene un valor válido:

X-Content-Type-Options: nosniff

Antes de añadirla, asegúrate de que tu servidor envía los tipos de contenido correctos, sobre todo para JavaScript y CSS.

Referrer-Policy

Cuando un visitante hace clic en un enlace a otro sitio, el navegador envía una cabecera Referer. Los navegadores modernos ya usan por defecto strict-origin-when-cross-origin, que entre sitios distintos envía solo el origen (https://example.com/) y no envía nada al pasar de HTTPS a HTTP (MDN). OWASP sigue recomendando establecerla de forma explícita «rather than relying on browser defaults» (en lugar de depender de los valores por defecto del navegador). Evita unsafe-url, que envía URL completas, incluidos los tokens que contengan, a todas partes.

Permissions-Policy y las cabeceras que conviene eliminar

Permissions-Policy desactiva funciones del navegador que no usas, de modo que un script incrustado no pueda pedir la cámara o la ubicación. MDN la marca como experimental y con compatibilidad limitada en los navegadores, así que trátala como una capa adicional. Nuestro verificador gratuito no la comprueba; el análisis de seguridad completo sí.

Hay dos cabeceras que conviene quitar en lugar de añadir: OWASP dice que no se establezca X-XSS-Protection (o que se ponga a 0), porque los antiguos filtros que controlaba podían crear vulnerabilidades, y califica Expect-CT de obsoleta. También recomienda eliminar X-Powered-By y dar a Server un valor que no revele información.

Cómo funciona el verificador de cabeceras de seguridad de Searvia

El verificador de cabeceras de seguridad gratuito usa el mismo motor que nuestro verificador SEO de sitios web y pone cinco comprobaciones en primer lugar. Hace peticiones ordinarias, como las que podría hacer cualquier visitante; no se ataca ni se sondea nada.

Las tres que cuenta son Content-Security-Policy, X-Frame-Options (o una cabecera CSP que contenga frame-ancestors) y X-Content-Type-Options. Referrer-Policy también aparece en la lista, pero su ausencia no se cuenta en tu contra: los navegadores ya usan por defecto strict-origin-when-cross-origin, y la tabla lo indica. La tabla de resultados muestra el valor de cada una, acortando las políticas largas.

Algunos límites que conviene tener presentes:

• Comprueba la presencia, no la calidad. Una CSP llena de 'unsafe-inline' pasa aquí; el análisis de seguridad completo la califica.
• Lee las cabeceras de respuesta HTTP. Una CSP definida en una etiqueta <meta> cuenta, con una nota: frame-ancestors y los informes no funcionan ahí, por lo que no puede sustituir a X-Frame-Options. Una cabecera Content-Security-Policy-Report-Only no cuenta como política aplicada.
• Comprueba una página, la que introduces (la página de inicio si introduces solo un dominio). Otras rutas, como un área de administración o una API, pueden enviar cabeceras distintas.
• El contenido mixto se detecta solo en el HTML: URL absolutas http:// en las etiquetas. No se ven los archivos que CSS o JavaScript soliciten más tarde.

Cómo leer los resultados

Trabaja de arriba abajo por prioridad. Un fallo en HTTPS o en el certificado es urgente: los visitantes ven advertencias del navegador o navegan sin cifrado. El contenido mixto activo (scripts, iframes, hojas de estilo) es lo siguiente, porque los navegadores bloquean esos archivos y la página puede romperse. HSTS y las cabeceras de seguridad tienen prioridad baja en la puntuación, pero también son lo más rápido de corregir, así que agrúpalas en un solo cambio de configuración.

Cómo corregir cada problema que informa el verificador

«The site does not work over HTTPS.» / «HTTP does not redirect to HTTPS.»

1. Instala un certificado. Let's Encrypt es gratuito y la mayoría de los hostings lo ofrecen con un clic.
2. Añade una redirección permanente de cada URL http:// a la misma URL https://.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

En Cloudflare, activa «Always Use HTTPS» en SSL/TLS › Edge Certificates.

«The certificate expired N days ago.» / «The certificate does not cover this domain.»

1. Renuévalo ahora y activa la renovación automática (Certbot y la mayoría de los hostings y CDN lo hacen por defecto).
2. Asegúrate de que el certificado incluya todos los hostnames que sirves, al menos el dominio sin subdominio y www.
3. Si la renovación falla en silencio, las causas habituales son un registro DNS modificado, una ruta de validación bloqueada o un token de API caducado para la validación por DNS.

Un aviso con menos de 14 días restantes suele significar que la renovación automática no funciona; investiga en lugar de renovar a mano cada vez.

«HSTS is not set.» / «HSTS is on but shorter than 6 months.»

Implántalo por fases para que un subdominio olvidado que solo funciona con HTTP no quede bloqueado:

1. Confirma que el sitio principal y todos los subdominios funcionan por HTTPS.
2. Envía Strict-Transport-Security: max-age=300 durante un día, luego una semana (604800) y después un mes.
3. Pasa a max-age=31536000; includeSubDomains.
4. Solo entonces plantéate preload y envía la solicitud en hstspreload.org.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

«N files load over plain HTTP.»

1. Abre la lista de URL del informe.
2. Cambia cada una a https://, o a una ruta relativa si son archivos tuyos. Para archivos de terceros, comprueba que el proveedor sirva HTTPS; si no, cambia de proveedor.
3. Busca en tu base de datos y en tu tema enlaces http:// escritos a mano; tras una migración a HTTPS, el contenido antiguo de las entradas suele ser el origen.
4. Como red de seguridad, añade Content-Security-Policy: upgrade-insecure-requests.

«N key security headers are missing.»

Añade las que falten en un solo cambio. Para nginx:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'; report-to csp" always;

Para Apache:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

En Cloudflare, añade cabeceras de respuesta con una Transform Rule. En Netlify, usa un archivo _headers; en Vercel, el ajuste headers de vercel.json. En nginx, recuerda que add_header dentro de un bloque location sustituye a las cabeceras definidas a nivel de servidor, así que repítelas o usa un archivo de inclusión.

En cuanto a CSP, la línea report-only de arriba es un punto de partida, no una política terminada. Apunta report-to a un endpoint de informes que controles, revisa las infracciones durante una o dos semanas, ajusta la política y luego renombra la cabecera a Content-Security-Policy. Una vez aplicada, la comprobación de CSP pasa.

Cómo comprobar las cabeceras por tu cuenta

El verificador muestra lo que envía la página comprobada, pero otras páginas, archivos y respuestas de error pueden diferir. Dos formas rápidas de verlo:

• DevTools del navegador. Abre el panel Network, recarga la página, haz clic en la primera petición y lee la sección Response Headers.
• La línea de comandos. curl -sI https://www.example.com/ imprime solo las cabeceras de respuesta. Ejecútalo con la página de inicio, una página interna, un PDF, una página 404 y tu página de inicio de sesión.

Una sorpresa frecuente son las cabeceras que aparecen en las páginas normales pero no en los errores ni en las redirecciones. En nginx, add_header solo se aplica a las respuestas correctas y a las redirecciones a menos que añadas el parámetro always, por eso todos los ejemplos anteriores lo incluyen. Otra es un CDN o un hosting que añade o elimina cabeceras, así que comprueba la respuesta que ve el público, no solo el archivo de configuración de tu servidor.

Recuerda que cada cabecera protege algo distinto. Una CSP perfecta no sirve de nada ante un certificado caducado, y HSTS no hace nada contra un script inyectado. El objetivo es el conjunto completo, añadido en un orden sensato.

Ejemplo práctico (hipotético)

El siguiente es un ejemplo hipotético, no datos reales. Halden Legal, un bufete inventado, recibe de un cliente corporativo un cuestionario de seguridad que pregunta por las cabeceras de su sitio web. El verificador de cabeceras de seguridad informa:

• HTTPS, certificado TLS: correcto, quedan 61 días.
• HSTS: aviso, max-age=86400 (un día).
• Contenido mixto: aviso, 2 imágenes se cargan por HTTP (una insignia de un socio y una foto antigua del equipo).
• Cabeceras de seguridad: faltan 2 cabeceras clave; solo está definida X-Content-Type-Options, y Referrer-Policy muestra el valor por defecto del navegador.

Las correcciones llevan una tarde. Las dos URL de imágenes se cambian a HTTPS. Tras confirmar que el subdominio del portal de clientes funciona por HTTPS, HSTS pasa a max-age=31536000; includeSubDomains en dos pasos a lo largo de una semana. En el servidor se añaden X-Frame-Options: SAMEORIGIN y Referrer-Policy: strict-origin-when-cross-origin. Una CSP en modo report-only funciona durante diez días y revela un script en línea del widget de reservas, que se mueve a un archivo y se permite por su origen antes de aplicar la política. La ejecución final pasa todas las comprobaciones y el bufete responde al cuestionario con un enlace al informe compartido.

Una lista de comprobación de una hora

1. Ejecuta el verificador de cabeceras de seguridad y corrige primero los fallos de HTTPS y del certificado.
2. Elimina el contenido mixto que indica el informe.
3. Añade X-Content-Type-Options, Referrer-Policy y X-Frame-Options o frame-ancestors.
4. Sube HSTS por fases hasta un año cuando todos los subdominios funcionen por HTTPS.
5. Inicia una CSP en modo report-only y programa una revisión.
6. Elimina X-Powered-By, los números de versión en Server y cualquier X-XSS-Protection distinto de 0.

Cómo vigila Searvia la seguridad de tu sitio

El verificador de cabeceras de seguridad gratuito analiza tu página de inicio, o cualquier página que introduzcas, en unos 20 segundos, sin registro, y el mismo informe incluye 33 comprobaciones más sobre apariencia en buscadores, rastreo, velocidad, móvil y autenticación del correo.

Una cuenta gratuita de Searvia añade un análisis de seguridad semanal: comprobaciones pasivas de cifrado, protecciones del navegador, flags de las cookies, versiones de software y protección contra suplantación de correo, con la petición y la respuesta que prueban cada hallazgo. Califica tu CSP (por ejemplo, 'unsafe-inline' sin nonces ni hashes), comprueba Permissions-Policy y, después de que verifiques la propiedad, busca además archivos .env y .git expuestos, copias de seguridad públicas, páginas de depuración y CORS inseguro. Write the remediation plan with AI convierte los hallazgos en configuración que puedes pegar (5 créditos). En los planes de pago desde Starter, la monitorización de disponibilidad también revisa tu certificado TLS a diario y te avisa antes de que caduque.