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

Maud Nalpas
Maud Nalpas
Twitter GitHub

Antes de comenzar:

  • Si no estás seguro de la diferencia entre "sitio" y "origen", consulta el artículo Información sobre "same-site" y "same-origin".
  • Al encabezado Referer le falta una R, debido a un error ortográfico original en la especificación. El encabezado 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 ofrecer un buen resguardo cuando un sitio web no tiene establecida ninguna política.
  • Chrome planea habilitar gradualmente strict-origin-when-cross-origin como política predeterminada en 85. Esto puede afectar los casos de uso que dependen del valor 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 función experimental en chrome://flags/#reduced-referrer-granularity. También puedes consultar esta demostración para ver el cambio en acción.
  • Además de la política de URL de referencia, la forma en que los navegadores tratan con estas URL puede cambiar, así que pregúntala.

¿Qué cambiará y por qué?

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

El encabezado Referrer-Policy que establezcas determina qué información se envía en el encabezado Referer en una solicitud del sitio.

Diagrama: Se envía la referencia en una solicitud.
Política de Referencias y Referencia.

Si no se establece una política, se usa la configuración predeterminada del navegador. Los sitios web suelen usar la configuración predeterminada del navegador.

Para 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 cambio a parámetros predeterminados más que mejoren 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 la política que prefieras; este cambio solo se aplicará a 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 encabezado Referer de las solicitudes de origen cruzado.

Esto evita 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: El referente que se envía, según la política, para una solicitud de origen cruzado.
Se envió el referente (y document.referrer) para una solicitud de origen cruzado, según la política.

Por ejemplo:

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

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

¿Qué sigue 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 (de lo contrario, establece que sea una prioridad), las URLs del sitio web no filtrarán solicitudes que no sean HTTPS, ya que cualquier persona en la red puede verlas, por lo que los usuarios podrían recibir ataques de intermediarios.
  • Dentro del mismo origen, el valor del encabezado Referer es la URL completa.

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

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

¿Cuál es el impacto?

Según los debates con otros navegadores y la ejecución de la propia experimentación de Chrome en Chrome 84, se espera que la falla visible para el usuario sea limitada.

Es probable que el nivel de detalle reducido de esa información afecte el registro o las estadísticas del servidor que dependen de que la URL de referencia completa esté disponible.

¿Qué debe hacer?

Chrome planea comenzar a lanzar la nueva política de referentes predeterminada en 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 cuáles son los nuevos cambios predeterminados en la práctica, consulta 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á a tu sitio

Ya puede probar el cambio a partir de Chrome 81: visite chrome://flags/#reduced-referrer-granularity en Chrome y habilite la función experimental. 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.
Habilitación de la marca.

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

Otra cosa que debes 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 no funcionen o se comporten de manera diferente si usas la URL de referencia de solicitudes de otro origen a tu sitio (específicamente, la ruta o la cadena de búsqueda) Y este origen usa la política de URL de referencia predeterminada del navegador (es decir, no tiene establecida ninguna política).

Si esto afecta a tu sitio, considera otras alternativas

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

  • Usa técnicas y encabezados alternativos, como Origin y Sec-fetch-Site para la protección, el registro y otros casos de uso de CSRF. Consulta la Política de referencias y referencias: prácticas recomendadas.
  • Puedes acordar con los socios una política específica si esta es necesaria y transparente para los usuarios. El control de acceso (cuando los sitios web usan el referente para otorgar acceso específico a sus recursos a otros orígenes) podría ser ese caso, aunque con el cambio de Chrome, el origen se seguirá compartiendo en el encabezado Referer (y en document.referrer).

Ten en cuenta que la mayoría de los navegadores avanzan en una dirección similar cuando se trata de la URL de referencia (consulta los valores predeterminados del navegador y sus evoluciones en Política de URLs de referencia y prácticas recomendadas).

Implemente una política explícita y que mejore la privacidad en su sitio

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

Incluso con el cambio de Chrome en mente, se recomienda establecer una política explícita y que mejore la privacidad, como strict-origin-when-cross-origin, o una más estricta en este momento.

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

Consulta Referrer and Referrer-Policy: best practices 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 referente 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 algún comentario que compartir o algo que denunciar? Comparte tus comentarios sobre la intención de enviar contenido de Chrome o twittea tus preguntas a @maudnals.

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.

Recursos