Skip to main content

Mejores prácticas para establecer su Política de referencia y utilizar la referencia en las solicitudes entrantes.


Updated

It appears in:
Safe and secure

Summary

  • La fuga inesperada de información de origen cruzado dificulta la privacidad de los usuarios de la web. Una política de referencia protectora puede ayudar.
  • Considere establecer una política de referencia de strict-origin-when-cross-origin. Conserva gran parte de la utilidad del remitente, al tiempo que mitiga el riesgo de filtrar orígenes cruzados de datos.
  • No utilice referencias para la protección de falsificación de solicitudes entre sitios (CSRF). Utilizar CSRF tokens
    instead, and other headers as an added layer of security.

Before we start:

  • Si no está seguro de la diferencia entre «sitio» y «origen», consulte Comprender «mismo sitio» y «mismo origen».
  • the Referer Al encabezado le falta una R, debido a un error ortográfico original en la especificación. los
    Referrer-Policy header and referrer en JavaScript y DOM están escritos correctamente.

Referer and Referer-Policy 101

HTTP requests can include the optional Referer

encabezamiento, que indica el origen o la URL de la página web desde la que se realizó la solicitud. los Referrer-Policy

encabezamiento define qué datos están disponibles en el Referer header.

In the following example, the Referer El encabezado incluye la URL completa de la página en site-one from where the request was made.

referrer-basics-9699140

the Referer The header can be present in different types of requests:

  • Solicitudes de navegación, cuando un usuario hace clic en un enlace
  • Solicitudes de subrecursos, cuando un navegador solicita imágenes, iframes, scripts y otros recursos que necesita una página.

Para navegaciones e iframes, también se puede acceder a estos datos a través de JavaScript utilizando
document.referrer.

the Referer El valor puede ser revelador. Por ejemplo, un servicio de análisis puede usar el valor para determinar que el 50% de los visitantes de site-two.example He came from social-network.example.

Pero cuando la URL completa, incluida la ruta y la cadena de consulta, se envía en el Referer a través de orígenes, this could be hinder privacy and pose security risks también. Eche un vistazo a estas URL:

referrer-urls-6903646

Las URL del 1 al 5 contienen información privada, a veces incluso de identificación o confidencial. Filtrarlos silenciosamente a través de los orígenes puede comprometer la privacidad de los usuarios web.

La URL n. ° 6 es una Capacity url. No quiere que caiga en manos de nadie más que del usuario previsto. Si esto sucediera, un actor malintencionado podría secuestrar la cuenta de este usuario.

Para restringir qué datos de referencia están disponibles para las solicitudes de su sitio, puede establecer una política de referencia.

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

Puede seleccionar una de las ocho políticas. Según la política, los datos disponibles de la Referer
header (and document.referrer) can be:

  • No data (no Referer el encabezado está presente)
  • Just the origin
  • The full URL: source, path, and query string
referrer-data-1659020

Algunas pólizas están diseñadas para comportarse de manera diferente según el context: solicitud de origen cruzado o del mismo origen, seguridad (si el destino de la solicitud es tan seguro como el origen) o ambos. Esto es útil para limitar la cantidad de información compartida entre orígenes o para orígenes menos seguros, mientras se mantiene la riqueza del referente dentro de su propio sitio.

A continuación, se muestra una descripción general que muestra cómo las políticas de referencia restringen los datos de URL disponibles en el encabezado de referencia y document.referrer:

referrer-policies-5521800

MDN provides a lista completa de políticas y ejemplos de comportamiento.

Things to keep in mind:

  • Todas las políticas que tienen en cuenta el esquema (HTTPS frente a HTTP) (strict-origin,
    no-referrer-when-downgrade and 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 origen HTTPS, incluso si HTTP es menos seguro. Eso es porque para estas políticas, lo que importa es si una seguridad degrade tiene lugar, es decir, si la solicitud puede exponer datos de un origen cifrado a uno no cifrado. Una solicitud HTTP → HTTP no está encriptada todo el tiempo, por lo que no hay degradación. HTTPS → Las solicitudes HTTP, por el contrario, presentan una degradación.
  • If a request is same origin, esto significa que el esquema (HTTPS o HTTP) es el mismo; por lo tanto, no hay degradación de seguridad.

Políticas de referencia predeterminadas en los navegadores

As of July 2020

Si no se establece una política de referencia, se utilizará la política predeterminada del navegador.

Browser Default Referrer-Policy / Behaviour
Chrome

Planning to switch to strict-origin-when-cross-origin in versión 85 (previously no-referrer-when-downgrade)

Firefox
  • no-referrer-when-downgrade
  • Considering strict-origin-when-cross-origin
  • strict-origin-when-cross-origin en navegación privada y para rastreadores
Edge
  • no-referrer-when-downgrade
  • Experimenting with strict-origin-when-cross-origin
Safari

Similar to strict-origin-when-cross-origin. Watch
Prevención del seguimiento Prevención del seguimiento for details.

Configuración de su política de referencias: mejores prácticas

Aim: Establecer explícitamente una política de mejora de la privacidad, como
strict-origin-when-cross-origin(o más estricto).

Hay diferentes formas de establecer políticas de referencia para su sitio:

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

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

  1. Política a nivel de elemento
  2. Política de nivel de página
  3. Default browser

Example:

index.html:

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

La imagen se solicitará con un no-referrer-when-downgrade política, mientras que todas las demás solicitudes de recursos secundarios de esta página seguirán la strict-origin-when-cross-origin política.

¿Cómo ver la política de referencias?

When inspecting an HTTP request:

  • In Chrome, Edge, and Firefox, you can see the Referrer-Policy.
  • In Chrome, Edge, Safari, and Firefox, you can see the Referer.

referrer-devtools-4780185

Chrome DevTools, Net panel with a selected request.

¿Qué política debería establecer para su sitio web?

Resumen: establezca explícitamente una política de mejora de la privacidad como strict-origin-when-cross-origin (o más estricto).

¿Por qué «explícitamente»?

Si no se establece una política de referencia, se utilizará la política predeterminada del navegador; de hecho, los sitios web suelen ceder a la predeterminada del navegador. Pero esto no es ideal, porque:

  • Las políticas predeterminadas del navegador son no-referrer-when-downgrade,
    strict-origin-when-cross-origino más estricto, según el navegador y el modo (privado / incógnito). Por lo tanto, su sitio web no se comportará de manera predecible en todos los navegadores.
  • Los navegadores están adoptando valores predeterminados más estrictos, como strict-origin-when-cross-origin and mechanisms like reference clipping para solicitudes de origen cruzado. Optar explícitamente por una política de mejora de la privacidad antes de que cambien los valores predeterminados del navegador le da control y le ayuda a ejecutar las pruebas como mejor le parezca.

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

Necesita una política que sea segura, que mejore la privacidad y que sea útil; lo que significa «útil» depende de lo que desee del remitente:

  • Sure: si su sitio web utiliza HTTPS (si no es así, conviértalo en una prioridad), no desea que las URL de su sitio web se filtren en solicitudes que no sean HTTPS. Dado que cualquier persona en la red puede verlos, esto expondría a sus usuarios a ataques de persona en el medio. Los policias no-referrer-when-downgrade,
    strict-origin-when-cross-origin, no-referrer and strict-origin Solve this problem.
  • Privacy enhancement: for a cross-origin request, no-referrer-when-downgrade share the full url; this does not improve privacy. strict-origin-when-cross-origin and strict-origin only share the origin, and no-referrer does not share anything at all. This leaves you with
    strict-origin-when-cross-origin, strict-originand no-referrer as options to improve privacy.
  • Útil: no-referrer and strict-origin never share the full url, even for requests from the same origin, so if you need this, strict-origin-when-cross-origin es una mejor opción.

All this means that strict-origin-when-cross-origin es generalmente una opción sensata.

Example: set a strict-origin-when-cross-origin política:

index.html:

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

Or on the server side, for example in Express:

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

What if strict-origin-when-cross-origin (o más estricto) no se adapta a todos sus casos de uso?

En este caso, no establezca una política insegura como unsafe-url. What you can do instead is take a
progressive approach: establezca una política de protección para su sitio web y, si es necesario, una política más permisiva para solicitudes o elementos específicos.

Example:

index.html:

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

script.js:

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

Gotchas!

Una política por elemento no es compatible con todos los navegadores navegadores (Ejemplos: referrerpolicy for to

elementos, para img elements, and to link elements). Pero los navegadores que no admiten esto tienden a adoptar un enfoque estricto de todos modos (por ejemplo, todas las solicitudes de origen cruzado se establecerán Referer to the origin).

¿Qué más deberías considerar?

Su política debe depender de su sitio web y de los casos de uso; esto depende de usted, su equipo y su empresa. Si algunas URL contienen datos de identificación o confidenciales, establezca una política de protección.

Warning: Data that may not seem sensitive to you may be sensitive to your users, or it is simply not data that you want or hope to silently filter for cross-origin.

Usar la referencia de solicitudes entrantes: mejores prácticas

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

El uso de la referencia de las solicitudes entrantes para la protección CSRF tiene algunas dificultades:

  • It can be hidden with the no-referrer política, o falsificada por el emisor de la solicitud. Si no tiene control sobre la implementación del emisor de solicitudes, no puede hacer suposiciones sobre ningún encabezado que reciba.
  • the Referer header (and document.referrer) can contain más datos de los que necesitasFor example, a full URL when you just want to know if the request is cross-sourced.

Use CSRF tokens
como su protección principal en su lugar. Para mayor protección, use SameSite, y en lugar de Referer, you can use headings like
Origin (available in POST and CORS requests) and
Sec-Fetch-Site (si está disponible).

Inicio sesión

the Referer header (and document.referrer) puede contener datos privados, personales o de identificación, por lo que debe tratarse como tal.

And instead of Referer, consider using other headers that may address your use case:
Origin and
Sec-Fetch-Site.

Payments

Payment providers can trust Referer header of incoming requests for security checks.

For example:

  • The user clicks on a Buy botón encendido online-shop.example / cart / checkout.
  • online-shop.example redirect to payment-provider.example para gestionar la transacción.
  • payment-provider.example check the Referer of this application against an allowed list
    Referer values set by merchants. If it does not match any entry in the list,
    payment-provider.example rechaza la solicitud. Si coincide, el usuario puede continuar con la transacción.

Mejores prácticas para controles de seguridad del flujo de pagos

Summary: As a payment provider, you can use the Referer como un control básico contra ataques ingenuos, pero definitivamente debe tener otro método de verificación más confiable en su lugar.

the Referer El encabezado por sí solo no es una base confiable para una verificación: el sitio solicitante, ya sea un comerciante legítimo o no, puede establecer fácilmente un no-referrer política que hará que el Referer
información no disponible para el proveedor de pago. Sin embargo, como proveedor de pagos, mirando el
Referer can help you catch naive attackers who did not establish a no-referrer política. Entonces puede decidir usar el Referer como primer control básico. Si tu haces eso:

  • Don't wait for the Referer estar siempre presente; y si está presente, solo verifique con la pieza de datos que incluirá como mínimo: el origen. When configuring the allowed list
    Referer valores, asegúrese de que no se incluya ninguna ruta, sino solo el origen. Ejemplo: el permitido
    Referer values for online-shop.example It should be online-shop.exampledo not
    online-shop.example / cart / checkout. ¿Por qué? Porque al esperar o no Referer at all or a
    Referer valor que es el origen del sitio web solicitante, evita errores inesperados ya que está make no assumptions about the Referrer-Policy su comerciante ha establecido o sobre el comportamiento del navegador si el comerciante no tiene una política establecida. Tanto el sitio como el navegador podrían quitar la Referer sent in the incoming request only to the origin or not send the Referer absolutely.
  • If he Referer está ausente o si está presente y su Referer la verificación de origen fue exitosa: puede pasar a su otro método de verificación más confiable (ver más abajo).

¿Cuál es un método de verificación más confiable?

Un método de verificación confiable es permitir que el solicitante hash los parámetros de la solicitud junto con una clave única. Como proveedor de pagos, puede calculate the same hash on your side y solo acepte la solicitud si coincide con su cálculo.

¿Qué pasa con el Referer ¿Cuándo un sitio de comerciante HTTP sin política de referencia redirecciona a un proveedor de pago HTTPS?

No Referer será visible en la solicitud para el proveedor de pago HTTPS, porque la mayoría de los navegadores utilizan strict-origin-when-cross-origin or
no-referrer-when-downgrade de forma predeterminada cuando un sitio web no tiene una política establecida. También tenga en cuenta que Cambio de Chrome a una nueva política predeterminada no cambiará este comportamiento.

conclusion

Una política de referencia protectora es una excelente manera de brindar a sus usuarios más privacidad.

Para obtener más información sobre las diferentes técnicas para proteger a sus usuarios, consulte la colección segura y protegida de web.dev.

Many thanks for contributions and comments to all reviewers, especially Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck, and Kayce Basques.

Means