Referer

La cabecera Referer (sí, mal escrita — la especificación HTTP de 1996 estableció la forma canónica como “Referer” y el error tipográfico se convirtió en estándar) es enviada por los navegadores en la mayoría de las solicitudes, conteniendo la URL de la página en la que estaba el usuario cuando activó la solicitud.

Se usa para:

• Análisis web — “¿de dónde vino este tráfico?”
• Prevención de hot-linking — hosts de imágenes que verifican que las solicitudes se originen de sitios aprobados.
• Defensa en profundidad contra CSRF — algunas aplicaciones verifican que Referer coincida con el origen esperado.
• Atribución de afiliados — rastrear qué sitio socio generó una conversión.

Preocupación de privacidad moderna: la URL completa — incluidos tokens, consultas de búsqueda o PII en la ruta URL — se filtra a todos los recursos de terceros que carga la página. La cabecera de respuesta Referrer-Policy (nota: correctamente escrita esta vez) controla cuánta información de referencia envían los navegadores:

• no-referrer: nunca enviar una cabecera Referer.
• same-origin: enviar URL completa a solicitudes del mismo origen, nada a otros.
• strict-origin-when-cross-origin: enviar solo el origen a solicitudes HTTPS de origen cruzado. Predeterminado moderno del navegador.
• unsafe-url: enviar siempre la URL completa. Evitar.

Para aplicaciones sensibles a la privacidad, establece una política estricta en cada respuesta.

El famoso error tipográfico: la cabecera fue propuesta originalmente en 1995 por Phillip Hallam-Baker, y la especificación escribió mal “Referrer” como “Referer” antes de que se detectara el error. Para cuando alguien lo notó, ya había varias implementaciones importantes en funcionamiento. RFC 1945 congeló el error tipográfico como canónico, y todos los navegadores desde entonces han tenido que usar la forma incorrecta para compatibilidad HTTP. Cuando el W3C añadió una cabecera de política en 2014, la escribieron deliberadamente de forma correcta (Referrer-Policy) para diferenciarla de la cabecera de solicitud heredada.

Qué envían los navegadores modernos por defecto: a partir de Chrome 85 (ago. 2020), Firefox 87 (mar. 2021) y Safari 14, la política predeterminada es strict-origin-when-cross-origin. Las solicitudes de origen cruzado ahora reciben solo el origen (https://ejemplo.com), no la URL completa. Las solicitudes del mismo origen siguen recibiendo la URL completa. Este único cambio eliminó una década de filtraciones accidentales de tokens de URL a scripts de análisis y tecnología publicitaria de terceros. Para configuraciones de máxima paranoia (banca, salud), establece Referrer-Policy: no-referrer en cada respuesta. Referencia: W3C — Referrer Policy.

Ejemplo práctico: filtración de URL de restablecimiento de contraseña

Un patrón de vulnerabilidad común: una aplicación envía por correo electrónico un enlace de restablecimiento de contraseña de la forma https://app.example.com/reset?token=abc123def456.... El usuario hace clic; la página de restablecimiento carga e incluye Google Analytics, Facebook Pixel y una librería de gráficos desde un CDN. Bajo la política predeterminada anterior a 2020, cada solicitud de terceros llevaba Referer: https://app.example.com/reset?token=abc123def456... — filtrando el token de restablecimiento a los registros de cuatro proveedores diferentes. Bajo el predeterminado moderno strict-origin-when-cross-origin, las solicitudes de origen cruzado solo llevan Referer: https://app.example.com y el token permanece privado. Aún mejor, establece Referrer-Policy: no-referrer en cada respuesta de flujo sensible — la defensa en profundidad no cuesta nada.

Qué sigue filtrándose a pesar de la política

Referrer-Policy solo gobierna la cabecera Referer. Los tokens de URL todavía aparecen en el historial del navegador, en la propiedad JavaScript document.referrer visible para scripts del mismo origen, en sentencias de registro window.location, y en cualquier SDK de monitoreo de errores que capture URLs. La solución arquitectónica es poner tokens sensibles en el cuerpo de la solicitud o en una cookie de corta duración establecida inmediatamente al aterrizar, luego redirigir a una URL sin el token. Referencia: RFC 9110 — HTTP Semantics §10.1.3 (Referer).