Esta página describe algunas prácticas recomendadas para establecer una política de URL de referencia y usando la URL de referencia en solicitudes entrantes.
Resumen
- La filtración inesperada de información de origen cruzado daña a los usuarios web la privacidad. R puede ayudar con la política de URL de referencia protectora.
- Considera establecer una política de URL de referencia de
strict-origin-when-cross-origin
. Integra conserva la mayor parte de la utilidad de la URL de referencia, a la vez que mitiga el riesgo de filtrar orígenes cruzados de datos. - No uses URLs de referencia para la protección contra la falsificación de solicitudes entre sitios (CSRF). Usa Tokens CSRF en su lugar, y otros encabezados como una capa de seguridad adicional.
Política de referencias y referencias 101
Las solicitudes HTTP pueden incluir un encabezado Referer
opcional.
que indique el origen o la URL de la página web desde la que se realizó la solicitud. El
Encabezado Referrer-Policy
define qué datos están disponibles en el encabezado Referer
.
En el siguiente ejemplo, el encabezado Referer
incluye la URL completa del
página de site-one
desde la que se realizó la solicitud.
![Solicitud HTTP que incluye un encabezado de referencia.](https://web.developers.google.cn/static/articles/referrer-best-practices/image/http-request-including-r-9ebf692a22831.jpg?authuser=7&hl=es-419)
El encabezado Referer
puede estar presente en diferentes tipos de solicitudes:
- Solicitudes de navegación, cuando un usuario hace clic en un vínculo
- Solicitudes de subrecursos, cuando un navegador solicita imágenes, iframes, secuencias de comandos otros recursos que necesita una página.
Para las navegaciones y los iframes, también puedes acceder a estos datos con JavaScript usando
document.referrer
Puedes aprender mucho de los valores de Referer
. Por ejemplo, un servicio de análisis
podría utilizarlas para determinar que el 50% de los visitantes de site-two.example
llegó a
desde social-network.example
. Pero cuando la URL completa, incluidas la ruta de acceso y
cadena de consulta, se envía en Referer
de todos los orígenes, puede poner en peligro
la privacidad y crear riesgos de seguridad:
![URLs con rutas de acceso, asignadas a diferentes riesgos de privacidad y seguridad.](https://web.developers.google.cn/static/articles/referrer-best-practices/image/urls-paths-mapped-diff-5b35e579c46d7.jpg?authuser=7&hl=es-419)
Las URL n.° 1 a n.° 5 contienen información privada y, a veces, información de identificación personal. Filtrar estos datos silenciosamente entre los orígenes puede comprometer usuarios web la privacidad.
La URL n° 6 es una URL de capacidad. Si alguien excepto que el usuario previsto recibe esto, un agente malicioso puede tomar el control de la cuenta de este usuario.
Para restringir qué datos de referencia están disponibles para solicitudes provenientes de tu sitio, puedes establecer una política de URLs de referencia.
¿Qué políticas están disponibles y en qué se diferencian?
Puedes seleccionar una de las ocho políticas. Según la política, los datos
disponibles en el encabezado Referer
(y document.referrer
) pueden ser las siguientes:
- No hay datos (no hay un encabezado
Referer
presente) - Solo el origen
- La URL completa: origen, ruta de acceso y cadena de consulta
![Datos que pueden
debe incluirse en el encabezado de referencia y en document.referrer.](https://web.developers.google.cn/static/articles/referrer-best-practices/image/data-can-contained-the-209ad524f7ae8.jpg?authuser=7&hl=es-419)
Algunas políticas están diseñadas para comportarse de manera diferente según el contexto: solicitudes de origen cruzado o del mismo origen, ya sea que el destino de la solicitud sea seguro como origen, o ambos. Esto es útil para limitar la cantidad de información compartidos entre orígenes o con orígenes menos seguros, mientras se mantiene la riqueza de la URL de referencia en tu propio sitio.
En la siguiente tabla, se muestra cómo las políticas de URL de referencia restringen los datos de URL disponibles
del encabezado de referencia y document.referrer
:
Alcance de la política | Nombre de la política | Referente: Sin datos | URL de referencia: solo origen | URL de referencia: URL completa |
---|---|---|---|---|
No considera el contexto de la solicitud. | no-referrer |
verificación | ||
origin |
verificación | |||
unsafe-url |
verificación | |||
Enfoque en la seguridad | strict-origin |
Solicitud de HTTPS a HTTP | Solicitud de HTTPS a HTTPS o de HTTP a HTTP |
|
no-referrer-when-downgrade |
Solicitud de HTTPS a HTTP | Solicitud de HTTPS a HTTPS o de HTTP a HTTP |
||
Enfoque centrado en la privacidad | origin-when-cross-origin |
Solicitud de origen cruzado | Solicitud del mismo origen | |
same-origin |
Solicitud de origen cruzado | Solicitud del mismo origen | ||
Se enfocan en la privacidad y la seguridad. | strict-origin-when-cross-origin |
Solicitud de HTTPS a HTTP | Solicitud de origen cruzado de HTTPS a HTTPS o de HTTP a HTTP |
Solicitud del mismo origen |
La MDN brinda una lista completa de políticas y comportamientos ejemplos comunes.
Estos son algunos puntos que debes tener en cuenta cuando configures una política de URL de referencia:
- Todas las políticas que tienen en cuenta el esquema (HTTPS en comparación con HTTP)
(
strict-origin
,no-referrer-when-downgrade
ystrict-origin-when-cross-origin
) tratan las solicitudes de un origen HTTP a a otro origen HTTP de la misma manera que las solicitudes de un origen HTTPS a otro origen HTTPS, incluso si HTTP es menos seguro. Eso se debe a que, para estos de seguridad, lo que importa es si se reduce el nivel de seguridad que es si la solicitud puede exponer datos de un origen encriptado a un como en las solicitudes HTTPS → HTTP. Una solicitud HTTP → HTTP es completamente y sin encriptar, por lo que no hay que cambiar a una versión inferior. - Si una solicitud es same-origin, significa que el esquema (HTTPS o HTTP) se igual, por lo que no hay un cambio a una versión inferior de seguridad.
Políticas de URL de referencia predeterminadas en navegadores
Hasta octubre de 2021
Si no estableces una política de referente, el navegador usa su política predeterminada.
Navegador | Referrer-Policy / Comportamiento predeterminado |
---|---|
Chrome |
El valor predeterminado es strict-origin-when-cross-origin .
|
Firefox |
El valor predeterminado es strict-origin-when-cross-origin .A partir de la versión 93, para la Protección estricta contra seguimiento y los usuarios de navegación privada, menos políticas de URL de referencia restrictivas no-referrer-when-downgrade ,
origin-when-cross-origin y unsafe-url son
Se ignoran las solicitudes entre sitios, lo que significa que la URL de referencia siempre se corta.
para las solicitudes entre sitios, independientemente de la política del sitio web.
|
Edge |
El valor predeterminado es strict-origin-when-cross-origin .
|
Safari |
El valor predeterminado es similar a strict-origin-when-cross-origin ,
con algunas diferencias específicas. Consulta
Evita el seguimiento de la prevención del seguimiento para obtener más detalles.
|
Prácticas recomendadas para configurar una política de URL de referencia
Existen diferentes maneras de establecer políticas de URL de referencia para tu sitio:
- Como un encabezado HTTP
- En tu HTML
- Desde JavaScript por solicitud
Puedes establecer diferentes políticas para distintas páginas, solicitudes o elementos.
El encabezado HTTP y el elemento meta están a nivel de la página. El orden de prioridad determinar la política vigente de un elemento es la siguiente:
- Política de nivel de elemento
- Política a nivel de la página
- Predeterminado del navegador
Ejemplo:
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
La imagen se solicita con una política no-referrer-when-downgrade
, y todas las demás
las solicitudes de subrecursos de esta página deben seguir la strict-origin-when-cross-origin
.
¿Cómo puedo ver la política de referentes?
securityheaders.com es útil para determinar qué la política que utiliza una página o un sitio específicos.
También puedes usar las herramientas para desarrolladores en Chrome, Edge o Firefox para consultar
para una solicitud específica. Al momento de la redacción de este documento, Safari
no muestra el encabezado Referrer-Policy
, pero sí el Referer
que se
enviados.
![Captura de pantalla del panel Network de las Herramientas para desarrolladores de Chrome que muestra Referer y Referrer-Policy.](https://web.developers.google.cn/static/articles/referrer-best-practices/image/a-screenshot-the-network-7f0db2eae4fd4.jpg?authuser=7&hl=es-419)
¿Qué política deberías establecer para tu sitio web?
Te recomendamos que establezcas de forma explícita una política que mejore la privacidad, como
strict-origin-when-cross-origin
(o más estricta).
¿Por qué "explícitamente"?
Si no estableces una política de URL de referencia, se usará la política predeterminada del navegador. De hecho, los sitios web a menudo diferir a la configuración predeterminada del navegador. Sin embargo, esto no es ideal por los siguientes motivos:
- Los diferentes navegadores tienen políticas predeterminadas distintas, por lo que, si dependes del predeterminada, tu sitio no se comportará de forma predecible en todos los navegadores.
- Los navegadores están adoptando valores predeterminados más estrictos, como
strict-origin-when-cross-origin
y mecanismos como el recorte de referencias para las solicitudes de origen cruzado. Aceptar explícitamente una política que mejore la privacidad antes de cambiar la configuración predeterminada del navegador, te da control y te ayuda a ejecutar pruebas, como lo creas conveniente.
¿Por qué usar strict-origin-when-cross-origin
(o una opción más estricta)?
Necesitas una política que sea segura, útil y que mejore la privacidad. Qué "útil" depende de lo que quieras obtener de la URL de referencia:
- Seguridad: Si tu sitio web usa HTTPS (de lo contrario, configúralo como un
prioridad), para que no se filtren las URLs de tu sitio web
de las solicitudes no HTTPS. Debido a que cualquiera en la red puede verlos, las fugas
a los usuarios a ataques de intermediarios. Las políticas
no-referrer-when-downgrade
,strict-origin-when-cross-origin
yno-referrer
ystrict-origin
resuelven este problema. - Mejora de la privacidad: para una solicitud de origen cruzado,
no-referrer-when-downgrade
comparte la URL completa, lo que puede causar problemas de privacidad.strict-origin-when-cross-origin
ystrict-origin
solo comparten el origen, yno-referrer
no comparte nada. Esto te deja constrict-origin-when-cross-origin
,strict-origin
yno-referrer
como opciones que mejoren la privacidad. - Útil:
no-referrer
ystrict-origin
nunca comparten la URL completa, ni siquiera para solicitudes del mismo origen. Si necesitas la URL completa,strict-origin-when-cross-origin
es la mejor opción.
Esto significa que, en general, strict-origin-when-cross-origin
es un
una decisión sensata.
Ejemplo: Establece una política strict-origin-when-cross-origin
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
O del servidor, por ejemplo en Express:
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
¿Qué sucede si strict-origin-when-cross-origin
(o una opción más estricta) no se adapta a todos tus casos de uso?
En este caso, adopta un enfoque progresivo: establece una política de protección, como
strict-origin-when-cross-origin
para tu sitio web y, si lo necesitas, un espacio más
política permisiva para solicitudes o elementos HTML específicos.
Ejemplo: política a nivel de elemento
index.html
:
<head>
<!-- document-level policy: strict-origin-when-cross-origin -->
<meta name="referrer" content="strict-origin-when-cross-origin" />
<head>
<body>
<!-- policy on this <a> element: no-referrer-when-downgrade -->
<a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
<body></body>
</body>
</head>
</head>
Safari/WebKit podrían limitar document.referrer
o el encabezado Referer
para
entre sitios.
Consulta los detalles.
Ejemplo: política a nivel de la solicitud
script.js
:
fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});
¿Qué más deberías considerar?
Su política debe depender de su sitio web y de los casos de uso, según lo determine usted. tu equipo y tu empresa. Si algunas URLs contienen datos de identificación o sensibles, establece una política de protección.
Prácticas recomendadas para solicitudes entrantes
Estas son algunas pautas sobre qué hacer si tu sitio utiliza la URL de referencia de las solicitudes entrantes.
Protege a los usuarios datos
El Referer
puede contener datos privados, personales o de identificación, así que asegúrate de que
lo tratas como tal.
Los referentes entrantes pueden cambiar {referer-can-change}
El uso de la URL de referencia a partir de solicitudes de origen cruzado entrantes tiene algunas limitaciones:
- Si no tienes control sobre la implementación del emisor de solicitudes, no puedes
haz suposiciones sobre el encabezado
Referer
(ydocument.referrer
) que que reciben. El emisor de solicitudes podría decidir cambiar a una políticano-referrer
en cualquier momento o, en general, a una política más estricta que la que que se usó antes. Esto significa que recibes menos datos deReferer
que antes. - Los navegadores utilizan cada vez más la política de referencias
strict-origin-when-cross-origin
de forma predeterminada. Esto significa que podrías recibir solo el origen, en lugar de una URL de referencia completa, en solicitudes entrantes de origen cruzado, si el sitio del no tiene una política establecida. - Es posible que los navegadores cambien la forma en que administran
Referer
. Por ejemplo, algunos navegadores los desarrolladores pueden decidir siempre cortar las referencias a orígenes cruzados las solicitudes de subrecursos con el objetivo de proteger la privacidad del usuario. - El encabezado
Referer
(ydocument.referrer
) puede contener más datos que que necesitas. Por ejemplo, podría tener una URL completa si solo quieres saber si si la solicitud es de origen cruzado.
Alternativas a Referer
Es posible que debas considerar alternativas en los siguientes casos:
- Una función esencial de tu sitio usa la URL de referencia de los y las solicitudes multiorigen.
- Tu sitio ya no recibe la parte de la URL de referencia que necesita en una de origen cruzado. Esto sucede cuando el emisor de la solicitud cambia su política o cuando no tienen una política establecida y se modificó la política predeterminada del navegador (como en Chrome 85).
Para definir alternativas, primero analiza qué parte de la URL de referencia usarás.
Si solo necesitas el nombre
- Si usas la URL de referencia en una secuencia de comandos que tiene acceso de nivel superior a la página
window.location.origin
es una alternativa. - Si están disponibles, los encabezados como
Origin
ySec-Fetch-Site
proporcionarte elOrigin
o describir si la solicitud es de origen cruzado, lo que puede ser exactamente lo que necesitas.
Si necesitas otros elementos de la URL (ruta, parámetros de consulta, etc.)
- Los parámetros de solicitud pueden abordar tu caso de uso, lo que te ahorra el trabajo de que analiza la URL de referencia.
- Si usas la URL de referencia en una secuencia de comandos que tiene acceso de nivel superior a la página
window.location.pathname
podría funcionar como alternativa. Extraer solo la ruta de acceso de la URL y pasarla como argumento, de modo que cualquier información potencialmente sensible información en los parámetros de URL.
Si no puedes usar estas alternativas:
- Verifica si puedes cambiar tus sistemas para esperar al emisor de solicitudes
(por ejemplo,
site-one.example
) para establecer de forma explícita la información que necesitas en algún tipo de configuración.- Ventaja: Contenido más explícito y preservación de la privacidad para los usuarios de
site-one.example
, más preparados para el futuro. - Desventaja: Potencialmente, más trabajo por parte de tu empresa o para los usuarios de tu sistema.
- Ventaja: Contenido más explícito y preservación de la privacidad para los usuarios de
- Comprueba si el sitio que emite las solicitudes podría aceptar establecer una
Política de referencia de
no-referrer-when-downgrade
por elemento o por solicitud.- Desventaja: es posible que los usuarios de
site-one.example
preserven menos la privacidad, posiblemente no sea compatible con todos los navegadores.
- Desventaja: es posible que los usuarios de
Protección contra la falsificación de solicitudes entre sitios (CSRF)
Un emisor de solicitudes siempre puede decidir no enviar la URL de referencia configurando una
no-referrer
. Además, un agente malicioso podría incluso falsificar la identidad del referente.
Usar tokens CSRF.
como su protección principal. Para mayor protección, usa
SameSite y
en lugar de Referer
, usa encabezados como
Origin
(disponible en solicitudes POST y CORS) y
Sec-Fetch-Site
si está disponible.
Registro y depuración
Asegúrate de proteger las contraseñas datos personales o sensibles que puedan
Referer
Si solo usas el origen, comprueba si puedes usar el
Origin
encabezado como
como alternativa. Esto podría darte la información que necesitas para la depuración
de forma más sencilla y sin necesidad de analizar la URL de referencia.
Pagos
Los proveedores de pagos podrían basarse en el encabezado Referer
de las solicitudes entrantes para
controles de seguridad.
Por ejemplo:
- El usuario hace clic en el botón Comprar en
online-shop.example/cart/checkout
. online-shop.example
redirecciona apayment-provider.example
para administrar transacción.payment-provider.example
verifica elReferer
de esta solicitud con una lista. de los valores deReferer
permitidos que configuraron los comercios. Si no coincide con ninguno entrada de la lista,payment-provider.example
rechaza la solicitud. Si aparece el usuario puede continuar con la transacción.
Prácticas recomendadas para las verificaciones de seguridad del flujo de pago
Como proveedor de pagos, puedes usar Referer
como comprobación básica de algunos
de ataques de seguridad cibernética. Sin embargo, el encabezado Referer
por sí solo no es una base confiable para
un cheque. El sitio solicitante, independientemente de si se trata de un comercio legítimo o no, puede establecer una
no-referrer
política que hace que la información de Referer
no esté disponible para el
proveedor de pagos.
Analizar Referer
podría ayudar a los proveedores de pagos a detectar atacantes ingenuos que
no estableciste una política no-referrer
. Si usas Referer
como primera verificación, haz lo siguiente:
- No esperes que el
Referer
esté siempre presente. Si está presente, revísala. solo con la cantidad mínima de datos que puede incluir, que es el origen.- Cuando configures la lista de valores
Referer
permitidos, asegúrate de incluir solo el origen y ninguna ruta. - Por ejemplo, los valores de
Referer
permitidos paraonline-shop.example
deben tener las siguientes características:online-shop.example
, noonline-shop.example/cart/checkout
. Al esperar ningún valorReferer
oReferer
que sea solo la solicitud desde el origen del sitio, se evitan los errores que podrían surgir al hacer suposiciones sobre elReferrer-Policy
del comercio.
- Cuando configures la lista de valores
- Si el
Referer
no está, o si está presente y tu origenReferer
básico la verificación se realiza correctamente, puedes pasar a otra verificación más confiable .
Para verificar los pagos de forma más confiable, permite que el solicitante Generar un hash para los parámetros de la solicitud junto con una clave única Luego, los proveedores de pagos pueden calcular el mismo hash por ti. y solo acepta la solicitud si coincide con tu cálculo.
Qué sucede con el error Referer
cuando el sitio de un comercio HTTP sin URL de referencia
redirige a un proveedor de pagos HTTPS?
No hay ningún Referer
visible en la solicitud al proveedor de pagos HTTPS porque
la mayoría de los navegadores usan strict-origin-when-cross-origin
o
no-referrer-when-downgrade
de forma predeterminada cuando un sitio web no tiene una política establecida.
Cambio de Chrome a una nueva política predeterminada
no cambiará este comportamiento.
Conclusión
Una política de URL de referencia protectora es una excelente forma de brindar más privacidad a los usuarios.
Para obtener más información sobre las diferentes técnicas para proteger a tus usuarios, consulta nuestra Recopilación segura
Recursos
- Acerca de "same-site" y “same-origin”
- Un nuevo encabezado de seguridad: Política de URLs de referencia (2017)
- Política de Referencias sobre MDN
- Encabezado de referencia: inquietudes sobre la privacidad y la seguridad en MDN
- Cambio en Chrome: Parpadea con el intent para implementar
- Cambio en Chrome: Parpadea con el intent para envío
- Cambio en Chrome: entrada de estado
- Cambio en Chrome: versión beta 85 blogpost
- Conversaciones de referencia sobre el corte del subproceso de GitHub: ¿En qué navegadores están los diferentes navegadores? sí
- Especificaciones de la política de referencias
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.