Cos'è Referrer-Policy?

L'header HTTP Referrer-Policy determina quante informazioni sulla pagina di origine vengono incluse nell'header di richiesta Referer quando un utente naviga dal tuo sito a un altro, o quando la tua pagina carica risorse da fonti esterne. Ogni volta che qualcuno clicca su un link, ogni volta che un'immagine viene caricata da un CDN, ogni volta che uno script di analisi parte, il browser potenzialmente invia l'URL della pagina corrente al server di destinazione. Con Referrer-Policy controlli quanto di quell'URL condividi.

(Una breve nota sull'ortografia: l'header HTTP è scritto come "Referer" con una sola "r" a causa di un errore di battitura nella specifica HTTP originale dei primi anni '90. L'header della policy usa l'ortografia corretta "Referrer" con due r. Entrambe le ortografie sono intenzionali.)

Cosa contiene l'header Referer e quando viene inviato

Per impostazione predefinita (senza Referrer-Policy), il browser invia l'URL completo della pagina corrente come header Referer nella maggior parte delle richieste in uscita. Include:

• Navigazione: quando un utente clicca su un link verso un altro sito, la destinazione riceve l'URL completo della pagina da cui è arrivato.
• Richieste di subresource: quando la tua pagina carica immagini, script, fogli di stile o font da domini esterni, ogni richiesta include l'header Referer.
• Invii di moduli: quando un modulo invia dati a un URL esterno, l'header Referer viene inviato con esso.
• Richieste AJAX e Fetch: anche le chiamate API a servizi esterni includono di default l'header Referer.

Supponi che un visitatore si trovi su questo URL del tuo sito WordPress:

https://tuosito.com/membri/dashboard?session=abc123&plan=premium

Se quella pagina contiene un'immagine incorporata da un provider di analisi esterno o da una rete pubblicitaria, il server di quel provider riceve l'URL completo nell'header Referer, inclusi i parametri di query con il token di sessione e le informazioni sul piano. Questa è la preoccupazione sulla privacy che Referrer-Policy affronta.

Tutti i valori Referrer-Policy spiegati

L'header Referrer-Policy supporta otto valori diversi. Ognuno definisce un diverso livello di condivisione delle informazioni:

• no-referrer: non inviare mai l'header Referer. La destinazione non riceve alcuna informazione su da dove proviene la richiesta. È l'opzione più rispettosa della privacy, ma può rompere funzionalità che dipendono dai dati referrer (alcune protezioni CSRF, ad esempio).
• no-referrer-when-downgrade: invia l'URL completo, ma omette il Referer quando si naviga da HTTPS a HTTP (un "downgrade"). Per anni è stato il default dei browser. Protegge dalla fuga di URL quando si lascia un contesto sicuro, ma condivide tutto nella navigazione HTTPS a HTTPS.
• origin: invia solo l'origin (schema, host e porta), ma non il path o la query string. Quindi https://tuosito.com/membri/dashboard?session=abc123 diventa solo https://tuosito.com/. La destinazione sa da quale sito è arrivato il visitatore, ma non da quale pagina specifica.
• origin-when-cross-origin: invia l'URL completo per richieste same-origin (link all'interno del tuo sito), ma solo l'origin per richieste cross-origin. Questo dà alle tue analytics e strumenti interni dati referrer completi, limitando ciò che vedono i siti esterni.
• same-origin: invia l'URL completo solo per richieste same-origin. Per richieste cross-origin non viene inviato alcun Referer. È molto privato per la navigazione esterna, ma significa che i servizi esterni non ricevono dati referrer.
• strict-origin: invia solo l'origin (come con origin), ma omette completamente il Referer in caso di downgrade HTTPS a HTTP. Combina la privacy di origin con la protezione del downgrade di no-referrer-when-downgrade.
• strict-origin-when-cross-origin: il valore più consigliato. Invia l'URL completo per richieste same-origin, solo l'origin per richieste cross-origin HTTPS a HTTPS, e nulla nei downgrade HTTPS a HTTP. È il miglior equilibrio tra privacy, sicurezza e funzionalità. I browser moderni (Chrome 85+, Firefox 87+) lo hanno introdotto come default, anche quando non è presente alcun header Referrer-Policy.
• unsafe-url: invia sempre l'URL completo, indipendentemente da destinazione o contesto di sicurezza. Non si chiama "unsafe" per niente. Invia parametri di query, path e tutto il resto, anche a destinazioni HTTP. Non usarlo mai, a meno che tu non abbia un'esigenza molto specifica e comprenda i rischi.

Implicazioni sulla privacy dell'header Referer

L'header Referer è una preoccupazione importante per la privacy che molti proprietari di siti trascurano. Considera quali informazioni possono contenere i tuoi URL:

• Query di ricerca: se il tuo sito ha una funzione di ricerca, l'URL può apparire come /search?q=argomento+sensibile+salute. Ogni risorsa esterna caricata sulla pagina dei risultati di ricerca riceve quella query.
• Identificatori utente: URL come /user/maria-rossi/profile o /order/12345 rivelano informazioni su utenti e ordini a terze parti.
• Token e dati di sessione: alcune applicazioni mettono token negli URL per reset password, conferme email o link di condivisione. Questi possono fuoriuscire tramite l'header Referer.
• Struttura URL interna: anche solo la struttura del path (/wp-admin/, /solo-membri/, /dashboard-interno/) rivela informazioni sull'architettura del tuo sito.

Ogni risorsa esterna sulla tua pagina è un potenziale destinatario di queste informazioni: Google Fonts, script di analisi, pulsanti social, video incorporati, reti pubblicitarie, librerie ospitate su CDN e immagini esterne. Ognuno di questi riceve l'header Referer nelle loro richieste.

Rilevanza per il GDPR e la protezione dei dati

Sotto il GDPR e leggi sulla privacy simili, gli URL con identificatori personali o informazioni sensibili possono costituire dati personali. Se i tuoi URL contengono nomi utente, indirizzi email o altre informazioni identificabili, condividere quegli URL tramite l'header Referer con terze parti può essere un problema di protezione dei dati.

Impostare una Referrer-Policy è una semplice misura tecnica che riduce lo scambio di dati non necessario con terze parti. Sebbene non sia esplicitamente richiesta dal GDPR, è in linea con i principi di minimizzazione dei dati (articolo 5(1)(c)) e privacy by design (articolo 25). Se il tuo responsabile della protezione dei dati o l'audit sulla privacy chiede quali misure tecniche hai adottato per limitare le fughe di dati, una corretta Referrer-Policy è un elemento concreto a cui fare riferimento.

Comportamento predefinito di WordPress e plugin comuni

Il core di WordPress non imposta di default un header Referrer-Policy. Questo significa che il tuo sito dipende dal default integrato del browser. Per i browser moderni, questo default è strict-origin-when-cross-origin, che in realtà è una policy ragionevole. Tuttavia, ci sono alcuni punti di attenzione:

• I browser più vecchi possono ricadere su no-referrer-when-downgrade, che invia l'URL completo in tutte le richieste HTTPS a HTTPS.
• Impostare esplicitamente l'header è meglio che fare affidamento sui default del browser, perché comunichi chiaramente la tua intenzione e copri tutte le versioni del browser.
• Alcuni plugin di sicurezza WordPress (come Sucuri o iThemes Security) includono un'opzione Referrer-Policy nelle loro impostazioni di hardening.
• WordPress 4.7.4 ha introdotto miglioramenti alla funzione wp_get_referer(), ma questa è una funzione lato server che legge l'header Referer per la protezione CSRF. È indipendente dal response header Referrer-Policy.

Impatto sull'analisi del sito web

La tua scelta di Referrer-Policy influisce direttamente su quali dati referrer ricevono i tuoi strumenti di analisi, e quali dati ricevono gli altri siti sul traffico dal tuo sito:

• Le tue analytics: se usi Google Analytics, Matomo o uno strumento simile con uno script di tracking sul tuo sito, le richieste same-origin contengono sempre il referrer completo indipendentemente dalla policy (la maggior parte delle policy limita solo i referrer cross-origin). Quindi i dati di analisi on-site non sono influenzati dalla maggior parte dei valori di policy.
• Tracciamento del traffico in entrata: la Referrer-Policy che imposti influisce su ciò che altri siti vedono quando i tuoi visitatori vengono dal tuo sito. Non influisce su ciò che vedi sul traffico verso il tuo sito (che dipende dalla policy del sito di riferimento).
• Tracciamento affiliati e partner: se hai un programma di affiliazione o devi tracciare i clic in uscita, una policy molto restrittiva come no-referrer romperà il tracciamento basato sul referrer. Il valore consigliato strict-origin-when-cross-origin invia l'origin (il dominio) ai partner, il che è solitamente sufficiente per l'attribuzione.

Impostare Referrer-Policy per WordPress

Il valore consigliato per la maggior parte dei siti WordPress è strict-origin-when-cross-origin:

Referrer-Policy: strict-origin-when-cross-origin

Impostazione in Apache:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

In Nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Tramite PHP:

add_action('send_headers', function() {
    header('Referrer-Policy: strict-origin-when-cross-origin');
});

Se il tuo sito gestisce dati particolarmente sensibili (informazioni mediche, dati finanziari, documenti legali), potresti considerare una policy più stringente, come same-origin o no-referrer. Sappi solo che ciò rimuove le informazioni referrer per tutte le richieste cross-origin, il che può influire sui servizi esterni che ne dipendono.

Cosa controlla InspectWP

InspectWP verifica se il tuo sito WordPress invia un header Referrer-Policy e segnala il valore configurato. Se l'header manca, il tuo sito dipende dal default del browser di ogni visitatore, che varia per versione. Una Referrer-Policy impostata esplicitamente garantisce un comportamento coerente e dimostra che hai preso una decisione consapevole su quante informazioni URL il tuo sito condivide con terze parti. Per la stragrande maggioranza dei siti WordPress, strict-origin-when-cross-origin è il valore consigliato.