Prima di iniziare:
- Se non hai ben chiaro la differenza tra "sito" e "origine", consulta la sezione Informazioni su "stesso sito" e "stessa origine".
- Nell'intestazione
Referermanca una R a causa di un errore ortografico originale nella specifica. L'intestazioneReferrer-Policyereferrerin JavaScript e nel DOM sono scritte correttamente.
Riepilogo
- I browser si stanno evolvendo verso policy relative al referrer predefinite che migliorano la privacy, per fornire un buon fallback quando un sito web non ha impostato alcuna policy.
- Chrome prevede di attivare gradualmente
strict-origin-when-cross-origincome criterio predefinito nella versione 85; ciò potrebbe influire sui casi d'uso che si basano sul valore del referrer di un'altra origine. - Questa è la nuova impostazione predefinita, ma i siti web possono comunque scegliere i criteri che preferiscono.
- 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 alle norme relative 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 facoltativa Referer, che indica l'URL di origine o della pagina web da cui è stata effettuata la richiesta. L'intestazione Referer-Policy definisce quali dati
sono disponibili nell'intestazione Referer e per la navigazione e gli iframe in document.referrer della destinazione.
Le informazioni esatte inviate nell'intestazione Referer di una richiesta dal tuo sito sono determinate
dall'intestazione Referrer-Policy che hai impostato.
Se non viene impostato alcun criterio, viene utilizzato il valore predefinito del browser. I siti web spesso rimandano all'impostazione predefinita 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
è stata una policy predefinita diffusa in tutti i browser. Ma ora molti browser si trovano in una fase di
transizione verso impostazioni predefinite che migliorano la privacy.
Chrome prevede di passare dalla policy predefinita no-referrer-when-downgrade a
strict-origin-when-cross-origin, a partire dalla versione 85.
Ciò significa che se non viene 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 comporta questo cambiamento?
strict-origin-when-cross-origin offre maggiore privacy. Con questa policy, nell'intestazione Referer delle richieste multiorigine viene inviata solo l'origine.
In questo modo si evitano fughe di dati privati che potrebbero essere accessibili da altre parti dell'URL completo, ad esempio 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: Referer: https://site-one.example/stuff/detail?tag=red. - Con
strict-origin-when-cross-origin: Referer: https://site-one.example/.
Cosa non cambierà?
- Come
no-referrer-when-downgrade,strict-origin-when-cross-originè sicuro: non è presente alcun 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 (se non lo fa, rendilo una priorità), gli URL del tuo sito web non verranno divulgati in richieste non HTTPS, perché chiunque sulla rete può vederli, quindi i tuoi utenti sarebbero esposti ad attacchi man-in-the-middle. - All'interno della stessa origine, il valore dell'intestazione
Refererè l'URL completo.
Ad esempio: Richiesta con stessa origine, 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 condotto in Chrome 84, si prevede che gli errori visibili agli utenti saranno limitati.
La registrazione o l'analisi lato server che si basa sulla disponibilità dell'URL referrer completo è probabilmente interessata 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). Vedi lo stato nella voce dello stato di Chrome.
Comprendere e rilevare la modifica
Per capire cosa comportano in pratica le nuove modifiche predefinite, puoi guardare 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 influirà 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. Quando questo flag è
attivato, tutti i siti web senza un criterio utilizzeranno il nuovo valore predefinito strict-origin-when-cross-origin.
Ora puoi controllare il comportamento del tuo sito web e del backend.
Un altro modo per rilevare l'impatto è verificare se il codebase del tuo sito web utilizza il referrer, tramite l'intestazione Referer delle richieste in entrata 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ù precisamente il percorso e/o la stringa di query) E questa origine utilizza le norme relative al referrer predefinite del browser (ovvero non è impostata alcuna norma).
Se questa modifica ha un impatto sul tuo sito, valuta 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
OrigineSec-fetch-Siteper la protezione CSRF, la registrazione e altri casi d'uso. Consulta Referer e Referrer-Policy: best practice. - Puoi allinearti con i partner a una norma specifica, se necessario e trasparente per i tuoi utenti.
Il controllo dell'accesso, quando il referrer viene utilizzato dai siti web per concedere l'accesso specifico alle proprie risorse
ad altre origini, potrebbe essere un caso di questo tipo, 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 i valori predefiniti del browser e la loro evoluzione in Referer e Referrer-Policy: best practice).
Implementare norme esplicite che migliorino la privacy su tutto il sito
Quale Referer deve essere inviato nelle richieste originate dal tuo sito web, ovvero quale policy devi impostare per il tuo sito?
Anche tenendo presente la modifica di Chrome, è consigliabile impostare una norma esplicita che migliori la privacy
come strict-origin-when-cross-origin o più restrittiva.
In questo modo, gli utenti sono protetti e il comportamento del tuo sito web è più prevedibile nei vari browser. Principalmente, ti offre il controllo, anziché far dipendere il tuo sito dalle impostazioni predefinite del browser.
Consulta Referrer e Referrer-Policy: best practice per informazioni dettagliate sull'impostazione di un criterio.
Informazioni su Chrome Enterprise
Il criterio aziendale di Chrome
ForceLegacyDefaultReferrerPolicy
è disponibile per gli amministratori IT che vogliono forzare il precedente criterio referrer predefinito 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 spedizione di Chrome o twitta le tue domande all'indirizzo @maudnals.
Un ringraziamento speciale per i contributi e i feedback a tutti i revisori, in particolare a Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck e Kayce Basques.