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 URL de referencia y usar la URL de referencia en las solicitudes entrantes.

Resumen

• La filtración inesperada de información de origen cruzado daña la privacidad de los usuarios web. Una política de URL de referencia protectora puede ayudar.
• Considera establecer una política de URL de referencia de strict-origin-when-cross-origin. Preserva la mayor parte de la utilidad de la URL de referencia y, al mismo tiempo, mitiga el riesgo de filtrar datos de origen cruzado.
• No uses URLs de referencia para la protección contra la falsificación de solicitudes entre sitios (CSRF). En su lugar, usa tokens de CSRF y otros encabezados como un nivel de seguridad adicional.

Introducción a Referer y Referrer-Policy

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 Referrer-Policy encabezado define qué datos están disponibles en el Referer encabezado.

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.

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 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 estadísticas podría usarlos para determinar que el 50% de los visitantes de site-two.example provienen de social-network.example. Sin embargo, cuando se envía la URL completa, incluida la ruta y la cadena de consulta, en el Referer entre orígenes, puede poner en peligro la privacidad del usuario y crear riesgos de seguridad:

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

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

Para restringir qué datos de la URL de referencia está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 las ocho políticas. Según la política, los datos disponibles del encabezado Referer (y document.referrer) pueden ser los siguientes:

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

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 compartida entre orígenes o a orígenes menos seguros, mientras se mantiene la riqueza de la URL de referencia dentro de 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 Referer y document.referrer:

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

Estos son algunos aspectos que debes tener en cuenta cuando establezcas 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 otro origen HTTP de la misma manera que las solicitudes de un origen HTTPS a otro origen HTTPS, aunque HTTP es menos seguro. Esto se debe a que, para estas políticas, lo que importa es si se produce una disminución de seguridad, es decir, si la solicitud puede exponer datos de un origen encriptado a uno sin encriptar, como en las solicitudes de HTTPS → HTTP. Una solicitud de HTTP → HTTP no está encriptada por completo, por lo que no hay disminución.
• Si una solicitud es del mismo origen, significa que el esquema (HTTPS o HTTP) es el mismo, por lo que no hay disminución de seguridad.

Políticas de URL de referencia predeterminadas en navegadores

A partir de octubre de 2021

Si no se establece ninguna política de URL de referencia, el navegador usa su política predeterminada.

Prácticas recomendadas para establecer la política de URL de referencia

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

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

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

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

1. Política a nivel del elemento
2. Política a nivel de la página
3. Valor 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 solicitudes de subrecursos de esta página siguen la política strict-origin-when-cross-origin.

¿Cómo ver la política de URL de referencia?

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

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

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

Te recomendamos que establezcas explícitamente 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 suelen diferir del valor predeterminado del navegador. Sin embargo, esto no es ideal por los siguientes motivos:

• Los diferentes navegadores tienen diferentes políticas predeterminadas, por lo que, si dependes de los valores predeterminados del navegador, tu sitio 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 y mecanismos como el recorte de la URL de referencia para las solicitudes de origen cruzado. Si habilitas explícitamente una política que mejore la privacidad antes de que cambien los valores predeterminados del navegador, tendrás control y podrás ejecutar pruebas según lo consideres adecuado.

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

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

• Seguro: Si tu sitio web usa HTTPS (si no es así, conviértelo en una prioridad), no querrás que las URLs de tu sitio web se filtren en solicitudes que no sean HTTPS. Como cualquier persona de la red puede verlas, las filtraciones expondrían a tus usuarios a ataques de intermediario. Las políticas no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer, y strict-origin resuelven este problema.
• Mejora 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 mejoran la privacidad.
• Útil: no-referrer y strict-origin nunca comparten la URL completa, incluso para las 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 sensata.

Ejemplo: Cómo establecer una política strict-origin-when-cross-origin

index.html:

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

O bien, en el 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 más estricta) no se adapta a todos tus casos de uso?

En este caso, adopta un enfoque progresivo: establece una política protectora como strict-origin-when-cross-origin para tu sitio web y, si es necesario, una más permisiva para solicitudes o elementos HTML específicos.

Ejemplo: Política a nivel del 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 puede 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 debes tener en cuenta?

Tu política debe depender de tu sitio web y de los casos de uso, según lo determinen tú, tu equipo y tu empresa. Si algunas URLs contienen datos sensibles o de identificación, establece una política protectora.

Prácticas recomendadas para las solicitudes entrantes

Estas son algunas instrucciones sobre qué hacer si tu sitio usa 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, por lo que debes tratarlo como tal.

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 algunas limitaciones:

• Si no tienes control sobre la implementación del emisor de la solicitud, no puedes hacer suposiciones sobre el encabezado Referer (y document.referrer) que recibes. El emisor de la solicitud puede decidir cambiar a una política no-referrer en cualquier momento o, en general, a una política más estricta que la que usaba antes. Esto significa que recibes menos datos del Referer que antes.
• Los navegadores usan cada vez más la política de URL de referencia strict-origin-when-cross-origin de forma predeterminada. Esto significa que ahora solo puedes recibir el origen, en lugar de una URL de referencia completa, en las solicitudes entrantes de origen cruzado, si el sitio remitente no tiene establecida ninguna política.
• Los navegadores pueden cambiar la forma en que administran Referer. Por ejemplo, algunos desarrolladores de navegadores podrían decidir recortar siempre las URLs de referencia a orígenes en 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 que necesitas. Por ejemplo, puede tener una URL completa cuando solo quieres 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 cambió la política predeterminada del navegador (como en Chrome 85).

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

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, lo que podría ser exactamente lo que necesitas.

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

• 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 ruta de la URL y pásala como argumento para que no se pase ninguna información potencialmente sensible en los parámetros de la URL.

Si no puedes usar estas alternativas:

• Verifica si puedes cambiar tus sistemas para esperar que el emisor de la solicitud (por ejemplo, site-one.example) establezca explícitamente la información que necesitas en algún tipo de configuración.
  • Ventaja: Más explícito, más preservación de la privacidad para los usuarios de site-one.example y más preparado para el futuro.
  • Desventaja: Potencialmente más trabajo de tu parte o para los usuarios de tu sistema.
• Verifica si el sitio que emite las solicitudes podría aceptar establecer una política de URL de referencia por elemento o por solicitud de no-referrer-when-downgrade.
  • Desventaja: Potencialmente menos preservación de la privacidad para los usuarios de site-one.example y potencialmente no 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 estableciendo una política no-referrer, y una persona malintencionada podría incluso suplantar la URL de referencia.

Usa tokens de 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.

Registra y depura

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

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

Pagos

Es posible que los proveedores de pagos dependan del encabezado Referer de las solicitudes entrantes para las 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 en una lista de valores Referer permitidos que establecieron los comerciantes. 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 las verificaciones de seguridad del flujo de pagos

Como proveedor de pagos, puedes usar el Referer como una 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 solicitante, ya sea un comerciante 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.

Observar el Referer puede ayudar a los proveedores de pagos a detectar atacantes ingenuos que no establecieron una política no-referrer. Si usas el Referer como primera verificación, ten en cuenta lo siguiente:

• No esperes que el Referer siempre esté presente. Si está presente, compruébalo solo con los datos mínimos que puede incluir, que es el origen.
  • Cuando establezcas la lista de valores Referer permitidos, asegúrate de incluir solo el origen y ninguna ruta.
  • 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 ningún Referer o un valor Referer que sea solo el origen del sitio solicitante, evitarás errores que puedan surgir de hacer suposiciones sobre el Referrer-Policy del comerciante.
• Si el Referer está ausente o si está presente y la verificación básica del origen Referer es exitosa, 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 haga un hash de los parámetros de la solicitud junto con una clave única. Luego, 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 comerciante HTTP sin política de URL de referencia redirecciona a un proveedor de pagos HTTPS?

No Referer es visible 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 modificará este comportamiento.

Conclusión

Una política de URL de referencia protectora es una excelente manera de brindarles a tus usuarios más privacidad.

Para obtener más información sobre las diferentes técnicas para proteger a tus usuarios, consulta nuestra Seguro y protegido colección

Recursos

• Comprende "mismo sitio" y "mismo origen"
• Un nuevo encabezado de seguridad: Política de URL de referencia (2017)
• Referrer-Policy en MDN
• Encabezado Referer: Inquietudes sobre la privacidad y seguridad en MDN
• Cambio de Chrome: Intención de Blink para implementar
• Cambio de Chrome: Intención de Blink para enviar
• Cambio de Chrome: Entrada de estado
• Cambio de Chrome: Publicación de blog de la versión beta 85
• Subproceso de GitHub de recorte de la URL de referencia: Qué hacen los diferentes navegadores
• Especificación de Referrer-Policy

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