Antes de comenzar:
- Si no sabes con certeza la diferencia entre "sitio" y "origen", consulta Cómo comprender "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 se escriben 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 establecida una política.
- Chrome planea habilitar
strict-origin-when-cross-originde forma gradual como política predeterminada en la versión 85, lo que 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 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 mantente al tanto.
¿Qué cambiará 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 encabezado Referer-Policy define qué datos están disponibles en el encabezado Referer, y para la navegación y los elementos iframe en el document.referrer del destino.
La información exacta que se envía en el encabezado Referer en una solicitud de tu sitio se determina según el encabezado Referrer-Policy que establezcas.
Cuando no se establece ninguna política, se usa la configuración predeterminada del navegador. Los sitios web suelen usar 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 hacia configuraciones predeterminadas 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 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.
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 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é se mantiene igual?
- Al igual que
no-referrer-when-downgrade,strict-origin-when-cross-origines seguro: No hay un referente (encabezadoRefererydocument.referrer) 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í, conviértelo en 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://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 en Chrome 84, se espera que las interrupciones visibles para el usuario sean limitadas.
Es probable que el registro o las estadísticas del servidor que dependen de la disponibilidad de la URL de referencia completa se vean afectados por la menor granularidad de 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 cómo funcionan los nuevos cambios predeterminados en la práctica, 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 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 el comportamiento de tu sitio web y backend.
Otra acción que puedes realizar para detectar el impacto es verificar si la base de código de tu sitio web usa el 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 utilizas el sitio de referencia de las solicitudes de otro origen a tu sitio (más específicamente, la ruta o la cadena de consulta) Y este origen utiliza la política de sitios de referencia predeterminada del navegador (es decir, no tiene establecida ninguna política).
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 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 and Referrer-Policy: best practices. - 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 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 URL de referencia (consulta los valores predeterminados del navegador y sus evoluciones en Referer and Referrer-Policy: best practices).
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 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, 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 su mayoría, te brinda control, en lugar de que tu 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 URL 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 para compartir o algo que informar? Comparte comentarios sobre la intención de Chrome de lanzar la función o tuitea tus preguntas a @maudnals.
Agradecemos mucho las contribuciones y los comentarios de todos los revisores, en especial de Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck y Kayce Basques.