Referer

L’header Referer (sì, scritto in modo errato — la specifica HTTP del 1996 ha fissato la forma canonica come “Referer” e il refuso è diventato standard) viene inviato dai browser nella maggior parte delle richieste, contenendo l’URL della pagina su cui si trovava l’utente quando ha avviato la richiesta.

Utilizzato per:

• Analisi web — “da dove proviene questo traffico?”
• Prevenzione dell’hotlinking — gli host di immagini verificano che le richieste provengano da siti approvati.
• Difesa in profondità contro CSRF — alcune app verificano che il Referer corrisponda all’origine prevista.
• Attribuzione di affiliazione — tracciamento di quale sito partner ha generato una conversione.

Problema moderno per la privacy: l’URL completo — inclusi eventuali token, query di ricerca o PII nel percorso URL — viene trasmesso a ogni risorsa di terze parti caricata dalla pagina. L’header di risposta Referrer-Policy (nota: questa volta scritto correttamente) controlla quante informazioni sul referrer i browser inviano:

• no-referrer: non inviare mai un header Referer.
• same-origin: invia l’URL completo alle richieste della stessa origine, nulla alle altre.
• strict-origin-when-cross-origin: invia solo l’origine alle richieste HTTPS cross-origin. Default moderno dei browser.
• unsafe-url: invia sempre l’URL completo. Da evitare.

Per le applicazioni sensibili alla privacy, impostare una policy rigorosa su ogni risposta.

Il famoso refuso: l’header fu originariamente proposto nel 1995 da Phillip Hallam-Baker, e la specifica scrisse male “Referrer” come “Referer” prima che l’errore fosse rilevato. Quando qualcuno se ne accorse, diverse implementazioni principali erano già in distribuzione. RFC 1945 ha congelato il refuso come canonica, e ogni browser da allora ha dovuto usare la forma errata per la compatibilità wire HTTP. Quando il W3C ha aggiunto un header di policy nel 2014, lo ha deliberatamente scritto correttamente (Referrer-Policy) per differenziarlo dall’header di richiesta legacy.

Cosa inviano i browser moderni per impostazione predefinita: a partire da Chrome 85 (agosto 2020), Firefox 87 (marzo 2021) e Safari 14, la policy predefinita è strict-origin-when-cross-origin. Le richieste cross-origin ricevono ora solo l’origine (https://example.com), non l’URL completo. Le richieste della stessa origine ricevono ancora l’URL completo. Questo singolo cambiamento ha eliminato un decennio di perdite accidentali di token URL verso script di analytics e ad-tech di terze parti. Per configurazioni ad alto livello di paranoia (bancario, sanitario), impostare Referrer-Policy: no-referrer su ogni risposta — gli header di produzione di Convertitive usano come default strict-origin-when-cross-origin. Riferimento: W3C — Referrer Policy.

Esempio pratico: perdita di un URL di reset password

Un pattern di violazione comune: un’app invia via email un link di reset password nella forma https://app.example.com/reset?token=abc123def456.... L’utente clicca; la pagina di reset si carica e include Google Analytics, Facebook Pixel e una libreria di grafici da una CDN. Con la policy predefinita pre-2020, ogni richiesta di terze parti portava Referer: https://app.example.com/reset?token=abc123def456... — trasmettendo il token di reset ai log dei server di quattro diversi fornitori. Con il moderno default strict-origin-when-cross-origin, le richieste cross-origin portano solo Referer: https://app.example.com e il token rimane privato. Ancora meglio, impostare Referrer-Policy: no-referrer su ogni risposta di flusso sensibile — la difesa in profondità non costa nulla.

Cosa trapela ancora nonostante la policy

Referrer-Policy governa solo l’header Referer. I token URL compaiono ancora nella cronologia del browser, nella proprietà JavaScript document.referrer visibile agli script della stessa origine, nelle istruzioni di log di window.location e in qualsiasi SDK di monitoraggio degli errori che acquisisce gli URL. La soluzione architetturale è inserire i token sensibili nel corpo della richiesta o in un cookie a vita breve impostato immediatamente all’arrivo, poi reindirizzare a un URL senza il token. Riferimento: RFC 9110 — HTTP Semantics §10.1.3 (Referer), che preserva il refuso originale nella riscrittura HTTP canonica del 2022.