Prima di iniziare:
- Se hai dubbi sulla differenza tra "sito" e "origine", consulta Informazioni su "stesso sito" e "stessa origine".
- Nell'intestazione
Referermanca una R a causa di un errore di ortografia originale nella specifica. L'intestazioneReferrer-Policyereferrerin JavaScript e il DOM sono stati digitati correttamente.
Riepilogo
- I browser si stanno evolvendo verso criteri per i referrer predefiniti che migliorano la privacy, per fornire un buon riserva quando per un sito web non sono impostati criteri.
- Chrome ha in programma di attivare gradualmente
strict-origin-when-cross-origincome criterio predefinito in 85. Ciò potrebbe influire sui casi d'uso basati sul valore referrer di un'altra origine. - Questa è la nuova impostazione predefinita, ma i siti web possono comunque scegliere un criterio a loro scelta.
- Per provare la modifica in Chrome, attiva il flag all'indirizzo
chrome://flags/#reduced-referrer-granularity. Puoi anche dare un'occhiata a questa demo per vedere la modifica in azione. - Oltre al criterio dei referrer, potrebbe cambiare il modo in cui i browser gestiscono i referrer, quindi tienilo d'occhio.
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 nell'intestazione
document.referrer della destinazione.
Le informazioni esatte che vengono inviate nell'intestazione Referer di una richiesta proveniente dal tuo sito dipendono
dall'intestazione Referrer-Policy che hai impostato.
Se non viene configurato alcun criterio, viene utilizzata l'impostazione predefinita del browser. I siti web spesso si basano sulle impostazioni predefinite del browser.
Per le navigazioni e gli iframe, i dati presenti nell'intestazione Referer sono accessibili anche tramite JavaScript utilizzando document.referrer.
Fino a poco tempo fa, no-referrer-when-downgrade era un criterio predefinito diffuso in tutti i browser. Tuttavia, ora molti browser si trovano in una fase di passaggio a impostazioni predefinite che migliorano la privacy.
Chrome prevede di cambiare il suo criterio predefinito da no-referrer-when-downgrade a strict-origin-when-cross-origin, a partire dalla versione 85.
Ciò significa che se non viene configurato 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 di tua scelta;
questa modifica avrà effetto solo sui siti web per cui non è impostato alcun criterio.
Che cosa significa questa modifica?
strict-origin-when-cross-origin offre una maggiore privacy. Con questo criterio, solo origin viene inviata nell'intestazione Referer delle richieste multiorigine.
In questo modo si evita la fuga di dati privati che potrebbero essere accessibili da altre parti dell'URL completo, come il percorso e la stringa di query.
Ad esempio:
Richiesta multiorigine, inviata da https://site-one.example/stuff/detail?tag=red a https://site-two.example/...:
- Con
no-referrer-when-downgrade: referrer: https://site-one.example/stuff/detail?tag=red. - Con
strict-origin-when-cross-origin: referrer: https://site-one.example/.
Cosa rimane invariato?
- Come nel caso di
no-referrer-when-downgrade,strict-origin-when-cross-originè sicuro: non è presente nessun referrer (intestazioneRefereredocument.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, impostalo come prioritario), gli URL del sito non verranno divulgati nelle richieste non HTTPS, perché chiunque sulla rete può vederle, esponendo così 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 della stessa origine, inviata da https://site-one.example/stuff/detail?tag=red a https://site-one.example/...:
- Con
strict-origin-when-cross-origin: referrer: https://site-one.example/stuff/detail?tag=red
Qual è l'impatto?
In base alle discussioni con altri browser e alla sperimentazione di Chrome eseguita in Chrome 84, l'interruzione visibile all'utente dovrebbe essere limitata.
Le analisi o il logging lato server che si basano sulla disponibilità dell'URL del referrer completo sono probabilmente influenzati dalla riduzione della granularità di queste informazioni.
Cosa occorre fare?
Chrome prevede di iniziare a implementare il nuovo criterio relativo al referrer predefinito nella versione 85 (luglio 2020 per la versione beta, agosto 2020 per la versione stabile). Controlla lo stato nella voce dello stato di Chrome.
Comprendi e rileva il cambiamento
Per comprendere in pratica cosa cambia la nuova impostazione predefinita, puoi guardare questa demo.
Puoi anche utilizzare questa demo per rilevare quale criterio viene applicato nell'istanza di Chrome in esecuzione.
Testa la modifica per capire se influenzerà il tuo sito
Puoi già provare la modifica a partire da Chrome 81: visita
chrome://flags/#reduced-referrer-granularity in Chrome e attiva il flag. Quando questo flag viene attivato, tutti i siti web senza un criterio utilizzeranno il nuovo valore predefinito di 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 il codebase 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 da un'altra origine per il tuo sito (più specificamente il percorso e/o la stringa di query) E questa origine utilizza il criterio relativo al referrer predefinito del browser (ovvero, non ha criteri impostati).
Se ciò influisce sul tuo sito, prendi in considerazione delle alternative
Se utilizzi il referrer per accedere al percorso completo o alla stringa di query per le richieste al tuo sito, hai alcune opzioni:
- Usa tecniche e intestazioni alternative come
OrigineSec-fetch-Siteper la protezione CSRF, il logging e altri casi d'uso. Consulta le norme relative a referrer e referrer: best practice. - Puoi allinearti ai partner in merito a una norma specifica, se necessario, e in modo trasparente per i tuoi utenti.
Il controllo dell'accesso: quando il referrer viene utilizzato dai siti web per concedere accesso specifico alle loro risorse ad altre origini, potrebbe essere questo il caso, anche se con la modifica di Chrome l'origine sarà comunque condivisa nell'intestazione
Referer(e indocument.referrer).
Tieni presente che la maggior parte dei browser si muove in una direzione simile per quanto riguarda il referrer (vedi i valori predefiniti del browser e le loro evoluzioni in Referer and Referrer-Policy: best practice.
Implementa norme esplicite per il miglioramento della privacy in tutto il sito
Quale Referer deve essere inviato nelle richieste originate dal tuo sito web, ad esempio quali criteri dovresti impostare per il tuo sito?
Anche tenendo presente la modifica di Chrome, è una buona idea impostare norme esplicite per il miglioramento della privacy, come strict-origin-when-cross-origin o più rigide, in questo momento.
In questo modo protegge gli utenti e il comportamento del sito web è più prevedibile sui vari browser. In gran parte, ti consente di avere maggiore controllo, invece di far sì che il tuo sito dipenda dalle impostazioni predefinite del browser.
Consulta Referrer e Referrer-Policy: best practice per i 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 precedente criterio relativo al referrer predefinito di no-referrer-when-downgrade negli ambienti aziendali. Ciò concede alle aziende più tempo
per testare e aggiornare le applicazioni.
Questo criterio verrà rimosso nella versione 88 di Chrome.
Invia feedback
Hai feedback da condividere o qualcosa da segnalare? Condividi il tuo feedback sull'intenzione di Chrome di spedire o twitta le tue domande all'indirizzo @maudnals.
Grazie mille per i contributi e i feedback a tutti i revisori, in particolare Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck e Kayce Basques.