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.
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.
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:
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
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
estrict-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
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:
- Criterio a livello di elemento
- Norme a livello di pagina
- 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.
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
estrict-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
estrict-origin
condividono solo l'origine, mentreno-referrer
non condivide nulla. In questo modo, vedraistrict-origin-when-cross-origin
,strict-origin
eno-referrer
come opzioni per migliorare la privacy. - Utile:
no-referrer
estrict-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.
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
(edocument.referrer
) che ricevi. Chi ha inviato la richiesta potrebbe decidere di passare a un criteriono-referrer
in qualsiasi momento o, più in generale, a una norma più restrittiva rispetto a prima. Questo significa che riceverai meno dati dalReferer
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
(edocument.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
eSec-Fetch-Site
forniscono il valoreOrigin
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.
- Pro: più espliciti, più incentrati sulla tutela della privacy per gli utenti
- 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.
- Contro: la tutela della privacy è potenzialmente inferiore per gli utenti
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 apayment-provider.example
per gestire la transazione.payment-provider.example
confronta il valoreReferer
di questa richiesta in base a un elenco di valoriReferer
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 peronline-shop.example
devono essereonline-shop.example
, nononline-shop.example/cart/checkout
. Prevedindo l'assenza diReferer
o un valoreReferer
che corrisponde solo all'origine del sito richiedente, eviti errori che potrebbero derivare da ipotesi sulReferrer-Policy
del commerciante.
- Quando imposti l'elenco dei valori
- Se
Referer
non è presente o se è presente e il controllo dell'origineReferer
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.
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.