También disponible en: English · Português · Français · العربية
Referrer-Policy: todos los valores comparados y la regla que nadie cuenta
Averigua qué política está en vigor, qué pondría de verdad una petición en la cabecera Referer y por qué mandar dos valores es una técnica documentada.
Qué hace la cabecera Referrer-Policy
Cuando un navegador sigue un enlace o pide un recurso, lo normal es que le diga al destino de dónde venía, en una cabecera llamada Referer. Referrer-Policy es como un sitio controla cuánto de eso regala: la URL entera con su ruta y su consulta, solo el origen, o nada. Hay ocho valores, y la especificación define cada uno frente a tres situaciones: una petición al mismo origen, una a otro origen y una que sale de una página segura hacia un destino inseguro.
Si no mandas cabecera, lo que se aplica es strict-origin-when-cross-origin. Eso manda la URL completa dentro de tu propio sitio, solo el origen al salir de él, y nada cuando el destino baja a HTTP a secas. Es un valor por defecto sensato, y conviene conocerlo, porque una cabecera que el navegador no sabe interpretar te deja exactamente con esto y con nada más.
Un detalle que la propia especificación señala sobre su nombre: la cabecera no repite la famosa errata. La cabecera de petición es Referer, con una sola r, un error de escritura ya lo bastante viejo como para ser permanente. La cabecera de respuesta que la controla es Referrer-Policy, bien escrita. Escribirlas al revés es una forma habitual de poner una cabecera que en silencio no hace nada.
Cómo usarlo
- Pega tu cabecera. Una por línea si mandas más de una: un navegador lee varias cabeceras Referrer-Policy como una sola lista separada por comas. El panel de abajo enseña cada valor y dice cuál va a usar de verdad.
- Pon las dos URL. La página que enlaza y el destino. Las dos necesitan esquema, porque el esquema es lo que decide si la petición es del mismo origen, de otro, o una degradación, y esas tres son las únicas distinciones que hace cualquiera de las políticas.
- Lee la fila del Referer. Enseña la cabecera exacta que llevaría la petición, o dice que no se manda ninguna. La tabla del final pone las ocho políticas una al lado de otra, con la que está en vigor resaltada.
Por qué gana el último valor, y por qué eso sirve
Esta es la parte que pilla a la gente, y está escrita con claridad. La especificación dice que los valores de política desconocidos se ignoran, y que cuando varias fuentes especifican una política de referente se usa el valor de la última. No el de la primera. El algoritmo de análisis tiene tres pasos: empieza sin nada y, por cada token de la cabecera, si es una política que reconoces, pon la política a ese valor. Lo último que hayas reconocido es con lo que te quedas.
Eso da la vuelta al instinto habitual. Un valor de cabecera con pinta de lista normalmente significa alternativas por orden de preferencia, y la forma natural de escribir un analizador es quedarse con lo primero que entiendas y parar. Aquí hay que seguir, y un analizador que para pronto da la respuesta equivocada en el propio ejemplo de la especificación.
El motivo es el despliegue. La especificación trabaja el caso ella misma: manda origin seguido de unsafe-url y un navegador demasiado antiguo para conocer unsafe-url lo ignora y usa origin, mientras que uno actual llega hasta el final y usa unsafe-url. Así que Referrer-Policy: origin, unsafe-url no es una errata ni una línea duplicada: es la forma documentada de adoptar un valor nuevo sin abandonar a los clientes viejos. La gramática está hecha para eso: la especificación permite un token desconocido justamente para que un navegador no falle al analizar la cabecera entera cuando se encuentre uno.
La misma regla tiene un filo más incómodo. Si no se reconoce nada de tu cabecera —una errata, un valor sacado de un artículo que nunca llegó a existir, un nombre de política con un guion bajo— el navegador se queda con la cadena vacía y recurre a su valor por defecto. La cabecera no ha hecho nada, y nada en la respuesta te lo dice. Eso es lo primero que informa el panel de arriba.
Qué manda de verdad cada política
La tabla de ocho por tres de esta página está transcrita de la frase de la especificación que define cada política, no montada de memoria ni sacada de las tablas de otros. Hay dos filas que conviene leer dos veces, porque son las que más se confunden.
origin y strict-origin se parecen muchísimo —las dos mandan solo el origen— y se diferencian en exactamente una casilla. origin lo manda a todas partes, incluido HTTP a secas; strict-origin se lo calla en esa degradación. La especificación es explícita sobre el motivo: señala que origin permite que el origen de referentes HTTPS viaje por la red dentro de peticiones HTTP sin cifrar, y que strict-origin resuelve esa preocupación. La misma pareja se repite un nivel más arriba: origin-when-cross-origin y strict-origin-when-cross-origin solo se diferencian en la columna de degradación.
Hay además un caso que sorprende a quien piensa en los orígenes como una cuestión de nombres de dominio. Un origen incluye el esquema, así que pasar de http a https en el mismo host es una petición a otro origen, no al mismo: la especificación menciona expresamente las mejoras de protocolo. Un puerto distinto hace lo mismo. Si una política se comporta de forma rara en una petición que no sale de tu dominio, normalmente es por esto.
Y unsafe-url significa lo que dice. La especificación añade una nota que casi suena a disculpa: el nombre de la política no miente, es insegura, y filtrará orígenes y rutas de recursos seguros hacia orígenes inseguros. Su ejemplo usa un documento llamado sekrit.html por algo.
Lo que esto no te va a decir
Esto averigua qué significa una política. No sabe qué manda tu servidor. Un navegador no puede leerte las cabeceras de respuesta de otro sitio, así que la cabecera de la caja es la que has escrito tú, no la que hay en producción: comprueba eso con el panel de red del navegador o con una petición desde la línea de comandos.
La clasificación de un destino como seguro o no es una simplificación, y conviene decirlo. La especificación delega en otro estándar lo que cuenta como URL potencialmente confiable, y ese algoritmo abarca más de lo que implementa esta página: aquí se tratan como confiables https, wss y file, más localhost y las direcciones de bucle local, y todo lo demás no. Eso cubre todos los ejemplos de la especificación y todo lo que vas a escribir en la práctica, pero un esquema que un navegador o una aplicación empaquetada registre como confiable se juzgará mal.
La política de una página tampoco es lo único que interviene. Un solo enlace puede saltársela con un atributo referrerpolicy, rel=noreferrer quita el referente entero, un iframe puede poner el suyo, y una redirección puede cambiar la política a mitad de una petición. Esta página responde la pregunta para una política y un par de URL, que es de lo que va la cabecera; el resto son decisiones por elemento que se toman en tu marcado.
Y para acabar: nada de esto es una garantía de privacidad. Suprimir la cabecera Referer corta una fuga concreta; no hace nada con una URL que pasaste en una cadena de consulta, con un script que informa él mismo de la ubicación, ni con lo que el destino pueda deducir de la petición por otras vías. Es un control útil, no una cortina.
¿Por qué es gratis?
Leer una cabecera y comparar dos URL es trabajo de texto y corre en tu navegador. No hay ningún servidor de por medio, así que no hay nada que cobrar ni cuenta que crear.
No se sube nada y no se guarda nada. Recarga la página y habrá olvidado las URL que escribiste.