Defaults.Exposed › Soluciones › Referrer-Policy

Cómo arreglar Referrer-Policy

Una Referrer-Policy es una instrucción de una sola línea que tu sitio web entrega al navegador de cada visitante y que controla cuánta parte de tu dirección web viaja con él cuando hace clic en un enlace hacia otro sitio. Sin ella, la dirección completa de la página en la que estuviera —términos de búsqueda, números de cuenta, enlaces de restablecimiento, rutas internas y todo lo demás— se entrega sin hacer ruido al siguiente sitio al que llegue, incluidos anunciantes, empresas de analítica y cualquier otro lugar al que apunte un enlace.

En resumen, para tu negocio: Cada vez que un visitante hace clic en un enlace saliente, un anuncio o un recurso compartido, su navegador puede entregar la dirección completa de tu página al destino; y si tus direcciones llevan consultas de búsqueda, identificadores de cliente, números de pedido o enlaces de un solo uso, estás filtrando datos de clientes a terceros que no controlas. Eso es un problema de protección de datos que los reguladores se toman en serio, una promesa de privacidad rota sin ruido y un hueco puntuado que el equipo de seguridad de un cliente señalará durante la diligencia debida.

Lo que esto te puede costar

• Un cliente rellena un formulario o hace una búsqueda, luego hace clic en un enlace saliente o un anuncio, y la dirección de la página, con todo lo que escribió incluido, se entrega directamente a un anunciante o una empresa de analítica con la que nunca quisiste compartirla.
• Los enlaces de restablecimiento de contraseña y de confirmación de cuenta a veces llevan un testigo secreto en la dirección web; sin esta cabecera, hacer clic en cualquier enlace de esa página puede pasar la dirección entera —testigo incluido— a un sitio externo.
• Rutas internas privadas (áreas de administración, páginas solo para clientes, niveles de precios, enlaces a documentos) quedan reveladas a cada tercero al que tus visitantes hagan clic, entregando a competidores y fisgones un mapa de tu sitio que nunca deberían ver.
• Una revisión de seguridad de un cliente o una auditoría de privacidad analiza tu sitio, no ve ninguna Referrer-Policy y lo registra como un fallo de minimización de datos: el tipo de hallazgo que frena un contrato o una certificación.
• Datos personales acaban en manos de encargados de tratamiento con los que no tienes ningún acuerdo, convirtiendo un descuido de cinco minutos en una brecha de protección de datos notificable.

Por qué importa. Los navegadores, a su aire, son charlatanes: por defecto le dicen al siguiente sitio web de dónde acaba de venir un visitante, a menudo incluyendo la dirección completa de la página. Para un sitio de escaparate eso puede ser inofensivo, pero en cuanto tus direcciones contienen algo personal —un término de búsqueda, un identificador de pedido, un correo en un enlace, una ruta privada— ese comportamiento por defecto lo filtra sin ruido a terceros. Una Referrer-Policy es el único ajuste que indica a los navegadores que dejen de compartir de más. Es una comprobación puntuada en tu informe que vale puntos reales, se corresponde directamente con los deberes de minimización de datos de la ley de privacidad y es una de las cabeceras de seguridad estándar que cualquier revisión profesional espera encontrar.

Qué es esto, en palabras llanas

Cada vez que un visitante de tu sitio web hace clic en un enlace hacia otro sitio —un enlace saliente, un banner publicitario, un «comparte esto», incluso una fuente o imagen cargada desde otro lugar— su navegador adjunta sin ruido una nota que indica de qué página tuya venía. Esa nota se llama el referente.

Usado con sensatez, el referente es inofensivo e incluso útil: es como otros sitios saben que el tráfico vino de ti, y mueve buena parte de la analítica honesta. La pega está en el comportamiento por defecto. Sin gestionar, el navegador no se limita a decir «vinieron de tu-empresa.com»: a menudo entrega la dirección completa de la página exacta, incluyendo todo lo que va después del nombre del dominio. Y las direcciones web llevan mucho más de lo que la gente cree: términos de búsqueda escritos en tu sitio, números de pedido y de cuenta, la ruta a una página privada solo para miembros, incluso testigos secretos de un solo uso en enlaces de restablecimiento de contraseña y de confirmación.

Una Referrer-Policy es una sola instrucción que tu sitio web envía al navegador y que dice cuánta parte de esa nota se le permite compartir. Puedes indicarle que comparta solo el nombre de tu dominio, solo con otras páginas de tu propio sitio, o nada en absoluto. Piénsalo como la diferencia entre entregar a un desconocido la dirección completa de tu casa con tu horario diario adjunto, frente a decirle solo en qué ciudad vives.

Esta es una de una pequeña familia de «cabeceras de seguridad»: instrucciones breves que tu sitio da al navegador de cada visitante. No cambia el aspecto ni el funcionamiento de tu sitio. Simplemente impide que el navegador comparta de más en tu nombre.

Lo que esto puede costarte

Aquí van formas concretas y cotidianas en que una Referrer-Policy ausente o permisiva muerde a empresas reales. Ninguna requiere un hacker: ocurren automáticamente, cada día, en el uso normal.

• La búsqueda filtrada. Un cliente busca en tu sitio algo sensible —un producto médico, un servicio relacionado con deudas, una comparación con la competencia— y el término de búsqueda acaba en la dirección de la página. Luego hace clic en un enlace saliente o un anuncio de esa página de resultados. El anunciante ahora recibe tu dirección con el término de búsqueda dentro, sabiendo exactamente qué buscaba tu cliente. Nunca aceptaste compartir eso, y no puedes recuperarlo.

• El enlace de restablecimiento expuesto. Muchos sistemas ponen un testigo secreto de un solo uso en la dirección de las páginas de restablecimiento de contraseña, confirmación de correo o «inicio de sesión mágico». Si esa página contiene cualquier enlace saliente o recurso de terceros, la dirección completa —testigo incluido— puede entregarse a un sitio externo. En el peor caso, eso entrega a un tercero las llaves de una cuenta.

• El mapa del sitio que regalaste. Tus rutas internas suelen revelar tu estructura: /admin, /precios-empresa, /clientes/acme, /descargas/informe-privado. Sin esta cabecera, cada sitio externo al que tus visitantes hagan clic recibe esas rutas. Los competidores aprenden tus niveles de precios y líneas de producto; los rastreadores aprenden a qué páginas apuntar.

• La relación de intercambio de datos no deseada. La ley de privacidad espera que sepas a quién van los datos personales de tus clientes y que tengas un acuerdo en vigor. Filtrar direcciones de página que contienen identificadores de cliente o direcciones de correo a redes publicitarias y empresas de analítica —sin acuerdo y sin consentimiento— es exactamente el tipo de flujo de datos descontrolado que convierte una auditoría rutinaria en un hallazgo, y un hallazgo en una brecha notificable.

• El acuerdo que se estanca en la diligencia debida. Cuando el equipo de seguridad de un cliente grande te revisa, que falten cabeceras de seguridad estándar es una casilla rápida y automatizada. Ver ausente la Referrer-Policy les dice que la higiene básica de privacidad nunca se configuró, y esa impresión tiñe todo lo demás de la revisión.

Qué es en realidad

Por defecto, los navegadores siguen un comportamiento aproximadamente equivalente a «strict-origin-when-cross-origin» en las versiones modernas, pero no puedes confiar en ello, porque los navegadores más antiguos, las webviews incrustadas y ciertas configuraciones todavía recaen en filtrar más. La única forma de estar seguro es establecer la política explícitamente. Cuando lo haces, eliges una regla de una lista corta. Las que importan:

• no-referrer — no compartir nada. Al siguiente sitio no se le dice nada sobre de dónde vino el visitante. Privacidad máxima; puede mermar tu analítica de referidos.
• same-origin — compartir la dirección completa solo cuando el visitante se mueve entre páginas de tu propio sitio; no compartir nada con sitios externos.
• strict-origin-when-cross-origin — el valor recomendado por defecto. Dentro de tu propio sitio, se comparte la ruta completa; con sitios externos, solo se comparte tu nombre de dominio escueto (y nada en absoluto al pasar de una página segura a una insegura). Los terceros saben que el tráfico vino de ti, pero nunca los detalles privados posteriores a tu dominio.
• origin — compartir siempre solo el nombre de tu dominio, incluso dentro de tu propio sitio.

Y los dos valores que hay que evitar, porque el informe los trata como nada mejor que no tener cabecera:

• unsafe-url — compartir la dirección completa con todos, siempre. El peor caso en una sola palabra.
• no-referrer-when-downgrade — el antiguo valor por defecto de los navegadores; sigue enviando la dirección completa a otros sitios seguros, filtrando todo lo descrito arriba.

Cómo es lo «bueno»: hay una cabecera Referrer-Policy presente y establecida en un valor restrictivo; para la mayoría de las empresas, strict-origin-when-cross-origin. Esto mantiene la analítica de referidos funcionando a la vez que garantiza que nada posterior al nombre de tu dominio llegue jamás a un sitio externo.

Cómo solucionarlo (gratis, unos 5 minutos)

Pásale este apartado a tu informático, tu desarrollador web o el soporte de tu hosting: la solución es gratuita, es una sola línea y no romperá tu sitio. Aquí no hay despliegue arriesgado: a diferencia de algunos ajustes de seguridad, una Referrer-Policy sensata no puede impedir que tus enlaces o páginas funcionen. Solo recorta lo que se comparte con otros sitios.

El objetivo: establecer una cabecera de respuesta Referrer-Policy con el valor strict-origin-when-cross-origin (o un valor más estricto si prefieres compartir aún menos).

Cloudflare (sin código, lo más fácil si lo usas): Panel → tu dominio → Rules → Transform Rules → Modify Response Header → Create rule → Set static → nombre de cabecera Referrer-Policy, valor strict-origin-when-cross-origin → aplicar a todas las peticiones entrantes → Deploy.

Google Workspace / Microsoft 365: estos gestionan tu correo, no tu sitio web, así que la cabecera se pone donde tu sitio esté realmente alojado (tu hosting web, CDN o servidor), no en la administración de Workspace o 365. Identifica el hosting y usa la opción correspondiente de abajo.

Nginx:

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

Apache (en la configuración del sitio o en .htaccess):

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

IIS (web.config):

<httpProtocol><customHeaders>
  <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders></httpProtocol>

Node / Express:

app.use((req, res, next) => { res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); next(); });

WordPress / hostings comunes: la mayoría de los WordPress gestionados y los hostings compartidos permiten añadir cabeceras de respuesta a través de un plugin de seguridad, un panel de «cabeceras» en el panel de control del hosting, o el fragmento de .htaccess de arriba. Si estás detrás de Cloudflare, el método de Cloudflare es el más limpio y se aplica en todas partes a la vez.

Tras aplicarlo: carga tu sitio y vuelve a ejecutar la comprobación, o usa las herramientas de desarrollo de tu navegador (pestaña Red → clic en el documento principal → Cabeceras de respuesta) para confirmar que Referrer-Policy: strict-origin-when-cross-origin está presente.

Errores habituales

• Poner un valor permisivo y suponer que cuenta. unsafe-url y no-referrer-when-downgrade siguen filtrando la dirección completa. El informe los puntúa con cero, idéntico a no tener cabecera. Si la cabecera está presente pero los puntos no, casi siempre es por esto.
• Ponerla solo en la página de inicio. La cabecera debe enviarse en cada página, porque las filtraciones ocurren en las páginas de resultados de búsqueda, de cuenta y de restablecimiento, no en la portada. Ponla a nivel de servidor, CDN o Cloudflare para que se aplique a todo el sitio automáticamente.
• Ponerla solo en etiquetas <meta> de HTML. Una etiqueta <meta name="referrer"> funciona en algunos casos pero no en todos, y es fácil que quede inconsistente entre páginas. Ponerla como una cabecera de respuesta en condiciones (los métodos de arriba) es el enfoque fiable.
• Dejar que una capa anule a otra. Si tanto tu servidor de origen como tu CDN ponen la cabecera con valores distintos, el resultado puede ser impredecible. Elige un solo lugar para gestionarla —normalmente el CDN o Cloudflare si tienes uno— y mantén el resto coherente.
• Tratarla como sustituto de no meter datos en las URL. La cabecera limita el daño, pero el hábito más limpio a largo plazo es no poner secretos ni datos personales en las direcciones web, para empezar. Usa la cabecera ahora; plantea la higiene de URL con tu desarrollador como un seguimiento.

Una nota rápida sobre las cabeceras relacionadas

Referrer-Policy va junto a un pequeño conjunto de otras cabeceras de seguridad web que comprobamos: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options y unas cuantas cabeceras avanzadas de origen cruzado. Protegen cosas distintas, así que tener una no cubre las demás. Si tu Referrer-Policy falta, conviene pedir a quien la arregle que confirme que las otras cabeceras estándar están en su sitio al mismo tiempo, ya que normalmente se configuran en ese mismo único lugar y la visita no cuesta nada extra.

En resumen

Referrer-Policy es la solución de privacidad más barata y segura de tu informe: una línea, unos cinco minutos, sin riesgo de romper nada, y gratis. Impide que los navegadores de tus visitantes entreguen sin ruido tus direcciones de página privadas —y los datos personales que contengan— a cada sitio externo al que hagan clic. Ponla en strict-origin-when-cross-origin, confirma que está activa en cada página, y el hueco de severidad media y sus 15 puntos quedan cerrados.

Preguntas frecuentes