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

Maud Nalpas

Esta página describe algunas prácticas recomendadas para establecer una política de URL de referencia y usando la URL de referencia en solicitudes entrantes.

Resumen

• La filtración inesperada de información de origen cruzado daña a los usuarios web la privacidad. R puede ayudar con la política de URL de referencia protectora.
• Considera establecer una política de URL de referencia de strict-origin-when-cross-origin. Integra conserva la mayor parte de la utilidad de la URL de referencia, a la vez que mitiga el riesgo de filtrar orígenes cruzados de datos.
• No uses URLs de referencia para la protección contra la falsificación de solicitudes entre sitios (CSRF). Usa Tokens CSRF en su lugar, y otros encabezados como una capa de seguridad adicional.

Nota:

.
• Si no está seguro de la diferencia entre "sitio" y "origin", consulta Acerca de "same-site" y "same-origin".
• Al encabezado Referer le falta una R 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 referencias y referencias 101

Las solicitudes HTTP pueden incluir un encabezado Referer opcional. que indique 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 del página de 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 otros recursos que necesita una página.

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

Puedes aprender mucho de los valores de Referer. Por ejemplo, un servicio de análisis podría utilizarlas para determinar que el 50% de los visitantes de site-two.example llegó a desde social-network.example. Pero cuando la URL completa, incluidas la ruta de acceso y cadena de consulta, se envía en Referer de todos los orígenes, puede poner en peligro la privacidad y crear riesgos de seguridad:

El uso de la URL completa puede afectar la privacidad del usuario y seguridad.

Las URL n.° 1 a n.° 5 contienen información privada y, a veces, información de identificación personal. Filtrar estos datos silenciosamente entre los orígenes puede comprometer usuarios web la privacidad.

La URL n° 6 es una URL de capacidad. Si alguien excepto que el usuario previsto recibe esto, un agente malicioso puede tomar el control de la cuenta de este usuario.

Para restringir qué datos de referencia están disponibles para solicitudes provenientes de tu sitio, puedes establecer una política de URLs de referencia.

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

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

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

Ejemplos de datos de la URL de referencia.

Algunas políticas están diseñadas para comportarse de manera diferente según el contexto: solicitudes de origen cruzado o del mismo origen, ya sea que el destino de la solicitud sea seguro como origen, o ambos. Esto es útil para limitar la cantidad de información compartidos entre orígenes o con orígenes menos seguros, mientras se mantiene la riqueza de la URL de referencia en tu propio sitio.

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

Alcance de la política	Nombre de la política	Referente: Sin datos	URL de referencia: solo origen	URL de referencia: URL completa
No considera el contexto de la solicitud.	no-referrer	verificación
	origin		verificación
	unsafe-url			verificación
Enfoque 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 centrado 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
Se enfocan 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

La MDN brinda una lista completa de políticas y comportamientos ejemplos comunes.

Estos son algunos puntos que debes tener en cuenta cuando configures una política de URL de referencia:

• 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 a otro origen HTTP de la misma manera que las solicitudes de un origen HTTPS a otro origen HTTPS, incluso si HTTP es menos seguro. Eso se debe a que, para estos de seguridad, lo que importa es si se reduce el nivel de seguridad que es si la solicitud puede exponer datos de un origen encriptado a un como en las solicitudes HTTPS → HTTP. Una solicitud HTTP → HTTP es completamente y sin encriptar, por lo que no hay que cambiar a una versión inferior.
• Si una solicitud es same-origin, significa que el esquema (HTTPS o HTTP) se igual, por lo que no hay un cambio a una versión inferior de seguridad.

Políticas de URL de referencia predeterminadas en navegadores

Hasta octubre de 2021

Si no estableces una política de referente, el navegador usa su política predeterminada.

Navegador	Referrer-Policy / Comportamiento predeterminado
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 la Protección estricta contra seguimiento y los usuarios de navegación privada, menos políticas de URL de referencia restrictivas no-referrer-when-downgrade, origin-when-cross-origin y unsafe-url son Se ignoran 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.
Edge	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 Evita el seguimiento de la prevención del seguimiento para obtener más detalles.

Prácticas recomendadas para configurar una política de URL de referencia

Objetivo: Establece 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
• En tu HTML
• Desde JavaScript por solicitud

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

El encabezado HTTP y el elemento meta están a nivel de la página. El orden de prioridad determinar la política vigente de un elemento es la siguiente:

1. Política de nivel de elemento
2. Política a nivel de la página
3. Predeterminado del navegador

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 las solicitudes de subrecursos de esta página deben seguir la strict-origin-when-cross-origin .

¿Cómo puedo ver la política de referentes?

securityheaders.com es útil para determinar qué la política que utiliza una página o un sitio específicos.

También puedes usar las herramientas para desarrolladores en Chrome, Edge o Firefox para consultar para una solicitud específica. Al momento de la redacción de este documento, Safari no muestra el encabezado Referrer-Policy, pero sí el Referer que se enviados.

Herramientas para desarrolladores de Chrome Panel Network 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 más estricta).

¿Por qué "explícitamente"?

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

• Los diferentes navegadores tienen políticas predeterminadas distintas, por lo que, si dependes del predeterminada, tu sitio no se comportará de forma predecible en todos los navegadores.
• Los navegadores están adoptando valores predeterminados más estrictos, como strict-origin-when-cross-origin y mecanismos como el recorte de referencias para las solicitudes de origen cruzado. Aceptar explícitamente una política que mejore la privacidad antes de cambiar la configuración predeterminada del navegador, te da control y te ayuda a ejecutar pruebas, como lo creas conveniente.

¿Por qué usar strict-origin-when-cross-origin (o una opción más estricta)?

Necesitas una política que sea segura, útil y que mejore la privacidad. Qué "útil" depende de lo que quieras obtener de la URL de referencia:

• Seguridad: Si tu sitio web usa HTTPS (de lo contrario, configúralo como un prioridad), para que no se filtren las URLs de tu sitio web de las solicitudes no HTTPS. Debido a que cualquiera en la red puede verlos, las fugas a los usuarios a ataques de intermediarios. Las políticas no-referrer-when-downgrade, strict-origin-when-cross-origin y no-referrer y strict-origin resuelven este problema.
• Mejora de la privacidad: para 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 te deja con strict-origin-when-cross-origin, strict-origin y no-referrer como opciones que mejoren 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 la mejor opción.

Esto significa que, en general, strict-origin-when-cross-origin es un una decisión sensata.

Ejemplo: Establece una política 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 una opción más estricta) 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 tu sitio web y, si lo necesitas, un espacio más política 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/WebKit podrían limitar document.referrer o el encabezado Referer para 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 considerar?

Su política debe depender de su sitio web y de los casos de uso, según lo determine usted. tu equipo y tu empresa. Si algunas URLs contienen datos de identificación o sensibles, establece una política de protección.

Advertencia: Los datos que podrían no parecer sensibles, pueden serlo para tu o que no sean datos que desean o esperan que filtren en forma silenciosa de origen cruzado.

Prácticas recomendadas para solicitudes entrantes

Estas son algunas pautas sobre qué hacer si tu sitio utiliza la URL de referencia de las solicitudes entrantes.

Protege a los usuarios datos

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

Los referentes entrantes pueden cambiar {referer-can-change}

El uso de la URL de referencia a partir de solicitudes de origen cruzado entrantes tiene algunas limitaciones:

• Si no tienes control sobre la implementación del emisor de solicitudes, no puedes haz suposiciones sobre el encabezado Referer (y document.referrer) que que reciben. El emisor de solicitudes podría decidir cambiar a una política no-referrer en cualquier momento o, en general, a una política más estricta que la que que se usó antes. Esto significa que recibes menos datos de Referer que antes.
• Los navegadores utilizan cada vez más la política de referencias strict-origin-when-cross-origin de forma predeterminada. Esto significa que podrías recibir solo el origen, en lugar de una URL de referencia completa, en solicitudes entrantes de origen cruzado, si el sitio del no tiene una política establecida.
• Es posible que los navegadores cambien la forma en que administran Referer. Por ejemplo, algunos navegadores los desarrolladores pueden decidir siempre cortar las referencias a orígenes cruzados las solicitudes de subrecursos con el objetivo de proteger la privacidad del usuario.
• El encabezado Referer (y document.referrer) puede contener más datos que que necesitas. Por ejemplo, podría tener una URL completa si solo quieres saber si 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 los y las solicitudes multiorigen.
• Tu sitio ya no recibe la parte de la URL de referencia que necesita en una de origen cruzado. Esto sucede cuando el emisor de la solicitud cambia su política o cuando no tienen una política establecida y se modificó la política predeterminada del navegador (como en Chrome 85).

Para definir alternativas, primero analiza qué parte de la URL de referencia usarás.

Si solo necesitas el nombre

• 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 proporcionarte el Origin o describir si la solicitud es de origen cruzado, lo que puede 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 que analiza 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. Extraer solo la ruta de acceso de la URL y pasarla como argumento, de modo que cualquier información potencialmente sensible información en los parámetros de URL.

Si no puedes usar estas alternativas:

• Verifica si puedes cambiar tus sistemas para esperar al emisor de solicitudes (por ejemplo, site-one.example) para establecer de forma explícita la información que necesitas en algún tipo de configuración.
  • Ventaja: Contenido más explícito y preservación de la privacidad para los usuarios de site-one.example, más preparados para el futuro.
  • Desventaja: Potencialmente, más trabajo por parte de tu empresa o para los usuarios de tu sistema.
• Comprueba 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: es posible que los usuarios de site-one.example preserven menos la privacidad, posiblemente no sea compatible con 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 no-referrer. Además, un agente malicioso podría incluso falsificar la identidad del referente.

Usar tokens CSRF. como su protección principal. Para mayor protección, 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 las contraseñas datos personales o sensibles que puedan Referer

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

Pagos

Los proveedores de pagos podrían basarse en el encabezado Referer de las solicitudes entrantes para controles de seguridad.

Por ejemplo:

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

Prácticas recomendadas para las verificaciones de seguridad del flujo de pago

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

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

• No esperes que el Referer esté siempre presente. Si está presente, revísala. 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.
  • Por ejemplo, los valores de Referer permitidos para online-shop.example deben tener las siguientes características: online-shop.example, no online-shop.example/cart/checkout. Al esperar ningún valor Referer o Referer que sea solo la solicitud desde el origen del sitio, se evitan los errores que podrían surgir al hacer suposiciones sobre el Referrer-Policy del comercio.
• Si el Referer no está, o si está presente y tu origen Referer básico la verificación se realiza correctamente, puedes pasar a otra verificación más confiable .

Para verificar los pagos de forma más confiable, permite que el solicitante Generar un hash para los parámetros de la solicitud junto con una clave única Luego, los proveedores de pagos pueden calcular el mismo hash por ti. y solo acepta la solicitud si coincide con tu cálculo.

Qué sucede con el error Referer cuando el sitio de un comercio HTTP sin URL de referencia redirige a un proveedor de pagos HTTPS?

No hay ningún Referer visible en la solicitud al proveedor de pagos HTTPS porque 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 una política establecida. 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 URL de referencia protectora es una excelente forma de brindar más privacidad a los usuarios.

Para obtener más información sobre las diferentes técnicas para proteger a tus usuarios, consulta nuestra Recopilación segura

Recursos

• Acerca de "same-site" y “same-origin”
• Un nuevo encabezado de seguridad: Política de URLs de referencia (2017)
• Política de Referencias sobre MDN
• Encabezado de referencia: inquietudes sobre la privacidad y la seguridad en MDN
• Cambio en Chrome: Parpadea con el intent para implementar
• Cambio en Chrome: Parpadea con el intent para envío
• Cambio en Chrome: entrada de estado
• Cambio en Chrome: versión beta 85 blogpost
• Conversaciones de referencia sobre el corte del subproceso de GitHub: ¿En qué navegadores están los diferentes navegadores? sí
• Especificaciones de la política de referencias

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