Pon una Referrer-Policy estricta

Qué comprueba esta auditoría

Inspecciona las cabeceras de respuesta buscando una directiva Referrer-Policy y verifica que el valor sea una de las políticas más seguras: strict-origin-when-cross-origin (el default moderno del navegador), strict-origin, same-origin, no-referrer o no-referrer-when-downgrade. La comprobación falla cuando la cabecera falta o tiene una política que filtra (unsafe-url, origin-when-cross-origin sin el prefijo strict-).

Por qué importa

La cabecera de petición Referer (sí, mal escrita en la RFC original y nos toca arrastrarla) le dice a cada sitio al que haces clic desde qué URL vienes. Sin política, el navegador envía la URL completa: path, query string y fragmento.

Es un agujero de privacidad mayor de lo que parece.

• Filtrado de tokens. Los enlaces de reset de contraseña, URLs de magic-login, callbacks de OAuth y URLs de “compartir con este enlace privado” llevan secretos en el path o en el query. Cualquier recurso externo de la página (analítica, fonts, scripts de terceros, imágenes embebidas, enlaces salientes) recibe la URL completa como Referer.
• Filtrado de PII. URLs como /users/jane-patel@example.com/profile o /checkout?email=… filtran datos personales a redes de anuncios y herramientas de analítica.
• Descubrimiento de rutas admin. Un clic desde /admin/users/42 a una imagen externa anuncia silenciosamente la existencia de /admin/ a todos los servicios externos.
• Exposición GDPR. Enviar PII a una red de anuncios de EE. UU. sin consentimiento es una violación de GDPR, intención aparte. Una política de referrer estricta es una mitigación barata.

Los navegadores modernos (Chrome 85+, Firefox 87+, Safari 14+) traen strict-origin-when-cross-origin como default, pero solo cuando la página no devuelve política. Navegadores antiguos y casos límite (orígenes file://, navegaciones http→http) siguen filtrando si no envías la cabecera explícitamente.

Cómo solucionarlo

Elige una política segura y ponla en tus cabeceras de respuesta:

Política	Mismo origen	Cross-origin	Downgrade cross-origin (https→http)
no-referrer	nada	nada	nada
same-origin	URL completa	nada	nada
strict-origin	solo origen	solo origen	nada
strict-origin-when-cross-origin (recomendada)	URL completa	solo origen	nada

strict-origin-when-cross-origin es el default moderno: tus propias navegaciones internas reciben la URL completa (útil para analítica), los enlaces externos solo reciben el origen (https://example.com/), y los downgrades a HTTP no envían nada.

nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

Caddy:

header Referrer-Policy "strict-origin-when-cross-origin"

Cloudflare — Rules → Transform Rules → Modify Response Header, fíjalo globalmente.

Next.js (next.config.js):

module.exports = {
  async headers() {
    return [{
      source: "/(.*)",
      headers: [
        { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
      ],
    }];
  },
};

Express con Helmet:

import helmet from "helmet";
app.use(helmet.referrerPolicy({ policy: "strict-origin-when-cross-origin" }));

Override por enlace. Si un enlace concreto necesita un comportamiento de referrer distinto, usa el atributo referrerpolicy en <a> o <img>:

<a href="https://partner.example.com/" referrerpolicy="no-referrer">Partner</a>

Audítalo tú:

curl -sI https://tudominio.com/ | grep -i referrer-policy

Espera una sola línea con la política elegida. Si grep no devuelve nada, la cabecera falta.

Preguntas frecuentes

¿Esto rompe mi analítica?

No, mientras tu analítica sea same-origin (corriendo en tu dominio) o self-hosted. Las herramientas de analítica cross-origin que dependen de URLs de referrer completas (algunas herramientas de atribución) pueden ver menos datos con strict-origin-when-cross-origin, pero siguen recibiendo el origen, normalmente suficiente para atribuir la visita.

¿Debería usar no-referrer para ir a lo seguro?

no-referrer es lo más seguro pero rompe muchos flujos legítimos: las pasarelas de pago suelen comprobar el referrer para confirmar que un checkout vino de un sitio de comercio real; los proveedores OAuth a veces loguean el referrer para detección de fraude; la analítica se rompe. strict-origin-when-cross-origin es el default correcto.

¿Esto afecta al SEO?

No. Los buscadores no leen la referrer policy. La cabecera solo afecta a clics salientes y cargas de recursos. En términos de SEO es neutra; en privacidad es una mejora real.