Prácticas recomendadas en relación con las políticas de referencias y los referentes

Maud Nalpas

En esta página, se describen algunas prácticas recomendadas para configurar tu política de referencia y usar la URL de referencia en las solicitudes entrantes.

Resumen

• Una filtración inesperada de información de origen cruzado daña la privacidad de los usuarios en la Web. Una política de referencia de protección puede ser útil.
• Te recomendamos establecer una política de URL de referencia de strict-origin-when-cross-origin. Conserva la utilidad de la URL de referencia y, al mismo tiempo, mitiga el riesgo de filtrar datos entre orígenes cruzados.
• No uses URLs de referencia para proteger la falsificación de solicitudes entre sitios (CSRF). En su lugar, usa tokens CSRF y otros encabezados como una capa de seguridad adicional.

Nota:

• Si no sabes cuál es la diferencia entre "sitio" y "origen", consulta Información sobre el "mismo sitio" y el "mismo-origen".
• Falta una R en el encabezado Referer debido a un error ortográfico en la especificación original. El encabezado Referrer-Policy y referrer en JavaScript y el DOM están escritos correctamente.

Política de referencia y referencia 101

Las solicitudes HTTP pueden incluir un encabezado Referer opcional, que indica el origen o la URL de la página web desde la que se realizó la solicitud. El encabezado Referrer-Policy define qué datos están disponibles en el encabezado Referer.

En el siguiente ejemplo, el encabezado Referer incluye la URL completa de la página en site-one desde la que se realizó la solicitud.

Una solicitud HTTP con un encabezado de referencia.

El encabezado Referer puede estar presente en diferentes tipos de solicitudes:

• Solicitudes de navegación, cuando un usuario hace clic en un vínculo
• Solicitudes de subrecursos, cuando un navegador solicita imágenes, iframes, secuencias de comandos y otros recursos que necesita una página

Para iframes y navegaciones, también puedes acceder a estos datos con JavaScript usando document.referrer.

Puedes aprender mucho de los valores Referer. Por ejemplo, un servicio de estadísticas podría usarlos para determinar que el 50% de los visitantes de site-two.example provino de social-network.example. Sin embargo, cuando la URL completa, incluida la ruta de acceso y la cadena de consulta, se envía en Referer de diferentes orígenes, puede poner en peligro la privacidad del usuario y crear riesgos de seguridad:

Usar la URL completa puede afectar la privacidad y seguridad del usuario.

Las URLs 1 a 5 contienen información privada y, a veces, información sensible o de identificación. Filtrar de manera silenciosa entre los orígenes puede comprometer la privacidad de los usuarios web.

La URL 6 es una URL de capacidad. Si alguien que no es el usuario previsto recibe esto, una persona malintencionada puede tomar el control de la cuenta de este usuario.

Para restringir los datos de referencia que estarán disponibles para las solicitudes de tu sitio, puedes establecer una política de URL de referencia.

¿Qué políticas están disponibles y en qué se diferencian?

Puedes seleccionar una de ocho políticas. Según la política, los datos disponibles en el encabezado Referer (y document.referrer) pueden ser los siguientes:

• Sin datos (no hay encabezado Referer)
• Solo el origen
• La URL completa: origen, ruta de acceso y cadena de consulta

Ejemplos de datos de referencia.

Algunas políticas están diseñadas para comportarse de manera diferente según el contexto: solicitud de origen cruzado o del mismo origen, si el destino de la solicitud es tan seguro como el origen, o ambos. Esto es útil para limitar la cantidad de información que se comparte entre los orígenes o a orígenes menos seguros, y al mismo tiempo mantener la riqueza del referente dentro de tu propio sitio.

En la siguiente tabla, se muestra cómo las políticas de referencia restringen los datos de URL disponibles en el encabezado de referencia y document.referrer:

Alcance de la política	Nombre de la política	Referente: Sin datos	Referente: Solo origen	URL de referencia: URL completa
No considera el contexto de la solicitud	no-referrer	verificar
	origin		verificar
	unsafe-url			verificar
Enfocado en la seguridad	strict-origin	Solicitud de HTTPS a HTTP	Solicitud de HTTPS a HTTPS o de HTTP a HTTP
	no-referrer-when-downgrade	Solicitud de HTTPS a HTTP		Solicitud de HTTPS a HTTPS o de HTTP a HTTP
Enfoque en la privacidad	origin-when-cross-origin		Solicitud de origen cruzado	Solicitud del mismo origen
	same-origin	Solicitud de origen cruzado		Solicitud del mismo origen
Centrado en la privacidad y la seguridad	strict-origin-when-cross-origin	Solicitud de HTTPS a HTTP	Solicitud de origen cruzado de HTTPS a HTTPS o de HTTP a HTTP	Solicitud del mismo origen

MDN proporciona una lista completa de políticas y ejemplos de comportamiento.

A continuación, se incluyen algunos aspectos que debes tener en cuenta cuando estableces una política de referentes:

• Todas las políticas que tienen en cuenta el esquema (HTTPS en comparación con HTTP) (strict-origin, no-referrer-when-downgrade y strict-origin-when-cross-origin) tratan las solicitudes de un origen HTTP a otro origen HTTP de la misma manera que las solicitudes de un origen HTTPS a otro, aunque HTTP sea menos seguro. Esto se debe a que para estas políticas lo importante es si se cambia a un cambio a una versión inferior de la seguridad, es decir, si la solicitud puede exponer datos de un origen encriptado a uno no encriptado, como en el caso de las solicitudes HTTPS → HTTP. Una solicitud HTTP → HTTP está completamente sin encriptar, por lo que no se puede cambiar a una versión inferior.
• Si una solicitud es de same-origin, significa que el esquema (HTTPS o HTTP) es el mismo, por lo que no se cambia a una versión inferior de la seguridad.

Políticas de URL de referencia predeterminadas en navegadores

Hasta octubre de 2021

Si no se establece una política de URL de referencia, el navegador usará su política predeterminada.

Navegador	Referrer-Policy predeterminado / comportamiento
Chrome	El valor predeterminado es strict-origin-when-cross-origin.
Firefox	El valor predeterminado es strict-origin-when-cross-origin. A partir de la versión 93, para los usuarios de Protección estricta contra seguimiento y Navegación privada, se ignoran las políticas de referentes menos restrictivas no-referrer-when-downgrade, origin-when-cross-origin y unsafe-url para las solicitudes entre sitios, lo que significa que la URL de referencia siempre se corta para las solicitudes entre sitios, independientemente de la política del sitio web.
Perimetrales	El valor predeterminado es strict-origin-when-cross-origin.
Safari	El valor predeterminado es similar a strict-origin-when-cross-origin, con algunas diferencias específicas. Consulta Cómo evitar el seguimiento de prevención de seguimiento para obtener más detalles.

Prácticas recomendadas para configurar la política de URLs de referencia

Objetivo: Establecer de forma explícita una política que mejore la privacidad, como strict-origin-when-cross-origin(o más estricta).

Existen diferentes maneras de establecer políticas de URL de referencia para tu sitio:

• Como un encabezado HTTP
• Dentro de tu archivo HTML
• Desde JavaScript por solicitud

Puedes establecer distintas políticas para diferentes páginas, solicitudes o elementos.

El encabezado HTTP y el metaelemento corresponden al nivel de la página. El orden de prioridad para determinar la política vigente de un elemento es el siguiente:

1. Política a nivel de elemento
2. Política a nivel de página
3. Navegador predeterminado

Ejemplo:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

La imagen se solicita con una política no-referrer-when-downgrade, y todas las demás solicitudes de subrecursos de esta página siguen la política strict-origin-when-cross-origin.

¿Cómo consultar la política de referentes?

securityheaders.com es útil para determinar qué política usa un sitio o una página específica.

También puedes usar las herramientas para desarrolladores en Chrome, Edge o Firefox a fin de ver la política de referencia que se usa para una solicitud específica. En el momento en que se redacta este documento, Safari no muestra el encabezado Referrer-Policy, pero muestra el Referer que se envió.

Panel Network de las Herramientas para desarrolladores de Chrome con una solicitud seleccionada.

¿Qué política deberías establecer para tu sitio web?

Te recomendamos que establezcas de forma explícita una política que mejore la privacidad, como strict-origin-when-cross-origin (o una más estricta).

¿Por qué "de forma explícita"?

Si no estableces una política de URL de referencia, se usará la política predeterminada del navegador. De hecho, los sitios web suelen elegir la política predeterminada del navegador. Sin embargo, esto no es ideal por los siguientes motivos:

• Los distintos navegadores tienen políticas predeterminadas diferentes. Por lo tanto, si dependes de las opciones predeterminadas, tu sitio no se comportará de forma predecible en ellos.
• Los navegadores están adoptando valores predeterminados más estrictos, como strict-origin-when-cross-origin, y mecanismos como el recorte de referencias para solicitudes de origen cruzado. Habilitar de forma explícita una política que mejore la privacidad antes de que cambie la configuración predeterminada del navegador, te brinda el control y te ayuda a ejecutar pruebas como estimes conveniente.

¿Por qué strict-origin-when-cross-origin (o más estricto)?

Necesitas una política que sea segura, útil y que mejore la privacidad. El significado de “útil” depende de lo que deseas del referente:

• Seguro: Si tu sitio web usa HTTPS (de lo contrario, haz que sea una prioridad), no querrás que las URLs de tu sitio web filtren solicitudes no HTTPS. Como cualquier persona en la red puede verlos, las fugas exponerían a tus usuarios a ataques de intermediarios. Las políticas no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer y strict-origin solucionan este problema.
• Mejora la privacidad: En una solicitud de origen cruzado, no-referrer-when-downgrade comparte la URL completa, lo que puede causar problemas de privacidad. strict-origin-when-cross-origin y strict-origin solo comparten el origen, y no-referrer no comparte nada. Esto deja strict-origin-when-cross-origin, strict-origin y no-referrer como opciones que mejoran la privacidad.
• Útil: no-referrer y strict-origin nunca comparten la URL completa, ni siquiera para solicitudes del mismo origen. Si necesitas la URL completa, strict-origin-when-cross-origin es una mejor opción.

Todo esto significa que strict-origin-when-cross-origin suele ser una opción sensible.

Ejemplo: Mediante la configuración de una política de strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

O del servidor, por ejemplo en Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

¿Qué sucede si strict-origin-when-cross-origin (o uno más estricto) no se adapta a todos tus casos de uso?

En este caso, adopta un enfoque progresivo: establece una política de protección como strict-origin-when-cross-origin para el sitio web y, de ser necesario, una política más permisiva para solicitudes o elementos HTML específicos.

Ejemplo: política a nivel de elemento

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari o WebKit podría limitar document.referrer o el encabezado Referer para solicitudes entre sitios. Consulta los detalles.

Ejemplo: política a nivel de la solicitud

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

¿Qué más deberías tener en cuenta?

La política debe depender del sitio web y los casos de uso que tú, tu equipo y tu empresa determinan. Si algunas URLs contienen datos de identificación o sensibles, establece una política de protección.

Advertencia: Es posible que los datos que no te parezcan sensibles sean sensibles para los usuarios o que no sean datos que quieran o no esperen que se filtren silenciosamente en orígenes cruzados.

Prácticas recomendadas para solicitudes entrantes

Estos son algunos lineamientos sobre qué hacer si tu sitio utiliza la URL de referencia de las solicitudes entrantes.

Protege los datos de los usuarios

El Referer puede contener datos privados, personales o de identificación, así que asegúrate de tratarlos como tales.

Las URLs de referencia entrantes pueden cambiar {referer-can-change}

El uso de la URL de referencia de las solicitudes entrantes de origen cruzado tiene las siguientes limitaciones:

• Si no tienes control sobre la implementación del emisor de la solicitud, no puedes hacer suposiciones sobre el encabezado Referer (y el document.referrer) que recibes. El emisor de la solicitud podría decidir cambiar a una política no-referrer en cualquier momento o, de manera más general, a una política más estricta que la que usó antes. Esto significa que recibes menos datos de Referer que antes.
• Los navegadores usan cada vez más la política de referencia strict-origin-when-cross-origin de forma predeterminada. Esto significa que es posible que ahora recibas solo el origen, en lugar de una URL de referencia completa, en las solicitudes entrantes de origen cruzado, si el sitio del remitente no tiene establecida ninguna política.
• Es posible que los navegadores cambien la forma en que administran Referer. Por ejemplo, algunos desarrolladores de navegadores podrían decidir siempre cortar las URLs de referencia según los orígenes de las solicitudes de subrecursos de origen cruzado para proteger la privacidad del usuario.
• El encabezado Referer (y document.referrer) puede contener más datos de los necesarios. Por ejemplo, es posible que tenga una URL completa cuando solo quieras saber si la solicitud es de origen cruzado.

Alternativas a Referer

Es posible que debas considerar alternativas en los siguientes casos:

• Una función esencial de tu sitio usa la URL de referencia de las solicitudes entrantes de origen cruzado.
• Tu sitio ya no recibe la parte de la URL de referencia que necesita en una solicitud de origen cruzado. Esto sucede cuando el emisor de la solicitud cambia su política o cuando no tiene establecida ninguna política y cambia la política predeterminada del navegador (como en Chrome 85).

Para definir alternativas, primero analiza qué parte de la URL de referencia usas.

Si solo necesitas el origen

• Si usas la URL de referencia en una secuencia de comandos que tiene acceso de nivel superior a la página, window.location.origin es una alternativa.
• Si están disponibles, los encabezados como Origin y Sec-Fetch-Site te proporcionan el Origin o describen si la solicitud es de origen cruzado, que podría ser exactamente lo que necesitas.

Si necesitas otros elementos de la URL (ruta, parámetros de consulta, etc.)

• Los parámetros de solicitud pueden abordar tu caso de uso, lo que te ahorra el trabajo de analizar la URL de referencia.
• Si usas la URL de referencia en una secuencia de comandos que tiene acceso de nivel superior a la página, window.location.pathname podría funcionar como alternativa. Extrae solo la sección de la ruta de acceso de la URL y pásala como argumento, de modo que no se pase información potencialmente sensible en los parámetros de la URL.

Si no puedes usar estas alternativas, haz lo siguiente:

• Verifica si puedes cambiar tus sistemas para que el emisor de la solicitud (por ejemplo, site-one.example) establezca de forma explícita la información que necesitas en algún tipo de configuración.
  • Ventaja: Más explícito, más preservador de la privacidad para los usuarios de site-one.example y más preparado para el futuro
  • Desventaja: Posiblemente, más trabajo de tu parte o de los usuarios del sistema.
• Verifica si el sitio que emite las solicitudes podría aceptar establecer una política de referencia de no-referrer-when-downgrade por elemento o por solicitud.
  • Desventaja: La preservación de la privacidad podría ser menor para los usuarios de site-one.example (posiblemente, no se admite en todos los navegadores).

Protección contra la falsificación de solicitudes entre sitios (CSRF)

Un emisor de solicitudes siempre puede decidir no enviar la URL de referencia configurando una política no-referrer, y un actor malicioso podría incluso falsificar la URL de referencia.

Usa los tokens CSRF como protección principal. Para obtener protección adicional, usa SameSite y, en lugar de Referer, usa encabezados como Origin (disponible en solicitudes POST y CORS) y Sec-Fetch-Site, si está disponible.

Registro y depuración

Asegúrate de proteger los datos personales o sensibles de los usuarios que puedan estar en Referer.

Si solo usas el origen, verifica si puedes usar el encabezado Origin como alternativa. Esto podría proporcionarte la información que necesitas para fines de depuración de manera más simple y sin necesidad de analizar la URL de referencia.

de pagos

Los proveedores de pagos pueden depender del encabezado Referer de las solicitudes entrantes para realizar verificaciones de seguridad.

Por ejemplo:

• El usuario hace clic en un botón Comprar en online-shop.example/cart/checkout.
• online-shop.example redirecciona a payment-provider.example para administrar la transacción.
• payment-provider.example verifica el Referer de esta solicitud con una lista de valores Referer permitidos establecidos por los comercios. Si no coincide con ninguna entrada de la lista, payment-provider.example rechaza la solicitud. Si coincide, el usuario puede continuar con la transacción.

Prácticas recomendadas para los controles de seguridad del flujo de pagos

Como proveedor de pagos, puedes usar Referer como verificación básica contra algunos ataques. Sin embargo, el encabezado Referer por sí solo no es una base confiable para una verificación. El sitio que realiza la solicitud, independientemente de si es un comercio legítimo o no, puede establecer una política no-referrer que haga que la información de Referer no esté disponible para el proveedor de pagos.

Mirar Referer podría ayudar a los proveedores de pagos a detectar atacantes ingenuos que no establecieron una política no-referrer. Si usas Referer como primera verificación, sucede lo siguiente:

• No esperes que Referer esté siempre presente. Si está presente, compárala solo con la cantidad mínima de datos que puede incluir, que es el origen.
  • Cuando configures la lista de valores Referer permitidos, asegúrate de incluir solo el origen, y ninguna ruta de acceso.
  • Por ejemplo, los valores Referer permitidos para online-shop.example deben ser online-shop.example, no online-shop.example/cart/checkout. Si esperas que no haya un Referer o un valor de Referer que sea solo el origen del sitio solicitante, se evitan errores que puedan surgir cuando se hacen suposiciones sobre el Referrer-Policy del comercio.
• Si Referer no está, o si está presente, y tu verificación básica de origen de Referer se realiza correctamente, puedes pasar a otro método de verificación más confiable.

Para verificar los pagos de manera más confiable, permite que el solicitante genere un hash en los parámetros de la solicitud junto con una clave única. Los proveedores de pagos pueden calcular el mismo hash de tu lado y solo aceptar la solicitud si coincide con tu cálculo.

¿Qué sucede con el Referer cuando un sitio de comercio HTTP sin política de URL de referencia redirecciona a un proveedor de pagos HTTPS?

No se puede ver ningún Referer en la solicitud al proveedor de pagos HTTPS, ya que la mayoría de los navegadores usan strict-origin-when-cross-origin o no-referrer-when-downgrade de forma predeterminada cuando un sitio web no tiene establecida ninguna política. El cambio de Chrome a una nueva política predeterminada no cambiará este comportamiento.

Nota: Si tu sitio web usa HTTP, migra a HTTPS.

Conclusión

Una política de referencia de protección es una excelente manera de brindar más privacidad a tus usuarios.

Si deseas obtener más información sobre las diferentes técnicas para proteger a los usuarios, consulta nuestra colección Seguridad y protección.

Recursos

• Información sobre las palabras "same-site" y "same-origin"
• Un nuevo encabezado de seguridad: Política de referencias (2017)
• Política de referencia sobre MDN
• Encabezado de referencia: inquietudes sobre la privacidad y la seguridad en MDN
• Cambio de Chrome: Blink intent para implementar
• Cambio de Chrome: Blink intent para enviar
• Cambio de Chrome: entrada de estado
• Cambio de Chrome: entrada de blog beta 85
• Referencia del subproceso de GitHub para cortar la referencia: Qué hacen los distintos navegadores
• Especificaciones de la política de referencia

Agradecemos las contribuciones y los comentarios a todos los revisores, en especial a Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck y Kayce Basques.