El encabezado Referer llegó a la especificación en la era de los módems. Nadie discutió mucho: al servidor le resulta útil saber de dónde vino el usuario. Ha pasado un cuarto de siglo, los navegadores cambiaron de motor, y la letra en el nombre sigue faltando. La paradoja es que junto con la ortografía arcaica se mantuvo la mala costumbre de revelar de más. Analizamos por qué este detalle, aparentemente pequeño, todavía causa problemas.
Origen del Referer y qué transmite
La primera versión del protocolo HTTP la escribieron ingenieros, no abogados de privacidad. Por eso el encabezado siempre incluía la URL completa: con protocolo, dominio, ruta y todo lo que sigue al signo de interrogación. Si el enlace contiene un token de sesión o un identificador único de compra, este se envía con el usuario sin preguntas. RFC 9110 explica con claridad que debe escribirse exactamente «Referer», y no «Referrer», porque de lo contrario se rompería una gran parte de los sistemas antiguos. Leer en el RFC
Fragmentos de datos que con más frecuencia se filtran
- Parámetros de consulta con tokens de corta duración.
- Números de pedidos, invitaciones y facturas.
- Cadena de búsqueda cuando se envía por GET y no por POST.
Por qué un atacante se alegra por cada Referer
El propio encabezado no rompe nada. Es solo un mensajero. Pero a veces eso basta. Imagine que un script externo, insertado por una bonita botonera, recibe el fragmento ?csrf=9f8e7. Si la política de referer del servidor no está configurada, el token acabará en los registros de una tercera parte. Solo le quedará pulsar el botón rojo conocido.
Cuatro escenarios reales de explotación
CSRF mediante imagen
La página renderiza un banner desde otro dominio y en la URL del usuario cuelga un token de un solo uso. La petición de la imagen lleva el token a la red publicitaria — el resto es técnica habitual: repetir la petición con el token y obtener éxito.
Frases de búsqueda en registros ajenos
La búsqueda interna del portal devuelve resultados mediante redirección. Un empleado busca "informe anual de salarios", hace clic en el documento y el tracker en el CDN externo está contento: la frase sensible llegó en el Referer.
Desanonimización en foros
El autor publica un enlace a un archivo personal en la nube. Cualquier salto a enlaces externos desde la misma página revela la URL privada a los propietarios del sitio externo.
Acceso al sistema interno de tickets
Soporte intercambia enlaces como /ticket/4815?auth=temp. Si el empleado hace clic en un recurso externo sin rel="noreferrer", la clave temporal se filtra.
Qué ya hacen los navegadores y por qué no es suficiente
Desde mediados de los años 2020 todos los navegadores principales cambiaron a la política strict-origin-when-cross-origin. Esta recorta el referer al pasar de HTTPS a HTTP, pero al navegar entre dos sitios HTTPS la cadena de consulta queda intacta. Para la mayoría de los ataques eso es suficiente.
Referrer-Policy como línea base de defensa
La opción «añadir el encabezado y olvidarse» se ve así:
Referrer-Policy: no-referrer
Si se necesitan datos para analítica, se puede suavizar a strict-origin o origin-when-cross-origin. La documentación detallada está en MDN.
Atributos de enlaces y microparches en el marcado
Ya que escribimos HTML, añada rel="noopener noreferrer" a todos los enlaces externos. Es barato, inmediato y casi no afecta las estadísticas.
SPA y la metaetiqueta referrer
Las aplicaciones de una sola página duran más de lo que parece. Dedique cinco minutos y coloque en el <head> la línea:
<meta name="referrer" content="strict-origin">El navegador aplicará la regla a todos los enlaces dinámicos de React, Vue o Angular, incluso si el desarrollador front-end subcontratado olvidó la seguridad.
Service Worker como herramienta quirúrgica
Cuando se necesita filtrado puntual, interceptar fetch en el Service Worker y anular request.referrer para hosts sospechosos. Es flexible, pero requiere disciplina: una comprobación débil y volverá a cero.
Recordatorio para desarrolladores
- No almacene secretos en parámetros GET si se pueden poner en el cuerpo de la petición.
- Compruebe qué referer envían sus páginas usando la pestaña «Network» en DevTools.
- Active
no-referrerpor defecto y debilite la política solo donde esté justificado. - Recorra el proyecto con el escáner OWASP ZAP o al menos SecurityHeaders.
- No confíe en scripts de terceros: verifique que no cambien la política en tiempo de ejecución.
Herramientas que ahorran tiempo
- WaybackURLs — extrae URL antiguos del Web Archive; a veces aparecen tokens olvidados.
- Smart Referer — extensión para Firefox que muestra en color qué se filtra.
- Un
curl -Ibásico con la opción-e— forma rápida de ver qué envía realmente su página.
Ideas erróneas comunes
«Todo está en HTTPS, no hay fugas»
Es cierto que un proxy interceptador no verá el cuerpo de la petición. Sin embargo, el sitio externo al que va el visitante recibirá la URL completa. Si contiene un token, se lo acaba de regalar.
«El navegador recorta la cadena de consulta si los dominios son distintos»
No siempre. La política estándar recorta solo al pasar de HTTPS a HTTP. Moverse entre dos sitios seguros dejará los parámetros intactos.
«El referer completo es crítico para analítica»
Muestre a los analistas un informe con el referer recortado; casi seguro que les basta con el dominio. Las UTM en la cadena de consulta rara vez compensan el riesgo.
Si es responsable de los riesgos del negocio
Los reguladores endurecen los requisitos sobre datos personales. Si su sector está sujeto a GDPR, HIPAA o equivalentes locales, una filtración por Referer es un caso listo para sanciones. Configure no-referrer por defecto y lance las campañas de marketing en subdominios con una política más laxa.
Sin grandes finales
Referer no es la brecha más ruidosa, pero junto con otras pequeñas fallas puede convertirse en un problema serio. Es mejor corregirla antes de que alguien decida aprovechar ese canal silencioso de transmisión de datos.
