Prima di iniziare:
- Se hai dubbi sulla differenza tra "sito " e"origine ", consulta l'articolo Informazioni su "stessa origine" e "stessa origine".
- Nell'intestazione
Referer
manca una R, a causa di un errore ortografico originale nelle specifiche. L'intestazioneReferrer-Policy
ereferrer
in JavaScript e nel DOM sono scritti correttamente.
Riepilogo
- I browser si stanno evolvendo verso criteri relativi al referrer predefiniti che migliorano la privacy, per fornire un buon piano di riserva quando un sito web non ha impostato alcun criterio.
- Chrome prevede di attivare gradualmente
strict-origin-when-cross-origin
come criterio predefinito nella versione 85. Questo potrebbe influire sui casi d'uso che si basano sul valore del referrer di un'altra origine. - Si tratta del nuovo valore predefinito, ma i siti web possono comunque scegliere un criterio a loro scelta.
- Per provare la modifica in Chrome, attiva il flag in
chrome://flags/#reduced-referrer-granularity
. Puoi anche dare un'occhiata a questa demo per vedere la modifica in azione. - Oltre ai criteri relativi ai referrer, il modo in cui i browser gestiscono i referrer potrebbe cambiare, quindi tieni d'occhio la situazione.
Che cosa cambia e perché?
Le richieste HTTP possono includere l'intestazione Referer
facoltativa, che indica l'origine o l'URL della pagina web da cui è stata effettuata la richiesta. L'intestazione Referer-Policy
definisce quali dati vengono resi disponibili nell'intestazione Referer
e per la navigazione e gli iframe nel document.referrer
della destinazione.
Le informazioni esatte inviate nell'intestazione Referer
di una richiesta del tuo sito sono determinate dall'intestazione Referer
impostata.Referrer-Policy

Se non viene impostato alcun criterio, viene utilizzato quello predefinito del browser. I siti web spesso si basano sulle impostazioni predefinite del browser.
Per le navigazioni e gli iframe, è possibile accedere ai dati presenti nell'intestazione Referer
anche tramite JavaScript utilizzando document.referrer
.
Fino a poco tempo fa,
no-referrer-when-downgrade
è stato un criterio predefinito ampiamente diffuso nei browser. Tuttavia, ora molti browser sono in una fase di
passaggio a impostazioni predefinite che migliorano la privacy.
Chrome prevede di passare dal criterio predefinito no-referrer-when-downgrade
a
strict-origin-when-cross-origin
, a partire dalla versione 85.
Ciò significa che se non è impostato alcun criterio per il tuo sito web, Chrome utilizzerà
strict-origin-when-cross-origin
per impostazione predefinita. Tieni presente che puoi comunque impostare un criterio a tua scelta.
Questa modifica avrà effetto solo sui siti web per i quali non è stato impostato alcun criterio.
Che cosa significa questa modifica?
strict-origin-when-cross-origin
offre una maggiore privacy. Con questo criterio, solo l'origine viene inviata nell'intestazione Referer
delle richieste cross-origin.
In questo modo si evitano fughe di dati privati che potrebbero essere accessibili da altre parti dell'URL completo, come il percorso e la stringa di query.

Ad esempio:
Richiesta cross-origin, inviata da https://site-one.example/stuff/detail?tag=red a https://site-two.example/…:
- Con
no-referrer-when-downgrade
: Referer: https://site-one.example/stuff/detail?tag=red. - Con
strict-origin-when-cross-origin
: Referer: https://site-one.example/.
Cosa rimane invariato?
- Come
no-referrer-when-downgrade
,strict-origin-when-cross-origin
è sicuro: non è presente alcun referrer (intestazioneReferer
edocument.referrer
) quando la richiesta viene effettuata da un'origine HTTPS (sicura) a una HTTP (non sicura). In questo modo, se il tuo sito web utilizza HTTPS (in caso contrario, dai la priorità), gli URL del tuo sito web non verranno divulgati nelle richieste non HTTPS, perché chiunque sulla rete può vederli, il che esporrebbe i tuoi utenti ad attacchi man-in-the-middle. - All'interno della stessa origine, il valore dell'intestazione
Referer
è l'URL completo.
Ad esempio: Richiesta con origine uguale, inviata da https://site-one.example/stuff/detail?tag=red a https://site-one.example/…:
- Con
strict-origin-when-cross-origin
: Referer: https://site-one.example/stuff/detail?tag=red
Qual è l'impatto?
In base alle discussioni con altri browser e all'esperimento eseguito in Chrome 84, si prevede che i problemi visibili agli utenti siano limitati.
È probabile che la registrazione o l'analisi lato server che si basano sulla disponibilità dell'URL completo del referrer siano interessate da una granularità ridotta di queste informazioni.
Cosa occorre fare?
Chrome prevede di iniziare a implementare il nuovo criterio referrer predefinito nella versione 85 (luglio 2020 per la versione beta, agosto 2020 per la versione stabile). Visualizza lo stato nella voce dello stato di Chrome.
Comprendere e rilevare la variazione
Per capire cosa cambia nella pratica con le nuove impostazioni predefinite, puoi dare un'occhiata a questa demo.
Puoi utilizzare questa demo anche per rilevare il criterio applicato nell'istanza di Chrome in esecuzione.
Prova la modifica e scopri se avrà un impatto sul tuo sito
Puoi già provare la modifica a partire da Chrome 81: visita
chrome://flags/#reduced-referrer-granularity
in Chrome e attiva il flag. Se questo flag viene attivato, tutti i siti web senza criteri utilizzeranno il nuovo valore predefinito strict-origin-when-cross-origin
.

Ora puoi controllare il comportamento del tuo sito web e del tuo backend.
Un'altra cosa da fare per rilevare l'impatto è verificare se la base di codice del tuo sito web utilizza il referrer tramite l'intestazione Referer
delle richieste in arrivo sul server o da document.referrer
in JavaScript.
Alcune funzionalità del tuo sito potrebbero non funzionare o comportarsi in modo diverso se utilizzi il referrer delle richieste provenienti da un'altra origine al tuo sito (più specificamente il percorso e/o la stringa di query) E se questa origine utilizza le norme relative al referrer predefinite del browser (ovvero non sono impostate norme).
Se questo influisce sul tuo sito, valuta le alternative
Se utilizzi il referrer per accedere al percorso completo o alla stringa di query per le richieste al tuo sito, hai a disposizione alcune opzioni:
- Utilizza tecniche e intestazioni alternative come
Origin
eSec-fetch-Site
per la protezione CSRF, il logging e altri casi d'uso. Consulta Referer e Referrer-Policy: best practice. - Puoi allinearti ai partner su un criterio specifico, se necessario e in modo trasparente per gli utenti.
Il controllo dell'accesso, quando il referrer viene utilizzato dai siti web per concedere accesso specifico alle proprie risorse ad altre origini, potrebbe essere un caso del genere, anche se con la modifica di Chrome l'origine verrà comunque condivisa nell'intestazione
Referer
(e indocument.referrer
).
Tieni presente che la maggior parte dei browser si sta muovendo in una direzione simile per quanto riguarda il referrer (consulta le impostazioni predefinite del browser e le relative evoluzioni in Referer e Referrer-Policy: best practice).
Implementa norme esplicite che promuovano la privacy sul tuo sito
Quale Referer
deve essere inviato nelle richieste originate dal tuo sito web, ovvero quali norme devi impostare per il tuo sito?
Anche tenendo conto del cambiamento di Chrome, è buona norma impostare norme esplicite che migliorano la privacy come strict-origin-when-cross-origin
o più severe.
In questo modo, proteggi gli utenti e il tuo sito web si comporta in modo più prevedibile su tutti i browser. Soprattutto, ti offre il controllo, anziché fare in modo che il tuo sito dipenda dalle impostazioni predefinite del browser.
Consulta Referrer e Referrer-Policy: best practice per dettagli sull'impostazione di un criterio.
Informazioni su Chrome Enterprise
Il criterio di Chrome Enterprise
ForceLegacyDefaultReferrerPolicy
è disponibile per gli amministratori IT che vogliono forzare il criterio referrer predefinito precedente di
no-referrer-when-downgrade
negli ambienti aziendali. Ciò consente alle aziende di avere più tempo per testare e aggiornare le proprie applicazioni.
Questo criterio verrà rimosso nella versione 88 di Chrome.
Invia feedback
Hai un feedback da condividere o qualcosa da segnalare? Condividi il tuo feedback sull'intenzione di rilasciare Chrome o invia un tweet con le tue domande all'indirizzo @maudnals.
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.