Antes de comenzar:
- Si no sabes cuál es la diferencia entre "sitio" y "origen", consulta Información sobre "mismo sitio" y "mismo origen".
- Al encabezado
Refererle falta una R debido a un error ortográfico original en la especificación. El encabezadoReferrer-Policyyreferreren JavaScript y el DOM están escritos correctamente.
Resumen
- Los navegadores evolucionan hacia políticas de referencia predeterminadas que mejoran 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 la política predeterminada en la versión 85. Esto puede afectar los casos de uso que dependen del valor del referente de otro origen. - Esta es la nueva configuración predeterminada, pero los sitios web 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 demo para ver el cambio en acción. - Además de la política de referencia, es posible que cambie la forma en que los navegadores manejan los referer, así que no pierdas de vista este tema.
¿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 configuras determina exactamente qué información se envía en el encabezado Referer de una solicitud de tu sitio.
Cuando no se establece ninguna política, se usa la predeterminada del navegador. Los sitios web suelen aplazar 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 están en algún proceso de cambio a parámetros de configuración 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 puedes establecer la política que desees.
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 se envía el origen en el encabezado Referer de las solicitudes de origen cruzado.
De esta manera, se evita la filtración 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 desde https://sitio-uno.ejemplo/elementos/detalles?etiqueta=rojo a https://sitio-dos.ejemplo/…:
- Con
no-referrer-when-downgrade: Referer: https://sitio-uno.example/cosas/detalle?etiqueta=rojo. - Con
strict-origin-when-cross-origin: Referer: https://sitio-uno.example/.
¿Qué permanece igual?
- Al igual que
no-referrer-when-downgrade,strict-origin-when-cross-origines segura: no hay ningún referente (encabezadoRefererydocument.referrer) presente cuando la solicitud se realiza desde un origen HTTPS (seguro) a uno HTTP (inseguro). De esta manera, si tu sitio web usa HTTPS (si no es así, hazlo una prioridad), las URLs de tu sitio web no se filtrarán en las solicitudes que no sean HTTPS, ya que cualquier persona en la red puede verlas, lo que expondría a tus usuarios a ataques de intermediario. - Dentro del mismo origen, el valor del encabezado
Refereres 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://sitio-uno.ejemplo/cosas/detalle?etiqueta=rojo
¿Cuál es el impacto?
En función de las conversaciones con otros navegadores y de la propia experimentación de Chrome en Chrome 84, se espera que las fallas visibles para el usuario sean limitadas.
Es probable que los registros o las estadísticas del servidor que dependen de que la URL de referencia completa esté disponible se vean afectados por la reducción de la granularidad de esa información.
¿Qué debes hacer?
Chrome planea comenzar a lanzar la nueva política de referente 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é cambios predeterminados nuevos se aplican en la práctica, puedes consultar esta demo.
También puedes usar esta demostración para detectar qué política se aplica en la instancia de Chrome que ejecutas.
Prueba el cambio y averigua si afectará a 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 se habilite esta marca, 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 tu backend.
Otra medida que puedes tomar para detectar el impacto es verificar si la base de código de tu sitio web usa el referente, 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 rompan o se comporten de forma diferente si usas el referente de las 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 referencia predeterminada del navegador (es decir, no tiene una política establecida).
Si esto afecta a tu sitio, considera las siguientes alternativas
Si usas el referente para acceder a la ruta de acceso completa o a la cadena de consulta de las solicitudes a tu sitio, tienes las siguientes opciones:
- Usa técnicas y encabezados alternativos, como
OriginySec-fetch-Site, para la protección contra 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 es 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 un caso de este tipo, aunque con el cambio de Chrome, el origen se seguirá compartiendo en el encabezado
Referer(y endocument.referrer).
Ten en cuenta que la mayoría de los navegadores se están moviendo en una dirección similar en lo que respecta al referente (consulta las opciones predeterminadas del navegador y su evolución 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 configurar 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 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 brinda control, en lugar de que tu sitio dependa de los parámetros de configuración predeterminados del navegador.
Consulta Referrer y Referrer-Policy: 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 deseen forzar la política de referencia predeterminada anterior de no-referrer-when-downgrade en entornos empresariales. Esto les permite a las empresas tener tiempo adicional para probar y actualizar sus aplicaciones.
Se quitará esta política en Chrome 88.
Enviar comentarios
¿Tienes comentarios o algo que informar? Comparte tus comentarios sobre el próximo lanzamiento de Chrome o twittea tus preguntas a @maudnals.
Muchas gracias por las contribuciones y los comentarios a todos los revisores, en especial a Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck y Kayce Basques.