Best practice relative alle norme sui referrer e sui referrer

Maud Nalpas

In questa pagina vengono descritte alcune best practice per l'impostazione di Referrer-Policy e l'utilizzo del referrer nelle richieste in entrata.

Riepilogo

• La fuga di informazioni multiorigine imprevista danneggia la privacy degli utenti web. Una policy di referrer protettiva può essere d'aiuto.
• Valuta la possibilità di impostare un criterio referrer di strict-origin-when-cross-origin. In questo modo, il referrer mantiene la maggior parte della sua utilità, riducendo al contempo il rischio di fuga di dati multiorigine.
• Non utilizzare i referrer per la protezione da falsificazione di richiesta cross-site (CSRF). Utilizza invece i token CSRF e altre intestazioni come ulteriore livello di sicurezza.

Nota:

• Se non hai chiara la differenza tra "sito" e "origine", consulta Informazioni su "stesso sito" e "stessa origine".
• Nell'intestazione Referer manca una R a causa di un errore ortografico nella specifica originale. L'intestazione Referrer-Policy e referrer in JavaScript e nel DOM sono scritte correttamente.

Nozioni di base su Referer e Referrer-Policy

Le richieste HTTP possono includere un'intestazione Referer facoltativa, che indica l'origine o l'URL della pagina web da cui è stata effettuata la richiesta. L'intestazione Referrer-Policy definisce quali dati vengono resi disponibili nell'intestazione Referer.

Nell'esempio seguente, l'intestazione Referer include l'URL completo della pagina su site-one da cui è stata effettuata la richiesta.

Una richiesta HTTP con un'intestazione Referer.

L'intestazione Referer potrebbe essere presente in diversi tipi di richieste:

• Richieste di navigazione, quando un utente fa clic su un link.
• Richieste di risorse secondarie, quando un browser richiede immagini, iframe, script e altre risorse necessarie per una pagina.

Per le navigazioni e gli iframe, puoi accedere a questi dati anche con JavaScript utilizzando document.referrer.

Puoi imparare molto dai valori Referer. Ad esempio, un servizio di analisi potrebbe utilizzarli per determinare che il 50% dei visitatori di site-two.example proveniva da social-network.example. Tuttavia, quando l'URL completo, inclusi il percorso e la stringa di query, viene inviato nell'Referer tra origini, può mettere a rischio la privacy dell'utente e creare rischi per la sicurezza:

L'utilizzo dell'URL completo può influire sulla privacy e sulla sicurezza degli utenti.

Gli URL da 1 a 5 contengono informazioni private e, a volte, informazioni sensibili o identificative. La divulgazione silenziosa di questi dati tra origini può compromettere la privacy degli utenti web.

L'URL n. 6 è un URL di funzionalità. Se un utente diverso da quello previsto riceve questo messaggio, un malintenzionato può assumere il controllo dell'account di questo utente.

Per limitare i dati del referrer resi disponibili per le richieste provenienti dal tuo sito, puoi impostare una policy dei referrer.

Quali policy sono disponibili e in che cosa differiscono?

Puoi selezionare una delle otto policy. A seconda della policy, i dati disponibili dall'intestazione Referer (e document.referrer) possono essere:

• Nessun dato (nessuna intestazione Referer presente)
• Solo l'origine
• L'URL completo: origine, percorso e stringa di query

Esempi di dati del referrer.

Alcune policy sono progettate per comportarsi in modo diverso a seconda del contesto: richiesta multiorigine o della stessa origine, se la destinazione della richiesta è sicura come l'origine o entrambe. Questo è utile per limitare la quantità di informazioni condivise tra origini o con origini meno sicure, mantenendo al contempo la ricchezza del referrer all'interno del tuo sito.

La tabella seguente mostra in che modo le policy dei referrer limitano i dati degli URL disponibili dall'intestazione Referer e da document.referrer:

Ambito delle policy	Nome del criterio	Referer: nessun dato	Referer: solo origine	Referer: URL completo
Non considera il contesto della richiesta	no-referrer	check
	origin		check
	unsafe-url			check
Incentrato sulla sicurezza	strict-origin	Richiesta da HTTPS a HTTP	Richiesta da HTTPS a HTTPS o da HTTP a HTTP
	no-referrer-when-downgrade	Richiesta da HTTPS a HTTP		Richiesta da HTTPS a HTTPS o da HTTP a HTTP
Incentrato sulla privacy	origin-when-cross-origin		Richiesta multiorigine	Richiesta della stessa origine
	same-origin	Richiesta multiorigine		Richiesta della stessa origine
Incentrato su privacy e sicurezza	strict-origin-when-cross-origin	Richiesta da HTTPS a HTTP	Richiesta multiorigine da HTTPS a HTTPS o da HTTP a HTTP	Richiesta della stessa origine

MDN fornisce un elenco completo di esempi di policy e comportamenti.

Ecco alcuni aspetti da tenere presente quando imposti un criterio di referrer:

• Tutte le policy che tengono conto dello schema (HTTPS rispetto a HTTP) (strict-origin, no-referrer-when-downgrade e strict-origin-when-cross-origin) trattano le richieste da un'origine HTTP a un'altra origine HTTP allo stesso modo delle richieste da un'origine HTTPS a un'altra origine HTTPS, anche se HTTP è meno sicuro. Questo perché per queste policy ciò che conta è se si verifica un downgrade della sicurezza, ovvero se la richiesta può esporre i dati da un'origine criptata a una non criptata, come nelle richieste HTTPS → HTTP. Una richiesta HTTP → HTTP è completamente non criptata, quindi non viene eseguito il downgrade.
• Se una richiesta è same-origin, significa che lo schema (HTTPS o HTTP) è lo stesso, quindi non si verifica un downgrade della sicurezza.

Criteri referrer predefiniti nei browser

Stato: ottobre 2021

Se non viene impostata alcuna policy del referrer, il browser utilizza la policy predefinita.

Browser	Referrer-Policy / comportamento predefinito
Chrome	Il valore predefinito è strict-origin-when-cross-origin.
Firefox	Il valore predefinito è strict-origin-when-cross-origin. A partire dalla versione 93, per gli utenti della protezione antitracciamento avanzata e della navigazione privata, i criteri di referrer meno restrittivi no-referrer-when-downgrade, origin-when-cross-origin e unsafe-url vengono ignorati per le richieste cross-site, il che significa che il referrer viene sempre tagliato per le richieste cross-site, indipendentemente dai criteri del sito web.
Edge	Il valore predefinito è strict-origin-when-cross-origin.
Safari	Il valore predefinito è simile a strict-origin-when-cross-origin, con alcune differenze specifiche. Per maggiori dettagli, consulta Prevenzione del monitoraggio della prevenzione del monitoraggio.

Best practice per l'impostazione della policy del referrer

Obiettivo: imposta esplicitamente una policy per il miglioramento della privacy, ad esempio strict-origin-when-cross-origin(o più restrittiva).

Esistono diversi modi per impostare i criteri dei referrer per il tuo sito:

• Come intestazione HTTP
• Nel tuo HTML
• Da JavaScript per ogni richiesta

Puoi impostare policy diverse per pagine, richieste o elementi diversi.

L'intestazione HTTP e l'elemento meta sono entrambi a livello di pagina. L'ordine di priorità per determinare la policy effettiva di un elemento è il seguente:

1. Policy a livello di elemento
2. Norme a livello di pagina
3. Browser predefinito

Esempio:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

L'immagine viene richiesta con una policy no-referrer-when-downgrade e tutte le altre richieste di risorse secondarie da questa pagina seguono la policy strict-origin-when-cross-origin.

Come visualizzare il criterio del referrer?

securityheaders.com è utile per determinare quale policy viene utilizzata da un sito o una pagina specifici.

Puoi anche utilizzare gli strumenti per sviluppatori di Chrome, Edge o Firefox per visualizzare la policy sui referrer utilizzata per una richiesta specifica. Al momento della stesura di questo documento, Safari non mostra l'intestazione Referrer-Policy, ma mostra l'intestazione Referer che è stata inviata.

Riquadro Rete di Chrome DevTools con una richiesta selezionata.

Quale criterio dovresti impostare per il tuo sito web?

Ti consigliamo vivamente di impostare esplicitamente una policy che migliori la privacy, ad esempio strict-origin-when-cross-origin (o più restrittiva).

Perché "esplicitamente"?

Se non imposti una policy dei referrer, verrà utilizzata la policy predefinita del browser. Di fatto, i siti web spesso si affidano alle impostazioni predefinite del browser. Tuttavia, questa non è la soluzione ideale perché:

• Browser diversi hanno policy predefinite diverse, quindi se ti affidi alle impostazioni predefinite del browser, il tuo sito non si comporterà in modo prevedibile nei vari browser.
• I browser stanno adottando valori predefiniti più severi come strict-origin-when-cross-origin e meccanismi come il taglio dei referrer per le richieste multiorigine. L'attivazione esplicita di una policy per il miglioramento della privacy prima che le impostazioni predefinite del browser cambino ti offre il controllo e ti aiuta a eseguire i test come ritieni opportuno.

Perché strict-origin-when-cross-origin (o più restrittivo)?

Hai bisogno di norme sicure, utili e che migliorino la privacy. Il significato di "utile" dipende da ciò che vuoi dal referrer:

• Secure: se il tuo sito web utilizza HTTPS (in caso contrario, rendilo una priorità), non vuoi che gli URL del tuo sito web vengano divulgati in richieste non HTTPS. Poiché chiunque sulla rete può vederli, le fughe di dati esporrebbero i tuoi utenti ad attacchi person-in-the-middle. Le policy no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer e strict-origin risolvono questo problema.
• Miglioramento della privacy: per una richiesta multiorigine, no-referrer-when-downgrade condivide l'URL completo, il che può causare problemi di privacy. strict-origin-when-cross-origin e strict-origin condividono solo l'origine, mentre no-referrer non condivide nulla. In questo modo, ti rimangono strict-origin-when-cross-origin, strict-origin e no-referrer come opzioni per migliorare la privacy.
• Utile: no-referrer e strict-origin non condividono mai l'URL completo, nemmeno per le richieste della stessa origine. Se hai bisogno dell'URL completo, strict-origin-when-cross-origin è un'opzione migliore.

Tutto ciò significa che strict-origin-when-cross-origin è generalmente una scelta sensata.

Esempio: impostazione di una policy strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

O lato server, ad esempio in Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Cosa succede se strict-origin-when-cross-origin (o un criterio più restrittivo) non soddisfa tutti i tuoi casi d'uso?

In questo caso, adotta un approccio progressivo: imposta una policy protettiva come strict-origin-when-cross-origin per il tuo sito web e, se necessario, una policy più permissiva per richieste o elementi HTML specifici.

Esempio: policy a livello di 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 potrebbe limitare document.referrer o l'intestazione Referer per le richieste cross-site. Visualizza i dettagli.

Esempio: policy a livello di richiesta

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Cos'altro dovresti considerare?

La policy deve dipendere dal tuo sito web e dai casi d'uso, come stabilito da te, dal tuo team e dalla tua azienda. Se alcuni URL contengono dati identificativi o sensibili, imposta una policy di protezione.

Avviso: i dati che potrebbero non sembrare sensibili per te possono esserlo per i tuoi utenti o semplicemente non essere dati che vogliono o si aspettano che vengano divulgati silenziosamente multiorigine.

Best practice per le richieste in entrata

Ecco alcune linee guida su cosa fare se il tuo sito utilizza l'URL referrer delle richieste in entrata.

Proteggere i dati degli utenti

Referer può contenere dati privati, personali o identificativi, quindi assicurati di trattarli come tali.

I referrer in entrata possono cambiare {referer-can-change}

L'utilizzo del referrer delle richieste multiorigine in entrata presenta alcune limitazioni:

• Se non hai il controllo sull'implementazione dell'emettitore della richiesta, non puoi fare supposizioni sull'intestazione Referer (e document.referrer) che ricevi. L'emittente della richiesta potrebbe decidere di passare a una policy no-referrer in qualsiasi momento o, più in generale, a una policy più restrittiva rispetto a quella utilizzata in precedenza. Ciò significa che ricevi meno dati da Referer rispetto a prima.
• I browser utilizzano sempre più spesso l'intestazione Referrer-Policy strict-origin-when-cross-origin per impostazione predefinita. Ciò significa che ora potresti ricevere solo l'origine, anziché un URL referrer completo, nelle richieste multiorigine in entrata, se il sito del mittente non ha impostato una policy.
• I browser potrebbero cambiare il modo in cui gestiscono i Referer. Ad esempio, alcuni sviluppatori di browser potrebbero decidere di tagliare sempre i referrer alle origini nelle richieste di risorse secondarie multiorigine per proteggere la privacy degli utenti.
• L'intestazione Referer (e document.referrer) potrebbe contenere più dati di quelli necessari. Ad esempio, potrebbe avere un URL completo quando vuoi solo sapere se la richiesta è multiorigine.

Alternative a Referer

Potresti dover prendere in considerazione delle alternative se:

• Una funzionalità essenziale del tuo sito utilizza l'URL referrer delle richieste multiorigine in entrata.
• Il tuo sito non riceve più la parte dell'URL del referrer di cui ha bisogno in una richiesta multiorigine. Ciò accade quando l'emittente della richiesta modifica la propria policy o quando non ha impostato alcuna policy e la policy predefinita del browser è cambiata (come in Chrome 85).

Per definire le alternative, analizza innanzitutto quale parte del referrer stai utilizzando.

Se hai bisogno solo dell'origine

• Se utilizzi il referrer in uno script che ha accesso di primo livello alla pagina, window.location.origin è un'alternativa.
• Se disponibili, intestazioni come Origin e Sec-Fetch-Site ti forniscono l'Origin o descrivono se la richiesta è multiorigine, il che potrebbe essere esattamente ciò di cui hai bisogno.

Se hai bisogno di altri elementi dell'URL (percorso, parametri di query e così via)

• I parametri di richiesta potrebbero essere adatti al tuo caso d'uso, risparmiandoti il lavoro di analisi del referrer.
• Se utilizzi il referrer in uno script che ha accesso di primo livello alla pagina, window.location.pathname potrebbe funzionare come alternativa. Estrai solo la sezione del percorso dell'URL e passala come argomento, in modo che le informazioni potenzialmente sensibili nei parametri URL non vengano trasmesse.

Se non puoi utilizzare queste alternative:

• Verifica se puoi modificare i tuoi sistemi in modo che l'emettitore della richiesta (ad esempio site-one.example) imposti esplicitamente le informazioni di cui hai bisogno in un qualche tipo di configurazione.
  • Pro: più esplicito, più rispettoso della privacy per gli utenti di site-one.example, più a prova di futuro.
  • Svantaggio: potenzialmente più lavoro da parte tua o per gli utenti del tuo sistema.
• Verifica se il sito che invia le richieste potrebbe accettare di impostare un valore Referrer-Policy per elemento o per richiesta pari a no-referrer-when-downgrade.
  • Svantaggio: potenzialmente meno attento alla privacy per gli utenti di site-one.example, potenzialmente non supportato in tutti i browser.

Protezione da falsificazione di richiesta cross-site (CSRF)

Un mittente della richiesta può sempre decidere di non inviare il referrer impostando una policy no-referrer e un malintenzionato potrebbe persino falsificare il referrer.

Utilizza i token CSRF come protezione principale. Per una maggiore protezione, utilizza SameSite e, anziché Referer, utilizza intestazioni come Origin (disponibile per le richieste POST e CORS) e Sec-Fetch-Site, se disponibile.

Log e debug

Assicurati di proteggere i dati personali o sensibili degli utenti che potrebbero essere presenti in Referer.

Se utilizzi solo l'origine, controlla se puoi utilizzare l'intestazione Origin come alternativa. In questo modo, potresti ottenere le informazioni necessarie per il debug in modo più semplice e senza dover analizzare il referrer.

Pagamenti

I fornitori di servizi di pagamento potrebbero fare affidamento sull'intestazione Referer delle richieste in arrivo per i controlli di sicurezza.

Ad esempio:

• L'utente fa clic su un pulsante Acquista su online-shop.example/cart/checkout.
• online-shop.example reindirizza a payment-provider.example per gestire la transazione.
• payment-provider.example confronta il Referer di questa richiesta con un elenco di valori Referer consentiti configurati dai commercianti. Se non corrisponde a nessuna voce dell'elenco, payment-provider.example rifiuta la richiesta. Se corrisponde, l'utente può procedere con la transazione.

Best practice per i controlli di sicurezza del flusso di pagamento

In qualità di fornitore di servizi di pagamento, puoi utilizzare Referer come controllo di base contro alcuni attacchi. Tuttavia, l'intestazione Referer da sola non è una base affidabile per un controllo. Il sito richiedente, che si tratti di un commerciante legittimo o meno, può impostare una policy no-referrer che rende le informazioni Referer non disponibili per il fornitore di servizi di pagamento.

L'analisi del Referer potrebbe aiutare i fornitori di servizi di pagamento a individuare gli utenti malintenzionati ingenui che non hanno impostato una policy no-referrer. Se utilizzi Referer come primo controllo:

• Non aspettarti che l'oggetto Referer sia sempre presente. Se è presente, controllalo solo in base ai dati minimi che può includere, ovvero l'origine.
  • Quando imposti l'elenco dei valori Referer consentiti, assicurati di includere solo l'origine e nessun percorso.
  • Ad esempio, i valori Referer consentiti per online-shop.example devono essere online-shop.example, non online-shop.example/cart/checkout. Se non prevedi alcun Referer o un valore Referer che corrisponda solo all'origine del sito richiedente, eviti gli errori che potrebbero derivare da ipotesi sull'Referrer-Policy del commerciante.
• Se l'intestazione Referer è assente o se è presente e il controllo di base dell'origine Referer ha esito positivo, puoi passare a un altro metodo di verifica più affidabile.

Per verificare i pagamenti in modo più affidabile, consenti al richiedente di eseguire l'hashing dei parametri di richiesta insieme a una chiave univoca. I fornitori di servizi di pagamento possono quindi calcolare lo stesso hash sul tuo lato e accettare la richiesta solo se corrisponde al tuo calcolo.

Che cosa succede al Referer quando un sito del commerciante HTTP senza un criterio di referrer reindirizza a un fornitore di servizi di pagamento HTTPS?

Nessun Referer è visibile nella richiesta al fornitore di servizi di pagamento HTTPS, perché la maggior parte dei browser utilizza strict-origin-when-cross-origin o no-referrer-when-downgrade per impostazione predefinita quando un sito web non ha un criterio impostato. La modifica di Chrome a una nuova policy predefinita non cambierà questo comportamento.

Nota: se il tuo sito web utilizza HTTP, esegui la migrazione a HTTPS.

Conclusione

Una policy di referrer protettiva è un ottimo modo per offrire ai tuoi utenti una maggiore privacy.

Per scoprire di più sulle diverse tecniche per proteggere i tuoi utenti, consulta la nostra raccolta Sicurezza e protezione.

Risorse

• Informazioni su "stesso sito" e "stessa origine"
• A new security header: Referrer Policy (2017)
• Referrer-Policy su MDN
• Referer header: privacy and security concerns on MDN
• Modifica di Chrome: Blink intent to implement
• Modifica di Chrome: Blink intent to ship
• Modifica di Chrome: voce dello stato
• Modifica di Chrome: post del blog sulla versione beta 85
• Thread di GitHub sul trimming dei referrer: cosa fanno i diversi browser
• Referrer-Policy Spec

Un ringraziamento speciale per i contributi e i feedback a tutti i revisori, in particolare Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck e Kayce Basques.