Nuovo criterio Referrer-Policy predefinito per Chrome: rigoroso-origin-quando-cross-origin

Maud Nalpas
Maud Nalpas

Prima di iniziare:

  • Se hai dubbi sulla differenza tra "site " e"origin ", leggi l'articolo Informazioni su "stesso sito" e "stesso-origine".
  • Nell'intestazione Referer manca una R a causa di un errore di ortografia originale nelle specifiche. L'intestazione Referrer-Policy e referrer in JavaScript e nel DOM sono stati digitati correttamente.

Riepilogo

  • I browser si stanno evolvendo verso criteri per i referrer predefiniti per la privacy, per fornire un buon fallback quando un sito web non ha criteri impostati.
  • Chrome prevede di attivare gradualmente strict-origin-when-cross-origin come criterio predefinito nella versione 85. Ciò potrebbe influire sui casi d'uso che utilizzano il valore del referrer da un'altra origine.
  • Questa è la nuova impostazione predefinita, ma i siti web possono comunque scegliere il criterio di loro scelta.
  • Per provare la modifica in Chrome, attiva il flag all'indirizzo chrome://flags/#reduced-referrer-granularity. Puoi anche consultare questa demo per vedere la modifica in azione.
  • Oltre al criterio relativo ai referrer, il modo in cui i browser gestiscono i referrer potrebbe cambiare, 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 in una richiesta dal tuo sito sono determinate dall'intestazione Referrer-Policy che hai impostato.

Diagramma: il referrer è stato inviato in una richiesta.
Criteri referrer e referrer.

Se non viene configurato alcun criterio, viene usato l'impostazione predefinita del browser. I siti web spesso fanno riferimento all'impostazione predefinita del browser.

Per navigazioni e iframe, i dati presenti nell'intestazione Referer sono accessibili anche tramite JavaScript utilizzando document.referrer.

Fino a poco tempo fa, no-referrer-when-downgrade è stato un criterio predefinito diffuso in tutti i browser. Tuttavia, ora molti browser stanno per passare a un numero maggiore di 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 a tua scelta; questa modifica avrà effetto solo sui siti web in cui non sono stati impostati criteri.

Che cosa significa questo cambiamento?

strict-origin-when-cross-origin offre maggiore privacy. Con questo criterio, solo l'origine viene inviata nell'intestazione Referer delle richieste multiorigine.

Questo impedisce fughe di dati privati che potrebbero essere accessibili da altre parti dell'URL completo, come il percorso e la stringa di query.

Diagramma: il referrer viene inviato
      a seconda del criterio, per una richiesta multiorigine.
Il referrer ha inviato (e document.referrer) per una richiesta multiorigine, in base al criterio.

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/.

Che cosa rimane invariato?

  • Come no-referrer-when-downgrade, strict-origin-when-cross-origin è protetto: non è presente alcun referrer (intestazione Referer e document.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 una priorità), gli URL del tuo sito web non verranno divulgati nelle richieste non HTTPS, perché chiunque sulla rete può visualizzarli, esponendo 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 all'esperimento di Chrome eseguito in Chrome 84, le interruzioni visibili agli utenti dovrebbero essere limitate.

Il logging o le analisi lato server che si basano sull'URL referrer completo disponibile potrebbero essere interessati dalla ridotta 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 sullo stato di Chrome.

Comprendere e rilevare la modifica

Per capire cosa cambia nella pratica il nuovo valore predefinito, puoi consultare questa demo.

Puoi anche utilizzare questa demo per rilevare quale criterio viene applicato nell'istanza di Chrome in esecuzione.

Testa la modifica e scopri se inciderà 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 è attivato, tutti i siti web senza un criterio useranno la nuova impostazione predefinita di strict-origin-when-cross-origin.

Screenshot di Chrome: come
      attivare il flag chrome://flags/#reduced-referrer-granularity.
Abilitazione del flag in corso.

Ora puoi controllare il comportamento del tuo sito web e del tuo backend.

Un'altra cosa da fare per rilevare l'impatto è controllare 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 al tuo sito (in particolare il percorso e/o la stringa di query) E questa origine utilizza i criteri relativi ai referrer predefiniti del browser (ovvero non ha criteri impostati).

Se questo ha un impatto 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 a disposizione alcune opzioni:

  • Utilizza tecniche e intestazioni alternative come Origin e Sec-fetch-Site per la protezione, il logging e altri casi d'uso CSRF. Consulta le norme per i referral e i referrer: best practice.
  • Se necessario, puoi allinearti ai partner che hanno stabilito una norma specifica in modo trasparente per i tuoi utenti. Il controllo dell'accesso, quando il referrer viene utilizzato da siti web per concedere ad altre origini l'accesso specifico alle proprie risorse, potrebbe essere sufficiente, sebbene con la modifica di Chrome l'origine continuerà a essere condivisa nell'intestazione Referer (e in document.referrer).

Tieni presente che la maggior parte dei browser si sposta in una direzione simile per quanto riguarda il referrer (vedi i valori predefiniti del browser e la loro evoluzione in Referer and Referrer-Policy: best practice).

Implementare 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 quale norma dovresti impostare per il tuo sito?

Anche tenendo in mente il cambiamento di Chrome, è consigliabile impostare norme esplicite per il miglioramento della privacy, come strict-origin-when-cross-origin o più restrittive per il momento.

In questo modo, puoi proteggere gli utenti e rendere il tuo sito web più prevedibile nei vari browser. Ti consente per lo più di avere il controllo, invece di lasciare 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 proprie applicazioni.

Questo criterio verrà rimosso nella versione 88 di Chrome.

Invia feedback

Hai feedback da condividere o qualcosa da segnalare? Condividi un 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 recensori, in particolare Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck e Kayce Basques.

Risorse