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 encabezadoReferrer-Policy
yreferrer
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.
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.
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 (encabezadoReferer
ydocument.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
.
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
ySec-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 endocument.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.