Best practice relative alle norme sui referrer e sui referrer

Maud Nalpas

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

Riepilogo

• La perdita imprevista di informazioni multiorigine danneggia la privacy degli utenti web. Un criterio referrer protettivo può aiutarti.
• Valuta la possibilità di impostare un criterio referrer di strict-origin-when-cross-origin. Conserva la maggior parte dell'utilità del referrer, mitigando il rischio di perdita di dati tra origini diverse.
• Non utilizzare i referrer per la protezione da attacchi di tipo richiesta cross-site (CSRF). Utilizza token CSRF e altre intestazioni come ulteriore livello di sicurezza.

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.

Nel seguente esempio, l'intestazione Referer include l'URL completo della pagina su 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 necessarie a 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 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 diverse, può mettere a rischio la privacy degli utenti e creare rischi per la sicurezza:

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

L'URL n. 6 è un URL di funzionalità. Se questa email viene ricevuta da un'altra persona, un malintenzionato può prendere il controllo dell'account dell'utente.

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

Quali norme sono disponibili e in cosa differiscono?

Puoi selezionare uno degli otto criteri. A seconda delle norme, i dati disponibili nell'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

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

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

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

Ecco alcuni aspetti da tenere presenti quando imposti una policy sui referrer:

• Tutte le norme che tengono conto dello schema (HTTPS anziché 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 dati da un'origine criptata a una non criptata, come nelle richieste HTTPS → HTTP. Una richiesta HTTP → HTTP non è crittografata, quindi non è previsto alcun downgrade.
• Se una richiesta è stessa origine, significa che lo schema (HTTPS o HTTP) è lo stesso, quindi non si verifica un downgrade della sicurezza.

Criteri referrer predefiniti nei browser

A partire da ottobre 2021

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

Best practice per l'impostazione del criterio referrer

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

• Come intestazione HTTP
• All'interno del tuo codice HTML
• Da JavaScript in base alla richiesta

Puoi impostare norme 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 il criterio effettivo di un elemento è il seguente:

1. Policy 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 di questa pagina seguono il criterio strict-origin-when-cross-origin.

Come visualizzare le norme relative al referrer

securityheaders.com è utile per determinare quale policy utilizza un sito o una pagina specifica.

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

Quale norma dovresti impostare per il tuo sito web?

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

Perché "esplicitamente"?

Se non imposti una policy referrer, verrà utilizzata quella predefinita del browser. Infatti, i siti web spesso rimandano alla policy predefinita del browser. Tuttavia, questa soluzione non è ideale perché:

• Browser diversi hanno criteri predefiniti diversi, quindi se ti affidi alle impostazioni predefinite del browser, il tuo sito non si comporterà in modo prevedibile su tutti i browser.
• I browser stanno adottando impostazioni predefinite più rigorose, come strict-origin-when-cross-origin, e meccanismi come il taglio del referrer per le richieste multiorigine. L'attivazione esplicita di una norma che migliora la privacy prima della modifica delle impostazioni predefinite del browser ti offre il controllo e ti aiuta a eseguire i test come preferisci.

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

Hai bisogno di una policy sicura, che migliori la privacy e sia utile. Il significato di "utile" dipende da ciò che vuoi ottenere dal referrer:

• Sicuro: 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 perdite esporrebbero 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. 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 ti serve l'URL completo, strict-origin-when-cross-origin è una scelta migliore.

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

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

index.html:

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

oppure 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 una versione più restrittiva) 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 tra siti. Visualizza i dettagli.

Esempio: policy a livello di richiesta

script.js:

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

Cos'altro dovresti considerare?

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 identificativi o sensibili, imposta un criterio di protezione.

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

Il 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 entrata presenta alcune limitazioni:

• Se non hai il controllo dell'implementazione del mittente della richiesta, non puoi fare ipotesi sull'intestazione Referer (e document.referrer) che ricevi. L'emittente della richiesta potrebbe decidere di passare a un criterio no-referrer in qualsiasi momento o, più in generale, a un criterio più rigoroso di quello utilizzato in precedenza. Ciò significa che ricevi meno dati da Referer rispetto a prima.
• I browser utilizzano sempre più spesso il criterio referrer 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 mittente non ha impostato alcun criterio.
• I browser potrebbero modificare 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 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 referrer di cui ha bisogno in una richiesta multiorigine. Ciò si verifica quando l'emittente della richiesta modifica le proprie norme o quando non ha impostato norme e le norme predefinite del browser sono cambiate (come in Chrome 85).

Per definire le alternative, analizza innanzitutto la parte del referrer che 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, le intestazioni come Origin e Sec-Fetch-Site forniscono il 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…)

• I parametri della richiesta potrebbero risolvere il 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 trasmettila come argomento, in modo che non vengano trasmesse informazioni potenzialmente sensibili nei parametri URL.

Se non puoi utilizzare queste alternative:

• Verifica se puoi modificare i tuoi sistemi in modo che l'emittente della richiesta (ad esempio site-one.example) imposti esplicitamente le informazioni di cui hai bisogno in un tipo di configurazione.
  • Pro: più esplicito, più rispettoso della privacy per gli utenti site-one.example, più orientato al futuro.
  • Contro: 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 per elemento o per richiesta di Referrer-Policy pari a no-referrer-when-downgrade.
  • Svantaggio: potenzialmente meno rispettoso della privacy per gli utenti di site-one.example, potenzialmente non supportato in tutti i browser.

Protezione da richiesta cross-site (CSRF)

Un emittente di richieste può sempre decidere di non inviare il referrer impostando un criterio no-referrer e un malintenzionato potrebbe persino falsificare 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.

Registrazione 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 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 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 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 sia o meno un commerciante legittimo, può impostare un criterio no-referrer che rende le informazioni Referer non disponibili per il fornitore di servizi di pagamento.

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

• Non aspettarti che Referer sia sempre presente. Se è presente, controllalo solo rispetto 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 prevedi che non sia presente alcun Referer o che il valore di Referer sia solo l'origine del sito richiedente, eviti errori che potrebbero derivare da ipotesi sul Referrer-Policy del commerciante.
• Se il Referer non è presente o se è presente e il controllo di base dell'origine del Referer va a buon fine, puoi passare a un altro metodo di verifica più affidabile.

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

Che cosa succede al Referer quando un sito commerciante HTTP senza policy 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 impostato criteri. La modifica di Chrome a un nuovo criterio predefinito non cambierà questo comportamento.

Conclusione

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

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"
• Una nuova intestazione di sicurezza: Referrer Policy (2017)
• Referrer-Policy su MDN
• Referer header: privacy and security concerns on MDN
• Modifica di Chrome: intenzione di implementazione di Blink
• Modifica di Chrome: intenzione di implementare Blink
• Modifica di Chrome: voce di stato
• Modifica di Chrome: post del blog sulla versione beta 85
• Thread di GitHub sul troncamento del referrer: cosa fanno i diversi browser
• Specifiche di Referrer-Policy

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