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 "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'intestazione Referrer-Policy e referrer 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

Diagramma: referrer inviato in
      una richiesta.
Referrer-Policy e Referrer.

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.

Diagramma: referer inviato
      a seconda del criterio, per una richiesta cross-origin.
Referer inviato (e document.referrer) per una richiesta cross-origin, a seconda del criterio.

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 (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, 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.

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

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 e Sec-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 in document.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.

Risorse