Cabeceras de seguridad HTTP: cuáles poner, cómo comprobarlas y qué nota da Mozilla

Las cabeceras de seguridad HTTP son líneas que tu servidor añade a cada respuesta para que el navegador aplique protecciones: usar siempre HTTPS (Strict-Transport-Security), limitar de dónde se cargan los scripts (Content-Security-Policy), impedir que otra web te incruste (frame-ancestors) o que adivine el tipo de un archivo (X-Content-Type-Options). No suben posiciones en Google: protegen a tus visitantes y tu reputación.

Para comprobarlo en tu web: Auditoría SEO

Forman parte de la categoría de seguridad y confianza del posicionamiento web, junto con HTTPS y la autenticación del correo. Esta guía explica qué hace cada una, con qué valor empezar sin romper nada y cómo comprobar el resultado.

¿Las cabeceras de seguridad ayudan al SEO?

No directamente, y conviene decirlo claro. Google explica que, más allá de Core Web Vitals, los demás aspectos de la experiencia de página no ayudan directamente a que una web posicione mejor, aunque hacen que sea más satisfactoria de usar, que es lo que sus sistemas buscan premiar1. Ninguna documentación de Google menciona Content-Security-Policy o Referrer-Policy como señal.

El beneficio real es otro. Una política de contenido bien puesta dificulta que un fallo en un plugin acabe inyectando scripts o enlaces de spam en tus páginas, y una web pirateada sí tiene consecuencias visibles en Google: avisos en los resultados y páginas de advertencia en el navegador, como contamos en la guía de HTTPS y SEO. Las cabeceras son prevención, no un atajo para subir.

Las cabeceras, una a una

Strict-Transport-Security (HSTS)

HSTS es la cabecera que le dice al navegador que, durante max-age segundos, solo se conecte a tu dominio por HTTPS. El navegador la ignora si llega por HTTP, y no protege la primera visita: solo surte efecto después de una conexión segura en la que se haya recibido2.

includeSubDomains extiende la regla a todos los subdominios, así que antes de ponerla comprueba que todos tienen certificado. La directiva preload sirve para entrar en la lista que los navegadores traen de serie, y exige un max-age de al menos un año (31.536.000 segundos) e includeSubDomains2. Es un compromiso difícil de deshacer: se puede salir de la lista, pero el cambio tarda meses en llegar a los usuarios3. Añádela solo cuando lo anterior lleve tiempo funcionando.

Content-Security-Policy (CSP)

La Content-Security-Policy es una lista de los orígenes desde los que la página puede cargar scripts, estilos, imágenes y demás recursos. Su objetivo principal es frenar el cross-site scripting (XSS)4. Las directivas que más se usan:

• default-src: el valor por defecto para todo lo que no tenga directiva propia.
• script-src: de dónde pueden venir los scripts. MDN desaconseja 'unsafe-inline', porque anula buena parte de la protección; la alternativa son los nonces o los hashes4.
• object-src 'none' y base-uri 'self': cierran dos vías de inyección clásicas.
• upgrade-insecure-requests: pide al navegador que cargue por HTTPS lo que esté enlazado por HTTP.
• frame-ancestors: quién puede incrustar tu página. Con 'none' equivale a X-Frame-Options: DENY, no hereda de default-src y no funciona dentro de una etiqueta <meta>, solo como cabecera5.

Empezar con Content-Security-Policy-Report-Only

Una CSP escrita a ciegas suele romper algo: la analítica, el chat, un mapa incrustado. Por eso existe Content-Security-Policy-Report-Only, que vigila las infracciones sin aplicarlas: el navegador las anota en la consola y, si declaras un punto de recogida, te las envía6. MDN recomienda declarar report-to (con la cabecera Reporting-Endpoints) y también el antiguo report-uri, porque el primero aún no tiene soporte completo en todos los navegadores6.

El método práctico: publica la política en modo Report-Only, navega por todas tus plantillas, revisa qué se habría bloqueado, añade los orígenes legítimos y, cuando la consola quede limpia, cambia el nombre de la cabecera a Content-Security-Policy.

X-Content-Type-Options

Con nosniff, el navegador deja de adivinar el tipo de un archivo y respeta el Content-Type que declara el servidor. Además bloquea los scripts que no llegan con un tipo JavaScript y las hojas de estilo que no llegan como text/css7. Antes de activarla, comprueba que tu servidor declara bien los tipos.

X-Frame-Options y frame-ancestors

X-Frame-Options admite DENY y SAMEORIGIN. La variante ALLOW-FROM está obsoleta: los navegadores actuales ignoran la cabecera entera si la encuentran. Ponerla en una etiqueta <meta> no tiene ningún efecto8. Para elegir con detalle quién te incrusta, usa frame-ancestors; mantener también X-Frame-Options cubre navegadores antiguos.

Referrer-Policy

Si no declaras nada, los navegadores aplican strict-origin-when-cross-origin: dentro de tu web se envía la URL completa como referencia, a otros sitios solo el dominio, y nada si se pasa de HTTPS a HTTP9. Declararlo de forma explícita evita depender del valor por defecto de cada navegador. Si tus URL llevan datos personales en los parámetros, no-referrer es más prudente.

Permissions-Policy

Permissions-Policy activa o desactiva funciones del navegador, como la cámara, el micrófono o la geolocalización, para tu página y para los iframes que incrusta. camera=() la desactiva para todos. MDN avisa de que no funciona aún en todos los navegadores principales10, así que tómala como una capa adicional, no como la única defensa.

Cookies: Secure, HttpOnly y SameSite

Las cookies no van en una cabecera aparte, sino en los atributos de Set-Cookie. Secure hace que la cookie solo viaje por HTTPS; HttpOnly impide que JavaScript la lea, lo que limita el daño de un XSS; SameSite=Strict o Lax restringe su envío en peticiones que vienen de otros sitios, y SameSite=None exige Secure11. Algunos navegadores aplican Lax si no indicas nada, pero no todos, así que decláralo. El prefijo __Host- obliga a que la cookie sea Secure, sin Domain y con Path=/11.

Las que sobran

OWASP recomienda no enviar X-XSS-Protection o enviarla a 0, porque el filtro antiguo de algunos navegadores podía abrir fallos en webs seguras. También aconseja quitar X-Powered-By y no revelar versiones en Server12.

Un bloque de cabeceras de ejemplo, comentado

Este es un punto de partida genérico para una web que solo carga recursos propios. Las líneas que empiezan por # son comentarios: no forman parte de la respuesta HTTP y no se copian.

# Solo HTTPS durante un año, también en los subdominios (comprueba antes que todos tienen certificado)
Strict-Transport-Security: max-age=31536000; includeSubDomains

# Primero en modo informe: avisa de lo que bloquearía, no bloquea nada
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; upgrade-insecure-requests; report-to csp

# Adónde envía el navegador los informes de la política anterior
Reporting-Endpoints: csp="https://www.example.com/informes-csp"

# El navegador respeta el Content-Type y no adivina
X-Content-Type-Options: nosniff

# Para navegadores que no entienden frame-ancestors
X-Frame-Options: SAMEORIGIN

# A otros sitios solo les llega tu dominio, no la URL completa
Referrer-Policy: strict-origin-when-cross-origin

# Cámara, micrófono y ubicación desactivados para la página y sus iframes
Permissions-Policy: camera=(), microphone=(), geolocation=()

# Cookie de sesión: solo por HTTPS, invisible para JavaScript, ligada a este host
Set-Cookie: __Host-sesion=valor; Path=/; Secure; HttpOnly; SameSite=Lax

Si usas analítica, un gestor de etiquetas, fuentes externas o un chat, default-src 'self' los bloquearía: el modo Report-Only te dirá cuáles añadir. Cómo se escriben estas líneas depende de tu servidor o de tu CDN, pero los valores son los mismos.

¿Cómo comprobar tus cabeceras con curl?

La forma más rápida de ver lo que envía tu servidor, no lo que crees que envía, es pedir solo las cabeceras desde la terminal (cambia example.com por tu dominio):

# Todas las cabeceras de la respuesta
curl -sI https://www.example.com/

# Solo las de seguridad (la búsqueda no distingue mayúsculas)
curl -sI https://www.example.com/ | grep -iE "strict-transport|content-security|x-content-type|x-frame|referrer-policy|permissions-policy|set-cookie"

# ¿La versión http redirige a https en un solo salto?
curl -sI http://example.com/ | grep -iE "^(HTTP|location)"

Repite la segunda orden con una URL de cada plantilla y con un archivo estático (una imagen o un .js): es habitual que la portada lleve las cabeceras y que los recursos que sirve otra capa, como una CDN, no las lleven. Si la tercera orden muestra más de un salto, revisa las cadenas de redirecciones como explica la guía de SEO técnico.

¿Cómo puntúa el HTTP Observatory de Mozilla?

El HTTP Observatory es la herramienta gratuita de MDN que analiza las cabeceras de una web y le pone una nota. Cada sitio parte de 100 puntos; primero se restan las penalizaciones y, solo si el resultado sigue en 90 o más, se suman las bonificaciones. La puntuación mínima es 0 y la máxima posible, hoy, 14513:

Mozilla advierte que lo que es innecesario en un sitio puede mitigar riesgos importantes en otro, y que cada equipo debe decidir qué le conviene13. Las pruebas actuales cubren la CSP, las cookies, CORS, la redirección a HTTPS, Referrer-Policy, HSTS, la integridad de subrecursos, X-Content-Type-Options, X-Frame-Options y las políticas Cross-Origin (COEP, COOP y CORP)14. Desde 2024 ya no puntúa X-XSS-Protection ni analiza el certificado TLS15. Permissions-Policy no forma parte de la nota, aunque sea buena práctica.

Qué revisa SmoothSeen en seguridad y confianza

Declaración de interés: este blog es de SmoothSeen. En la categoría de seguridad y confianza de su análisis de posicionamiento web, SmoothSeen muestra la nota del HTTP Observatory de tu dominio, comprueba que la página se sirve por HTTPS sin contenido mixto, mira si Google Web Risk la marca como peligrosa y revisa los registros SPF y DMARC del dominio, que explicamos en la guía de SPF, DKIM y DMARC. Si comparas con competidores, ves también su nota de cabeceras.

Preguntas frecuentes

¿Una mala nota en el HTTP Observatory baja mi posición en Google?

No hay ninguna declaración de Google en ese sentido. Google dice que, aparte de Core Web Vitals, los aspectos de experiencia de página no ayudan directamente a posicionar. La nota del Observatory mide si usas defensas del navegador contra ataques comunes; mejorarla reduce el riesgo de que te pirateen, y eso sí tiene consecuencias en Google si llega a pasar.

¿Puedo poner las cabeceras de seguridad en una etiqueta meta?

Solo algunas. Una Content-Security-Policy básica puede ir en una etiqueta <meta http-equiv>, pero frame-ancestors no funciona ahí, y X-Frame-Options en una etiqueta meta no tiene ningún efecto. El modo Report-Only, HSTS y los atributos de las cookies solo existen como cabeceras HTTP. Si puedes, configúralas en el servidor o en la CDN.

¿HSTS con preload es peligroso?

Puede serlo si no estás preparado. Una vez que el dominio entra en la lista precargada de los navegadores, todos los subdominios quedan obligados a usar HTTPS, y salir de la lista tarda meses en surtir efecto. Antes de añadir preload, comprueba que cada subdominio, incluidos los internos y los de herramientas de terceros, tiene un certificado válido.

¿Por qué mi CSP rompe Google Analytics o el gestor de etiquetas?

Porque esos servicios cargan scripts y envían datos a dominios que no son el tuyo, y una política con default-src 'self' solo permite el propio. Publica primero la política en modo Report-Only, mira en la consola qué orígenes se bloquearían y añádelos a script-src y connect-src antes de activar la política real.

Qué hacer ahora

Ejecuta la segunda orden de curl sobre tu portada y sobre una URL de cada plantilla, y apunta qué cabeceras faltan. Empieza por nosniff, Referrer-Policy y HSTS, que rara vez rompen nada, y deja la CSP en modo Report-Only unas semanas. Para ver dónde encaja la seguridad en el conjunto, vuelve a la guía de posicionamiento web.