Best practice relative alle norme sui referrer e sui referrer

Maud Nalpas

In questa pagina vengono descritte alcune best practice per impostare i criteri referrer e utilizzare il referrer nelle richieste in arrivo.

Riepilogo

• Una fuga di informazioni multiorigine imprevista danneggia la privacy degli utenti web. Può essere utile un criterio per i referrer protettivo.
• Valuta la possibilità di impostare un criterio relativo ai referrer strict-origin-when-cross-origin. Preserva la maggior parte dell'utilità del referrer, riducendo al contempo il rischio di perdita di dati multiorigine.
• Non utilizzare i referrer per la protezione della falsificazione di richieste tra siti (CSRF). Utilizza invece i token CSRF e altre intestazioni come ulteriore livello di sicurezza.

Nota:

• Se hai dubbi sulla differenza tra "site" e "origin", consulta Informazioni su "same-site" e "same-origin".
• Nell'intestazione Referer manca una R a causa di un errore di ortografia nelle specifiche originali. L'intestazione Referrer-Policy e referrer in JavaScript e nel DOM sono stati digitati correttamente.

Referer e Referrer-Policy 101

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.

Nel seguente esempio, 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 sottorisorse, quando un browser richiede immagini, iframe, script e altre risorse necessarie per una pagina.

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

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

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

Gli URL da 1 a 5 contengono informazioni private e talvolta informazioni sensibili o identificative. Diffondere queste informazioni automaticamente tra le origini può compromettere la privacy degli utenti web.

L'URL 6 è un URL con funzionalità. Se qualcuno oltre all'utente previsto riceve questo messaggio, un utente malintenzionato può assumere il controllo dell'account di questo utente.

Per limitare i dati referrer resi disponibili per le richieste dal tuo sito, puoi impostare un criterio relativo ai referrer.

Quali norme sono disponibili e in che cosa differiscono?

Puoi selezionare uno degli otto criteri disponibili. A seconda del criterio, i dati disponibili dall'intestazione Referer (e da document.referrer) possono essere:

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

Esempi di dati del referrer.

Alcuni criteri sono progettati per comportarsi in modo diverso a seconda del contesto: richiesta multiorigine o stessa origine, che la destinazione della richiesta sia sicura quanto l'origine o entrambe. Ciò è utile per limitare la quantità di informazioni condivise tra origini o a origini meno sicure, mantenendo al contempo la ricchezza del referrer all'interno del tuo sito.

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

Ambito delle norme	Nome del criterio	Referer: nessun dato	Referer: solo origine	Referer: URL completo
Non prende in considerazione il contesto della richiesta	no-referrer	segno di spunta
	origin		segno di spunta
	unsafe-url			segno di spunta
post 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
post 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 criteri ed esempi di comportamento.

Quando imposti un criterio relativo ai referrer, tieni presente quanto segue:

• Tutti i criteri che prendono in considerazione lo schema (HTTPS o 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 HTTPS, anche se HTTP è meno sicuro. Il motivo è che per questi criteri, ciò che conta è se viene eseguito un downgrade di 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 non è crittografata, quindi non è possibile eseguire il downgrade.
• Se una richiesta è same-origin, significa che lo schema (HTTPS o HTTP) è lo stesso, quindi non è previsto alcun downgrade della sicurezza.

Criteri referrer predefiniti nei browser

Dati aggiornati a ottobre 2021

Se non viene configurato alcun criterio relativo ai referrer, il browser utilizza il proprio criterio predefinito.

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 dal monitoraggio rigoroso e della Navigazione privata, le norme relative ai referrer meno restrittive no-referrer-when-downgrade, origin-when-cross-origin e unsafe-url vengono ignorate per le richieste cross-site, il che significa che il referrer viene sempre tagliato per le richieste cross-site, indipendentemente dalle norme del sito web.
Dispositivi periferici	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 Impedire il monitoraggio della prevenzione del monitoraggio.

Best practice per l'impostazione dei criteri relativi ai referrer

Obiettivo: impostare esplicitamente norme che rafforzano la privacy, ad esempio strict-origin-when-cross-origin(o un criterio più restrittivo).

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

• Come intestazione HTTP
• All'interno del tuo HTML
• Da JavaScript su richiesta.

Puoi impostare criteri diversi per pagine, richieste o elementi diversi.

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

1. Criterio a livello di elemento
2. Norme a livello di pagina
3. Predefinito del browser

Esempio:

index.html:

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

L'immagine viene richiesta con un criterio no-referrer-when-downgrade e tutte le altre richieste di sottorisorse di questa pagina seguono il criterio strict-origin-when-cross-origin.

Come si visualizzano le norme relative ai referrer?

securityheaders.com è utile per determinare le norme utilizzate da una pagina o un sito specifici.

Puoi anche usare gli strumenti per sviluppatori in Chrome, Edge o Firefox per controllare il criterio del referrer utilizzato per una richiesta specifica. Al momento della stesura di questo documento, Safari non mostra l'intestazione Referrer-Policy, ma mostra il Referer che è stato inviato.

Riquadro Rete di Chrome DevTools con una richiesta selezionata.

Quale criterio dovresti impostare per il tuo sito web?

Ti consigliamo vivamente di impostare esplicitamente norme che migliorano la privacy, come strict-origin-when-cross-origin (o un criterio più restrittivo).

Perché "esplicitamente"?

Se non imposti un criterio relativo ai referrer, verrà usato il criterio predefinito del browser: infatti, i siti web spesso fanno riferimento a quello predefinito del browser. Questo non è l'ideale, perché:

• I criteri predefiniti del browser variano a seconda del browser. Pertanto, se utilizzi le impostazioni predefinite del browser, il tuo sito non avrà un comportamento prevedibile da un browser all'altro.
• I browser stanno adottando valori predefiniti più rigidi come strict-origin-when-cross-origin e meccanismi come il taglio dei referrer per le richieste multiorigine. L'attivazione esplicita di un criterio di miglioramento della privacy prima della modifica delle impostazioni predefinite del browser ti consente di avere il controllo e di eseguire i test secondo le tue esigenze.

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

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

• Sicuro: se il tuo sito web utilizza HTTPS (in caso contrario, assegnagli una priorità), non vuoi che gli URL del tuo sito web diffondano nelle richieste non HTTPS. Poiché sono visibili a tutti gli utenti della rete, le fughe di dati esporranno gli utenti ad attacchi person in the middle. I criteri no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer e strict-origin risolvono il problema.
• Miglioramento della privacy: per una richiesta multiorigine, no-referrer-when-downgrade condivide l'URL completo, 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, vedrai 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, anche per le richieste della stessa origine. Se ti serve l'URL completo, strict-origin-when-cross-origin è un'opzione migliore.

Tutto questo significa che in genere strict-origin-when-cross-origin è una scelta sensata.

Esempio: impostazione di un criterio 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 valore più restrittivo) non soddisfa tutti i tuoi casi d'uso?

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

Esempio: criterio 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 il limite a document.referrer o all'intestazione Referer per le richieste cross-site. Visualizza i dettagli.

Esempio: norme a livello di richiesta

script.js:

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

Cos'altro dovresti prendere in considerazione?

Le norme dovrebbero dipendere dal 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 un criterio di protezione.

Avviso: i dati che potrebbero non sembrare sensibili per te possono essere sensibili per i tuoi utenti o semplicemente non essere quelli che vogliono o che si aspettano di condividere silenziosamente da più origini.

Best practice per le richieste in arrivo

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

Proteggere i dati degli utenti

L'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 dalle richieste multiorigine in arrivo presenta alcune limitazioni:

• Se non hai alcun controllo sull'implementazione dell'emittente della richiesta, non puoi fare ipotesi sull'intestazione Referer (e document.referrer) che ricevi. Chi ha inviato la richiesta potrebbe decidere di passare a un criterio no-referrer in qualsiasi momento o, più in generale, a una norma più restrittiva rispetto a prima. Questo significa che riceverai meno dati dal Referer rispetto a prima.
• I browser utilizzano sempre di più il criterio 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 arrivo se per il sito del mittente non sono stati impostati criteri.
• I browser potrebbero cambiare il modo in cui gestiscono Referer. Ad esempio, alcuni sviluppatori di browser potrebbero decidere di tagliare sempre i referrer alle origini nelle richieste di sottorisorse multiorigine, per proteggere la privacy degli utenti.
• L'intestazione Referer (e document.referrer) potrebbe contenere più dati del necessario. Ad esempio, potrebbe avere un URL completo quando vuoi sapere solo 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 arrivo.
• Il tuo sito non riceve più la parte dell'URL referrer di cui ha bisogno in una richiesta multiorigine. Questo accade quando l'emittente delle richieste modifica il proprio criterio o se non sono stati impostati criteri e il criterio predefinito del browser viene modificato (ad esempio in Chrome 85).

Per definire le alternative, innanzitutto analizza la parte del referrer che utilizzi.

Se ti serve solo l'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 forniscono il valore 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...)

• I parametri della richiesta potrebbero essere adatti al tuo caso d'uso, evitandoti 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 trasmettila come argomento in modo da non trasmettere qualsiasi informazione potenzialmente sensibile nei parametri URL.

Se non puoi utilizzare queste alternative:

• Verifica se puoi modificare i tuoi sistemi in modo che l'emittente delle richieste (ad esempio site-one.example) imposti esplicitamente le informazioni necessarie in un qualche tipo di configurazione.
  • Pro: più espliciti, più incentrati sulla tutela della privacy per gli utenti site-one.example, più a prova di futuro.
  • Svantaggio: lavoro potenzialmente maggiore da parte tua o per gli utenti del tuo sistema.
• Verifica se il sito che emette le richieste può accettare di impostare un criterio referrer di no-referrer-when-downgrade per elemento o per richiesta.
  • Contro: la tutela della privacy è potenzialmente inferiore per gli utenti site-one.example, potenzialmente non supportata in tutti i browser.

Protezione dalla contraffazione di richieste tra siti (CSRF)

Chi ha inviato una richiesta può decidere in qualsiasi momento di non inviare il referrer impostando un criterio no-referrer e un utente malintenzionato potrebbe persino eseguire lo spoofing del referrer.

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

Accedi ed esegui il debug

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

Se utilizzi solo l'origine, verifica se puoi utilizzare l'intestazione Origin come alternativa. Questo potrebbe fornirti le informazioni necessarie per eseguire il debug in modo più semplice e senza dover analizzare il referrer.

Pagamenti

I fornitori di servizi di pagamento potrebbero utilizzare l'intestazione Referer delle richieste in entrata per i controlli di sicurezza.

Ad esempio:

• L'utente fa clic sul 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 valore Referer di questa richiesta in base a un elenco di valori Referer consentiti configurato 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 per evitare alcuni attacchi. Tuttavia, l'intestazione Referer da sola non è una base affidabile per un controllo. Il sito richiedente, che sia un commerciante legittimo o meno, può impostare una norma no-referrer che rende le informazioni relative a Referer non disponibili per il fornitore di servizi di pagamento.

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

• Non aspettarti che Referer sia sempre presente. Se è presente, verificalo in base al numero minimo di dati 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. Prevedindo l'assenza di Referer o un valore Referer che corrisponde solo all'origine del sito richiedente, eviti errori che potrebbero derivare da ipotesi sul Referrer-Policy del commerciante.
• Se Referer non è presente o se è presente e il controllo dell'origine Referer di base ha esito positivo, puoi passare a un altro metodo di verifica più affidabile.

Per verificare i pagamenti in modo più affidabile, permetti al richiedente di eseguire l'hashing dei parametri della richiesta con 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 alla Referer quando un sito commerciante HTTP senza norma referrer reindirizza a un fornitore di servizi di pagamento HTTPS?

Nessun elemento Referer è visibile nella richiesta al fornitore di servizi di pagamento HTTPS perché la maggior parte dei browser utilizza i valori strict-origin-when-cross-origin o no-referrer-when-downgrade per impostazione predefinita quando un sito web non ha criteri impostati. La modifica di Chrome in un nuovo criterio predefinito non modificherà questo comportamento.

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

Conclusione

Le norme per i referrer sono un ottimo metodo per tutelare la privacy degli utenti.

Per scoprire di più sulle diverse tecniche per proteggere i tuoi utenti, consulta la nostra raccolta Protezione e sicurezza

Risorse

• Informazioni su "stesso sito" e "stessa origine"
• Una nuova intestazione di sicurezza: Norme dei referrer (2017)
• Criterio dei referrer su MDN
• Intestazione del referrer: problemi di privacy e sicurezza su MDN
• Modifica di Chrome: intent Blink per implementare
• Modifica di Chrome: intenzione di spedizione blink
• Modifica di Chrome: voce dello stato
• Modifica a Chrome: 85 beta blogpost
• Taglio del thread GitHub di taglio dei referrer: cosa fanno i diversi browser
• Specifiche dei criteri del referrer

Grazie mille per i contributi e il feedback a tutti i recensori, in particolare Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck e Kayce Basques.