Per què els URL filtren dades sensibles i com evitar-ho

Un URL sembla privat perquè només l'haurien de tenir les persones a qui l'envieu. A la pràctica, un URL és una de les dades que més es registren al web: l'anoten, el copien i el reenvien sistemes que no us han demanat permís i que no podeu auditar. Aquí teniu exactament on es filtra i com dissenyar enllaços que ho resisteixin. També és el motiu pel qual un generador d'enllaços secrets d'un sol ús guarda la clau de desxifratge a la part de l'enllaç que va després del #: aquesta part no arriba mai a cap registre de servidor.

Per on es filtra

• L'historial del navegador. Cada URL que visita l'usuari es desa en local i es pot sincronitzar amb altres dispositius i amb el servei de sincronització del fabricant del navegador.
• Els registres d'accés del servidor HTTP. La majoria de servidors registren per defecte el camí sencer de la sol·licitud i la cadena de consulta. Qualsevol persona amb accés als registres té l'URL.
• Els servidors intermediaris inversos i les CDN. Cloudflare, Fastly, el vostre balancejador de càrrega: tots registren l'URL, cadascun amb la seva pròpia política de conservació.
• Els sistemes d'agregació de registres. Els registres d'accés rarament es queden en una sola màquina: s'envien a serveis centralitzats de registre i monitoratge, i així es multiplica el nombre de sistemes que guarden l'URL.
• La capçalera Referer. Quan la pàgina enllaça a un recurs d'un tercer, el navegador pot enviar l'URL d'origen a la capçalera Referer. Els scripts d'estadístiques, els vídeos incrustats i els píxels publicitaris la reben.
• Les extensions del navegador. Les extensions amb el permís de «llegir l'historial de navegació» veuen cada URL, fragments inclosos.
• La sincronització d'adreces d'interès. Els URL desats com a adreces d'interès se sincronitzen entre els dispositius de l'usuari i amb els servidors del fabricant del navegador.
• Els previsualitzadors d'enllaços. Slack, Teams, iMessage, LinkedIn i els clients de correu obren els URL per mostrar-ne una previsualització, sense avisar i en el moment en què s'envia el missatge.
• Els servidors intermediaris corporatius i les passarel·les de correu. Moltes organitzacions inspeccionen, reescriuen i registren cada URL que travessa el seu perímetre.

HTTPS fa que l'URL sigui privat?

No. HTTPS xifra l'URL durant el trànsit i res més; els dos extrems el continuen desant. Val la pena ser precisos, perquè «la connexió està xifrada» es malinterpreta sovint com a «l'URL és privat».

TLS xifra el camí i la cadena de consulta durant el trànsit: algú que observi la xarxa entre el navegador i el servidor no pot llegir /reset?token=.... El que TLS no amaga: el nom d'amfitrió de destinació (visible per la resolució DNS i pel camp SNI de TLS en la majoria de connexions actuals) i tot el que passa als extrems. El navegador continua registrant l'URL sencer a l'historial i el servidor el continua escrivint al registre d'accés. El xifratge en trànsit protegeix el cable, no els dos extrems, i és als dos extrems on es filtren els URL.

Un exemple pràctic: la vida d'un URL

Seguim un sol URL sensible, per exemple un enllaç de restabliment, https://example.com/reset?token=8f3a91..., des que s'envia fins que s'hi fa clic:

1. El proveïdor de correu desa el missatge (URL inclòs) indefinidament, i el seu escàner de seguretat pot obrir l'URL quan el lliura.
2. La passarel·la de correu del destinatari reescriu i registra l'URL, i l'obre una altra vegada en el moment del clic.
3. El DNS resol example.com: el nom d'amfitrió (no el camí) ja és als registres del resolutor.
4. El servidor web escriu la línia sencera de la sol·licitud al registre d'accés. Una entrada amb el format «combined» per defecte de nginx o Apache té aquest aspecte:

203.0.113.7 - - [14/Jul/2026:09:12:45 +0000]
  "GET /reset?token=8f3a91... HTTP/1.1" 200 5123 "-" "Mozilla/5.0 ..."

5. La CDN que hi ha al davant registra el mateix URL amb la seva pròpia política de conservació.
6. L'script d'estadístiques de la pàgina registra l'URL de la pàgina, cadena de consulta inclosa, en un sistema d'un tercer, tret que s'hagi configurat expressament perquè la tregui.
7. El navegador desa l'URL a l'historial i el sincronitza.

Un sol enviament, set còpies, en mans de com a mínim cinc organitzacions. Res d'això ha necessitat cap atacant: és el web funcionant tal com està dissenyat.

La capçalera Referer a la pràctica

Si la pàgina on es mostra el secret enllaça a qualsevol recurs extern (un tipus de lletra d'una CDN, un script d'estadístiques, una imatge incrustada), el navegador pot enviar l'URL de la pàgina a aquell origen a la capçalera Referer.

Els navegadors actuals fan servir per defecte strict-origin-when-cross-origin (MDN: Referrer-Policy), que retalla els referents entre orígens diferents i en deixa només l'origen (https://example.com/ en lloc del camí sencer). És un progrés real, però no us hi podeu refiar: les sol·licituds del mateix origen continuen portant l'URL sencer, una política definida a la pàgina pot relaxar el valor per defecte, i els clients antics i les webviews incrustades no es comporten tots igual.

Dues mesures pràctiques:

<!-- Strip the referer for outbound requests on the page -->
<meta name="referrer" content="no-referrer" />

Referrer-Policy: no-referrer

La versió amb capçalera s'aplica a tot el lloc; l'etiqueta meta s'aplica a la pàgina concreta. Feu servir totes dues per tenir protecció en capes. Encara millor: serviu les pàgines sensibles sense cap recurs de tercers, perquè no hi hagi ningú a qui enviar el referent.

Un testimoni és més segur al camí, a la cadena de consulta o al fragment?

Només el fragment queda fora de la sol·licitud, i per tant només el fragment queda fora dels registres del servidor; el camí i la cadena de consulta són equivalents. On poseu un testimoni dins l'URL canvia qui el veu:

El fragment sí que és diferent: segons la RFC 3986, secció 3.5, es processa al client i no s'inclou mai a la sol·licitud HTTP. Per això les eines per enganxar text amb xifratge d'extrem a extrem hi posen la clau de desxifratge: el servidor no la rep mai, literalment. Tot i així, no és invisible: l'historial del navegador, les extensions i qualsevol JavaScript que s'executi a la pàgina la poden llegir. En canvi, entre el camí i la consulta no hi ha cap diferència de privadesa: tots dos acaben als mateixos registres.

El problema dels testimonis de restabliment de contrasenya

Els testimonis sensibles als URL són una classe de vulnerabilitat reconeguda. La CWE-598 de MITRE («Use of GET Request Method With Sensitive Query Strings») tracta exactament això: les dades sensibles de la cadena de consulta acaben als registres, als historials i als referents, sigui quin sigui el xifratge del transport. Per això els processos de restabliment de contrasenya ben fets no depenen mai només del fet que l'URL es mantingui secret. Fan que el testimoni sigui d'un sol ús, de curta durada i lligat a una acció posterior (definir una contrasenya nova), de manera que un testimoni recuperat d'un registre tres setmanes després no serveix de res.

Aquesta és la lliçó general: normalment no podeu evitar que un URL acabi als registres, però sí que podeu fer que l'URL registrat no serveixi de res quan algú el llegeixi.

Dissenyar URL que es puguin filtrar sense perill

Doneu per fet que tots els URL que genereu acabaran apareixent, tard o d'hora, en algun lloc no previst, i dissenyeu-los perquè no importi:

• Un sol ús. Destruïu el secret després de la primera lectura correcta, perquè un URL filtrat ja no funcioni quan aparegui a l'historial d'algú.
• Caducitat curta. Limiteu el període en què la filtració fa mal. Un URL que ha funcionat durant cinc minuts val molt menys que un que ha funcionat durant una setmana.
• Frase de contrasenya per un altre canal. Demaneu un secret que no hagi estat mai a l'URL. Així, l'URL sol, que és l'únic que tenen els registres, ja no és suficient.
• Separeu l'obertura de la visualització. Serviu les metadades amb GET i lliureu el contingut només amb un POST explícit, perquè els previsualitzadors d'enllaços i els escàners no puguin consumir el secret.
• Cap recurs de tercers a les pàgines sensibles, a més de Referrer-Policy: no-referrer i <meta name="robots" content="noindex">.
• Amagueu les rutes dels secrets als vostres propis registres. A nginx, transformeu l'URI de la sol·licitud abans de registrar-la (vegeu la referència del ngx_http_log_module per a log_format):

map $request_uri $loggable_uri {
    ~^/s/   "/s/[redacted]";
    default $request_uri;
}
log_format redacted '$remote_addr - $remote_user [$time_local] '
                    '"$request_method $loggable_uri" $status';
access_log /var/log/nginx/access.log redacted;

Només controleu els vostres propis registres (les còpies de la CDN, del servidor intermediari i del navegador continuen existint), i per això mateix els tres primers punts d'aquesta llista són els que fan la major part de la feina.

Com determina això els enllaços secrets

Aquest model d'amenaces explica per què els enllaços secrets de LinkPilot funcionen com funcionen: l'URL es tracta com si s'hagués de filtrar inevitablement, de manera que l'URL sol no és mai suficient. Un GET només retorna metadades; per veure el contingut cal un POST explícit, opcionalment protegit amb una frase de contrasenya de la qual es calcula el hash SHA-256 al client. Els secrets destruïts, caducats o revocats retornen HTTP 410 amb el contingut sobreescrit de manera irreversible, les respostes que mostren el secret porten Cache-Control: no-store, i els esdeveniments de visualització registren un hash de la IP amb una sal que es rota cada dia, no l'adreça en si. I un límit que diem obertament a la pàgina d'arquitectura de seguretat: la clau de desxifratge viatja a la part de l'enllaç que va després del #, així que tot l'enllaç s'ha de tractar com el secret, que és exactament el perill del qual parla aquest article. Una caducitat curta, la destrucció després de la lectura i una frase de contrasenya enviada per un altre canal són el que limita el mal quan es filtra un enllaç.

Actualització del 29 de setembre de 2026: originalment aquest paràgraf deia que LinkPilot no oferia xifratge d'extrem a extrem. Ara xifra el contingut de text al navegador, fitxers adjunts inclosos.

Límits

El disseny dels URL no ho pot arreglar tot. No controla què fa el destinatari després d'una lectura legítima, no pot eliminar les còpies que ja tenen tercers i no salvarà un URL que porti dades personals a la vista. Si l'adreça de correu d'un usuari és a la cadena de consulta, cap caducitat farà que no quedi registrada. La regla que val sempre: no poseu mai en un URL dades que després hàgiu de suprimir, perquè suprimir un URL de tots els llocs on s'ha copiat és pràcticament impossible. Dissenyeu URL que no serveixin de res quan es filtrin.

Lectures relacionades

• Com funcionen els enllaços secrets d'un sol ús
• Els escàners d'enllaços i els secrets d'un sol ús
• Compartir contrasenyes de manera segura: comparació de 5 mètodes

Referències

• IETF, RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, section 3.5 Fragment.
• MDN Web Docs, Referrer-Policy header.
• nginx, Module ngx_http_log_module.