Antes de comenzar:
- Si no conoces la diferencia entre "sitio" y "origen", consulta Explicación de "same-site" y "same-origin".
- Al encabezado
Refererle falta una R debido a un error ortográfico original en la especificación. El encabezadoReferrer-Policyyreferreren JavaScript y en el DOM están bien escritos.
Resumen
- Los navegadores están evolucionando hacia políticas de URL de referencia predeterminadas que mejoren la privacidad para proporcionar un buen resguardo cuando un sitio web no tiene una política establecida.
- Chrome planea habilitar gradualmente
strict-origin-when-cross-origincomo 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 una política de su elección.
- 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 URLs de referencia, la forma en que los navegadores manejan las URLs de referencia podría cambiar, así que mantenlas allí.
¿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 el 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.
La información que se envía exactamente en el encabezado Referer en una solicitud de tu sitio se determina
con el encabezado Referrer-Policy que configures.
Si no se establece ninguna política, se usa la configuración predeterminada del navegador. Los sitios web suelen elegir la configuración predeterminada del navegador.
En el caso de iframes y navegaciones, también se puede acceder a los datos presentes en el encabezado Referer a través de JavaScript mediante document.referrer.
Hasta hace poco, no-referrer-when-downgrade ha sido una política predeterminada generalizada en todos los navegadores. Sin embargo, muchos navegadores se encuentran en alguna etapa de migrar a valores predeterminados 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 estableces 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 afectará 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 el
origen se envía 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.
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: URL de referencia: https://site-one.example/stuff/detail?tag=red. - Con
strict-origin-when-cross-origin: URL de referencia: https://site-one.example/
¿Qué aspectos no cambiarán?
- Al igual que
no-referrer-when-downgrade,strict-origin-when-cross-origines seguro: no hay ninguna URL de referencia (encabezadoRefererydocument.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, haz que sea una prioridad), las URLs del sitio web no se filtrarán en solicitudes que no sean HTTPS, ya que cualquier persona en la red puede verlas, por lo que se expone a los usuarios a ataques de intermediarios. - Dentro del mismo origen, el valor del encabezado
Refereres 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: URL de referencia: https://site-one.example/stuff/detail?tag=red
¿Cuál es el impacto?
En función de los discusiones con otros navegadores y la propia experimentación ejecutada en Chrome 84, se espera que las fallas visibles para el usuario sean limitadas.
Es probable que el registro o las estadísticas del servidor que dependen de que la URL de referencia completa esté disponible se vean afectadas por un nivel de detalle reducido en esa información.
¿Qué debe hacer?
Chrome planea comenzar a lanzar la nueva política de referente predeterminada en el 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 la configuración predeterminada nueva 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 averigua si afectará a tu sitio.
Ya puedes probar el cambio a partir de Chrome 81. Para ello, visita chrome://flags/#reduced-referrer-granularity en Chrome y habilita la función experimental. Cuando esta marca esté habilitada, todos los sitios web sin una política usarán el nuevo valor predeterminado de strict-origin-when-cross-origin.
Ahora puedes verificar cómo se comportan tu sitio web y 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 no funcionen o que se comporten de manera diferente si usas la URL de referencia de solicitudes de otro origen para tu sitio (más específicamente, la ruta de acceso o la cadena de consulta) Y si este origen usa la política de URL de referencia predeterminada del navegador (es decir, no tiene una política establecida).
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 de las solicitudes a tu sitio, tienes algunas opciones:
- Usa técnicas y encabezados alternativos, como
OriginySec-fetch-Site, para la protección de CSRF, el registro y otros casos prácticos. Consulta el artículo Prácticas recomendadas sobre políticas de referencias y referentes. - Puedes acordar una política específica con los socios si es necesario y transparente para los 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 este caso, aunque con el cambio de Chrome, el origen aún se compartirá en el encabezado
Referer(y endocument.referrer).
Ten en cuenta que, en lo que respecta a la URL de referencia, la mayoría de los navegadores avanzan en una dirección similar (consulta los valores predeterminados del navegador y sus evoluciones en Prácticas recomendadas sobre política de referencias y referencias).
Implementa una política explícita que mejore la privacidad en todo tu sitio
¿Qué Referer se debe enviar en las solicitudes generadas por tu sitio web; es decir, ¿qué política debes establecer para tu sitio?
Incluso con el cambio de Chrome en mente, es una buena idea establecer una política explícita que mejore la privacidad, como strict-origin-when-cross-origin o más estricta, ahora mismo.
Esto protege a tus usuarios y hace que tu sitio web se comporte de manera más predecible en todos los navegadores. En general, te brinda control, en lugar de que tu sitio dependa de los valores predeterminados del navegador.
Consulta Referencia y política de referencia: prácticas recomendadas para obtener detalles sobre cómo configurar una política.
Acerca de Chrome Enterprise
La política empresarial de Chrome ForceLegacyDefaultReferrerPolicy está disponible para los administradores de TI que quieran forzar la política de URL de referencia predeterminada anterior de no-referrer-when-downgrade en entornos empresariales. Esto les da a las empresas más tiempo
para probar y actualizar sus aplicaciones.
Se quitará esta política en Chrome 88.
Enviar comentarios
¿Tienes comentarios que compartir o algo que denunciar? Comparte comentarios sobre la intención de envío de Chrome o tuitea 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.