Best practice relative alle norme sui referrer e sui referrer

Maud Nalpas

Questa pagina illustra alcune best practice per impostare Referrer-Policy e utilizzare il referrer nelle richieste in entrata.

Riepilogo

• La fuga imprevista di informazioni tra origini danneggia la privacy degli utenti web. Può essere utile un criterio referrer protettivo.
• Valuta la possibilità di impostare un criterio referrer pari a strict-origin-when-cross-origin. Conserva gran parte dell'utilità del referrer, riducendo al contempo il rischio di fuga di dati tra origini.
• Non utilizzare i referrer per la protezione da CSRF (Cross-Site Request Forgery). Utilizza invece token CSRF e altre intestazioni come ulteriore livello di sicurezza.

Guida introduttiva alle norme sui referrer e sui referrer

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 in site-one da cui è stata effettuata la richiesta.

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 di cui una pagina ha bisogno.

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 su site-two.example proviene da social-network.example. Tuttavia, quando l'URL completo, inclusi il percorso e la stringa di query, viene inviato nel Referer tra le origini, può mettere in pericolo la privacy degli utenti e creare rischi per la sicurezza:

Gli URL da 1 a 5 contengono informazioni private e, a volte, sensibili o che consentono l'identificazione. La loro fuga silenziosa tra le origini può compromettere la privacy degli utenti web.

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

Per limitare i dati referrer resi disponibili per le richieste provenienti dal tuo sito, puoi impostare un criterio 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 document.referrer) possono essere:

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

Alcuni criteri sono progettati per comportarsi in modo diverso a seconda del contesto: richiesta multiorigine o stessa origine, se la destinazione della richiesta è sicuro quanto l'origine o entrambi. Questa opzione è 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 i criteri relativi ai referrer limitano i dati URL disponibili dall'intestazione Referer e da document.referrer:

MDN fornisce un elenco completo di norme ed esempi di comportamento.

Ecco alcuni aspetti da tenere presenti quando imposti un criterio per il referrer:

• Tutti i criteri che prendono in considerazione lo 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 nello stesso modo delle richieste da un'origine HTTPS a un'altra origine HTTPS, anche se HTTP è meno sicuro. Questo accade perché per questi criteri ciò che conta è se viene eseguito un downgrade della sicurezza, ovvero se la richiesta può esporre i dati da un'origine criptata a un'origine non criptata, come nelle richieste HTTPS → HTTP. Una richiesta HTTP → HTTP è completamente unencrypted, quindi non è previsto alcun downgrade.
• Se una richiesta è stessa origine, significa che lo schema (HTTPS o HTTP) è uguale, quindi non si verifica alcun downgrade della sicurezza.

Criteri referrer predefiniti nei browser

Dati aggiornati a ottobre 2021

Se non viene configurato alcun criterio per il referrer, il browser utilizza il criterio predefinito.

Best practice per l'impostazione delle norme relative ai referrer

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

• Come intestazione HTTP
• All'interno del codice 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 di priorità per determinare il criterio efficace di un elemento è il seguente:

1. Criterio a livello di elemento
2. Norme a livello di pagina
3. Valore 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 risorse secondarie da questa pagina rispettano il criterio strict-origin-when-cross-origin.

Come visualizzare le norme relative ai referrer?

securityheaders.com è utile per determinare il criterio utilizzato da una pagina o un sito specifico.

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

Quale norma dovresti impostare per il tuo sito web?

Ti consigliamo vivamente di impostare esplicitamente un criterio che migliori la privacy, ad esempiostrict-origin-when-cross-origin (o più restrittivo).

Perché "esplicitamente"?

Se non imposti un criterio referrer, verrà utilizzato quello predefinito del browser. Infatti, i siti web spesso fanno riferimento a quello predefinito del browser. Questo, però, non è l'ideale, perché:

• Browser diversi hanno criteri predefiniti diversi, pertanto se ti basi su quelli predefiniti del browser, il tuo sito non avrà un comportamento prevedibile su tutti i browser.
• I browser stanno adottando valori predefiniti più rigidi come strict-origin-when-cross-origin e meccanismi come il trimming del referrer per le richieste cross-origin. L'attivazione esplicita di norme per il miglioramento della privacy prima della modifica delle impostazioni predefinite del browser ti offre il controllo e ti aiuta a eseguire i test secondo le tue esigenze.

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

Devi avere delle norme sicure, che tutelano la privacy e sono utili. Il significato di "utile" dipende da ciò che si vuole ottenere dal referrer:

• Sicuro: se il tuo sito web utilizza HTTPS (in caso contrario, impostalo come priorità), evita che gli URL del tuo sito web vengano divulgati nelle richieste non HTTPS. Dal momento che chiunque sulla rete può vederle, le fughe di dati espongono i tuoi utenti ad attacchi man in the middle. I criteri 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. Ti restano 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 ciò significa che strict-origin-when-cross-origin è in genere una scelta sensata.

Esempio: impostazione di un criterio strict-origin-when-cross-origin

index.html:

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

Sul 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 un criterio di protezione come strict-origin-when-cross-origin per il tuo sito web e, se necessario, criteri più permissivi per richieste o elementi HTML specifici.

Esempio: criteri 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: criterio a livello di richiesta

script.js:

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

Quali altri aspetti è opportuno prendere in considerazione?

Le norme devono 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 di identificazione o sensibili, imposta un criterio di protezione.

Best practice per le richieste in arrivo

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

Proteggere i dati degli utenti

Il token Referer può contenere dati privati, personali o che consentono l'identificazione personale, quindi assicurati di trattarlo come tale.

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

L'utilizzo del referrer dalle richieste cross-origin in entrata presenta alcune limitazioni:

• Se non hai alcun controllo sull'implementazione dell'emittente della richiesta, non puoi fare supposizioni sull'intestazione Referer (e document.referrer) che ricevi. L'autore della richiesta potrebbe decidere di passare a un criterio no-referrer in qualsiasi momento o, più in generale, a un criterio più rigoroso rispetto a quello utilizzato in precedenza. Ciò significa che ricevi meno dati da Referer rispetto a prima.
• Per impostazione predefinita, i browser usano sempre più spesso la norma Referrer-Policy strict-origin-when-cross-origin. Ciò significa che ora potresti ricevere solo l'origine, anziché un URL referrer completo, nelle richieste cross-origin in arrivo, se il sito mittente non ha impostato alcun criterio.
• 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 risorse secondarie cross-origin per proteggere la privacy degli utenti.
• L'intestazione Referer (e document.referrer) potrebbe contenere più dati di quanto necessario. Ad esempio, potrebbe avere un URL completo quando vuoi solo sapere se la richiesta è cross-origin.

Alternative a Referer

Potresti dover prendere in considerazione delle alternative se:

• Una funzionalità essenziale del tuo sito utilizza l'URL referrer delle richieste cross-origin in arrivo.
• Il tuo sito non riceve più la parte dell'URL referrer di cui ha bisogno in una richiesta cross-origin. Questo accade quando l'emittente della richiesta modifica il proprio criterio o quando non ha impostato alcun criterio e il criterio predefinito del browser è cambiato (ad esempio in Chrome 85).

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

Se ti serve solo l'origine

• Se utilizzi il referrer in uno script con 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 è cross-origin, 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, evitando così 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 essere un'alternativa. Estrai solo la sezione del percorso dell'URL e trasmettela come argomento, in modo che le informazioni potenzialmente sensibili nei parametri URL non vengano trasmesse.

Se non puoi utilizzare queste alternative:

• Controlla se puoi modificare i tuoi sistemi in modo che l'autore della richiesta (ad esempio, site-one.example) imposti in modo esplicito le informazioni di cui hai bisogno in qualche tipo di configurazione.
  • Vantaggio: più esplicito, più rispettoso della privacy per gli utenti site-one.example, più adatto al futuro.
  • Svantaggio: potenzialmente più lavoro da parte tua o per gli utenti del tuo sistema.
• Verifica se il sito che invia le richieste può accettare di impostare un criterio per i referrer di no-referrer-when-downgrade per elemento o per richiesta.
  • Svantaggio: potenzialmente meno rispettoso della privacy per gli utenti site-one.example, potenzialmente non supportato in tutti i browser.

Protezione da CSRF (Cross-Site Request Forgery)

Un mittente della richiesta può sempre decidere di non inviare il referrer impostando un criterio no-referrer; un utente malintenzionato potrebbe persino simulare il referrer.

Utilizza i token CSRF come protezione principale. Per una protezione aggiuntiva, 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 trovarsi nel Referer.

Se utilizzi solo l'origine, controlla se puoi utilizzare l'intestazione Origin come alternativa. In questo modo, potresti ottenere le informazioni di cui hai bisogno per il debugging 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 valore Referer di questa richiesta con un elenco di valori Referer consentiti configurato dai commercianti. Se non corrisponde a nessuna voce nell'elenco, payment-provider.example rifiuta la richiesta. Se corrisponde, l'utente può procedere alla transazione.

Best practice per i controlli di sicurezza del flusso di pagamento

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

Dare un'occhiata alla Referer potrebbe aiutare i fornitori di servizi di pagamento a individuare gli utenti 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, controlla solo i dati minimi che può includere, ovvero l'origine.
  • Quando imposti l'elenco di 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 prevedi di non avere Referer o un valore Referer che sia solo l'origine del sito che effettua la richiesta, eviti gli errori che potrebbero derivare da supposizioni sul Referer del commerciante.
• Se il valore Referer non è presente o se è presente e il controllo di base dell'origine Referer è andato a buon fine, puoi passare a un altro metodo di verifica più affidabile.

Per verificare i pagamenti in modo più affidabile, consenti all'utente che effettua la richiesta di eseguire l'hash 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.

Cosa succede al Referer quando un sito del commerciante HTTP senza criteri per i 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 criteri impostati. Il passaggio di Chrome a un nuovo criterio predefinito non cambierà questo comportamento.

Conclusione

Un criterio di referrer protettivo è un ottimo modo per offrire agli utenti una maggiore privacy.

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

Risorse

• Informazioni su "stessa origine" e "stessa origine"
• Una nuova intestazione di sicurezza: Referrer Policy (2017)
• Referrer-Policy su MDN
• Intestazione Referrer: problemi di privacy e sicurezza su MDN
• Modifica di Chrome: intenzione di implementare Blink
• Modifica di Chrome: intenzione di consegnare lampeggiamento
• Modifica di Chrome: voce di stato
• Modifica di Chrome: post del blog sulla versione beta 85
• Thread di GitHub sul taglio del referrer: cosa fanno i diversi browser
• Specifiche Referrer-Policy

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