Nueva política de referencia predeterminada para Chrome: strict-origin-when-cross-origin

Maud Nalpas

Antes de comenzar:

Si no estás seguro de la diferencia entre "sitio" y "origen", consulta Cómo entender "same-site" y "same-origin".
Al encabezado Referer le falta una R debido a un error ortográfico original en la especificación. Los encabezados Referrer-Policy y referrer en JavaScript y el DOM están escritos correctamente.

Resumen

Los navegadores están evolucionando hacia políticas de URL de referencia predeterminadas que mejoran la privacidad para proporcionar una buena alternativa cuando un sitio web no tiene una política establecida.
Chrome planea habilitar gradualmente strict-origin-when-cross-origin como la política predeterminada en la versión 85. Esto puede afectar los casos de uso que dependen del valor de la URL de referencia de otro origen.
Esta es la nueva configuración predeterminada, pero los sitios web aún pueden elegir la política que deseen.
Para probar el cambio en Chrome, habilita la marca en chrome://flags/#reduced-referrer-granularity. También puedes consultar esta demostración para ver el cambio en acción.
Más allá de la política de URL de referencia, la forma en que los navegadores manejan las URLs de referencia podría cambiar, así que estate atento.

¿Qué cambia y por qué?

Las solicitudes HTTP pueden incluir el encabezado Referer opcional, que indica la URL de origen o de la página web desde la que se realizó la solicitud. El Referer-Policy encabezado define qué datos están disponibles en el Referer encabezado, y para la navegación y los iframes en el document.referrer del destino.

El encabezado Referrer-Policy que establezcas determinará exactamente qué información se envía en el encabezado Referer en una solicitud de tu sitio.

Diagrama: Se envía la URL de referencia en una solicitud. — *Referrer-Policy y Referer.*

Cuando no se establece ninguna política, se usa la predeterminada del navegador. Los sitios web suelen diferir a la configuración predeterminada del navegador.

En el caso de las navegaciones y los iframes, también se puede acceder a los datos presentes en el encabezado Referer a través de JavaScript con document.referrer.

Hasta hace poco, no-referrer-when-downgrade era una política predeterminada generalizada en todos los navegadores. Sin embargo, ahora muchos navegadores se encuentran en alguna etapa de transición a valores predeterminados que mejoran la privacidad.

Chrome planea cambiar su política predeterminada de no-referrer-when-downgrade a strict-origin-when-cross-origin, a partir de la versión 85.

Esto significa que, si no se establece ninguna política para tu sitio web, Chrome usará strict-origin-when-cross-origin de forma predeterminada. Ten en cuenta que aún puedes establecer una política de tu elección. Este cambio solo tendrá un efecto en los sitios web que no tengan una política establecida.

¿Qué significa este cambio?

strict-origin-when-cross-origin ofrece más privacidad. Con esta política, solo se envía el origen en el Referer encabezado de las solicitudes de origen cruzado.

Esto evita las filtraciones de datos privados a los que se puede acceder desde otras partes de la URL completa, como la ruta de acceso y la cadena de consulta.

Diagrama: Se envía el encabezado Referer según la política para una solicitud de origen cruzado. — *Referer enviado (y document.referrer) para una solicitud de origen cruzado, según la política.*

Por ejemplo:

Solicitud de origen cruzado, enviada desde https://site-one.example/stuff/detail?tag=red a https://site-two.example/…:

Con no-referrer-when-downgrade: Referer: https://site-one.example/stuff/detail?tag=red.
Con strict-origin-when-cross-origin: Referer: https://site-one.example/.

¿Qué permanece igual?

Al igual que no-referrer-when-downgrade, strict-origin-when-cross-origin es seguro: no hay URL de referencia (encabezado Referer y document.referrer) cuando la solicitud se realiza desde un origen HTTPS (seguro) a uno HTTP (no seguro). De esta manera, si tu sitio web usa HTTPS (si no lo hace, conviértelo en una prioridad), las URLs de tu sitio web no se filtrarán en solicitudes que no sean HTTPS , ya que cualquier persona de la red puede verlas, lo que expondría a tus usuarios a ataques de intermediario.
Dentro del mismo origen, el valor del encabezado Referer es la URL completa.

Por ejemplo: Solicitud del mismo origen, enviada desde https://site-one.example/stuff/detail?tag=red a https://site-one.example/…:

Con strict-origin-when-cross-origin: Referer: https://site-one.example/stuff/detail?tag=red

¿Cuál es el impacto?

Según las conversaciones con otros navegadores y la propia experimentación de Chrome ejecutada en Chrome 84, se espera que las interrupciones visibles para el usuario sean limitadas.

Es probable que el registro o el análisis del servidor que dependen de que esté disponible la URL de referencia completa se vean afectados por la reducción de la granularidad en esa información.

¿Qué debes hacer?

Chrome planea comenzar a lanzar la nueva política de URL de referencia predeterminada en la versión 85 (julio de 2020 para la versión beta y agosto de 2020 para la versión estable). Consulta el estado en la entrada de estado de Chrome.

Comprende y detecta el cambio

Para comprender qué cambia en la práctica el nuevo valor predeterminado, puedes consultar esta demostración.

También puedes usar esta demostración para detectar qué política se aplica en la instancia de Chrome que estás ejecutando.

Prueba el cambio y determina si afectará tu sitio

Ya puedes probar el cambio a partir de Chrome 81: visita chrome://flags/#reduced-referrer-granularity en Chrome y habilita la marca. Cuando esta marca esté habilitada, todos los sitios web sin una política usarán el nuevo valor predeterminado strict-origin-when-cross-origin.

Captura de pantalla de Chrome: Cómo habilitar la función experimental chrome://flags/#reduced-referrer-granularity. — *Cómo habilitar la marca*

Ahora puedes verificar cómo se comportan tu sitio web y tu backend.

Otra cosa que puedes hacer para detectar el impacto es verificar si la base de código de tu sitio web usa la URL de referencia, ya sea a través del encabezado Referer de las solicitudes entrantes en el servidor o desde document.referrer en JavaScript.

Es posible que algunas funciones de tu sitio se interrumpan o se comporten de manera diferente si usas la URL de referencia de solicitudes de otro origen a tu sitio (más específicamente, la ruta de acceso o la cadena de consulta) Y este origen usa la política de URL de referencia predeterminada del navegador (es decir, no tiene una política establecida).

Si esto afecta tu sitio, considera alternativas

Si usas la URL de referencia para acceder a la ruta de acceso completa o a la cadena de consulta de las solicitudes a tu sitio, tienes algunas opciones:

Usa técnicas y encabezados alternativos, como Origin y Sec-fetch-Site, para la protección CSRF, el registro y otros casos de uso. Consulta Referer y Referrer-Policy: prácticas recomendadas.
Puedes alinearte con los socios en una política específica si es necesario y transparente para tus usuarios. El control de acceso, cuando los sitios web usan la URL de referencia para otorgar acceso específico a sus recursos a otros orígenes, podría ser un caso de este tipo, aunque, con el cambio de Chrome, el origen aún se compartirá en el encabezado Referer (y en document.referrer).

Ten en cuenta que la mayoría de los navegadores se mueven en una dirección similar cuando se trata de la URL de referencia (consulta los valores predeterminados del navegador y sus evoluciones en Referer y Referrer-Policy: prácticas recomendadas).

Implementa una política explícita que mejore la privacidad en todo tu sitio

¿Qué Referer se debe enviar en las solicitudes originadas por tu sitio web? Es decir, ¿qué política debes establecer para tu sitio?

Incluso teniendo en cuenta el cambio de Chrome, es una buena idea establecer una política explícita que mejore la privacidad, como strict-origin-when-cross-origin o una más estricta en este momento.

Esto protege a tus usuarios y hace que tu sitio web se comporte de manera más predecible en todos los navegadores. En su mayoría, te da control, en lugar de que tu sitio dependa de los valores predeterminados del navegador.

Consulta Referer y Referrer-Policy: prácticas recomendadas para obtener detalles sobre cómo establecer una política.

Acerca de Chrome Enterprise

La política empresarial de Chrome ForceLegacyDefaultReferrerPolicy está disponible para los administradores de TI que deseen forzar la política de URL de referencia predeterminada anterior de no-referrer-when-downgrade en entornos empresariales. Esto permite que las empresas tengan más tiempo para probar y actualizar sus aplicaciones.

Se quitará esta política en Chrome 88.

Enviar comentarios

¿Tienes comentarios para compartir o algo que informar? Comparte comentarios sobre la intención de Chrome de realizar el envío o envía tus preguntas por Twitter a @maudnals.

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.