Defaults.Exposed › Correzioni › Referrer-Policy

Come correggere Referrer-Policy

Una Referrer-Policy è un'istruzione di una sola riga che il tuo sito consegna al browser di ogni visitatore e che controlla quanta parte del tuo indirizzo web viaggia con lui quando clicca un collegamento verso un altro sito. Senza di essa, l'indirizzo completo della pagina su cui si trovava — termini di ricerca, numeri di conto, link di reimpostazione, percorsi di pagine interne e tutto il resto — viene consegnato in silenzio al sito successivo su cui atterra, inclusi inserzionisti, società di analisi e ovunque punti un collegamento.

In sintesi per la tua attività: Ogni volta che un visitatore clicca un collegamento in uscita, una pubblicità o una risorsa condivisa, il suo browser può consegnare l'indirizzo completo della tua pagina alla destinazione; e se i tuoi indirizzi contengono query di ricerca, ID cliente, numeri d'ordine o link monouso, stai facendo trapelare dati dei clienti a terze parti che non controlli. È un problema di protezione dei dati che i regolatori prendono sul serio, una promessa di privacy infranta in silenzio e una falla a punteggio che il team di sicurezza di un cliente segnalerà durante la due diligence.

Cosa può costarti

• Un cliente compila un modulo o esegue una ricerca, poi clicca un collegamento in uscita o una pubblicità, e l'indirizzo della pagina, completo di ciò che ha digitato, finisce dritto a un inserzionista o a una società di analisi con cui non avevi mai pensato di condividerlo.
• I link di reimpostazione password e di conferma account a volte portano un token segreto nell'indirizzo web; senza questo header, cliccare un qualsiasi collegamento su quella pagina può trasmettere l'intero indirizzo, token incluso, a un sito esterno.
• Percorsi di pagine interne private (aree amministrative, pagine riservate ai clienti, fasce di prezzo, link a documenti) vengono rivelati a ogni terza parte verso cui i tuoi visitatori cliccano, consegnando a concorrenti e curiosi una mappa del tuo sito che non dovrebbero mai vedere.
• Una revisione di sicurezza di un cliente o un audit sulla privacy scansiona il tuo sito, non vede alcuna Referrer-Policy e la registra come violazione della minimizzazione dei dati: il tipo di rilievo che blocca un contratto o una certificazione.
• Dati personali finiscono nelle mani di responsabili del trattamento con cui non hai alcun accordo, trasformando una svista di cinque minuti in una violazione dei dati da segnalare.

Perché è importante. I browser, lasciati a sé stessi, sono chiacchieroni: per impostazione predefinita dicono al sito successivo da dove proviene un visitatore, spesso includendo l'indirizzo completo della pagina. Per un sito vetrina può essere innocuo, ma nel momento in cui i tuoi indirizzi contengono qualcosa di personale — un termine di ricerca, un ID ordine, un'email in un link, un percorso privato — quel comportamento predefinito lo fa trapelare in silenzio a parti esterne. Una Referrer-Policy è l'unica impostazione che dice ai browser di smettere di condividere troppo. È un controllo a punteggio sulla tua scheda che vale punti reali, mappa direttamente sugli obblighi di minimizzazione dei dati previsti dalla normativa sulla privacy ed è uno degli header di sicurezza standard che qualsiasi revisione professionale si aspetta di trovare.

Cos’è, in parole semplici

Ogni volta che un visitatore sul tuo sito clicca un collegamento verso un altro sito — un link in uscita, un banner pubblicitario, un «condividi questo», persino un carattere o un’immagine caricati da altrove — il suo browser allega in silenzio una nota che indica da quale tua pagina proviene. Quella nota si chiama referrer.

Usato con criterio, il referrer è innocuo e persino utile: è così che altri siti sanno che il traffico è arrivato da te, ed è alla base di molte analisi oneste. L’insidia sta nel comportamento predefinito. Lasciato non gestito, il browser non dice solo «provengono da la-tua-impresa.com»: spesso consegna l’indirizzo completo della pagina esatta, incluso tutto ciò che segue il nome di dominio. E gli indirizzi web contengono molto più di quanto si creda: termini di ricerca digitati sul tuo sito, numeri d’ordine e di conto, il percorso verso una pagina privata riservata ai soci, persino token segreti monouso nei link di reimpostazione password e di conferma.

Una Referrer-Policy è una singola istruzione che il tuo sito invia al browser e che indica quanta parte di quella nota può condividere. Puoi dirgli di condividere solo il nome del dominio, solo verso altre pagine del tuo stesso sito, oppure nulla del tutto. Pensala come la differenza tra dare a uno sconosciuto il tuo indirizzo di casa completo con allegata la tua agenda giornaliera, e dirgli soltanto in quale città vivi.

Fa parte di una piccola famiglia di «header di sicurezza», brevi istruzioni che il tuo sito dà al browser di ogni visitatore. Non cambia l’aspetto né il funzionamento del tuo sito. Impedisce semplicemente al browser di condividere troppo per conto tuo.

Quanto può costarti

Ecco modi concreti e quotidiani in cui una Referrer-Policy mancante o permissiva colpisce le imprese reali. Nessuno di questi richiede un hacker: avvengono automaticamente, ogni giorno, nel normale uso.

• La ricerca trapelata. Un cliente cerca sul tuo sito qualcosa di sensibile — un prodotto medico, un servizio legato ai debiti, un confronto con un concorrente — e il termine di ricerca finisce nell’indirizzo della pagina. Poi clicca un collegamento in uscita o una pubblicità su quella pagina dei risultati. L’inserzionista riceve ora il tuo indirizzo con dentro il termine di ricerca, scoprendo esattamente cosa stava cercando il tuo cliente. Non hai mai acconsentito a condividerlo, e non puoi ritirarlo.

• Il link di reimpostazione esposto. Molti sistemi mettono un token segreto monouso nell’indirizzo delle pagine di reimpostazione password, conferma email o «accesso magico». Se quella pagina contiene un collegamento in uscita o una risorsa di terze parti, l’indirizzo completo — token incluso — può essere consegnato a un sito esterno. Nel caso peggiore questo dà a una terza parte le chiavi di un account.

• La mappa del sito regalata gratis. I percorsi delle tue pagine interne spesso rivelano la tua struttura: /admin, /prezzi-aziende, /clienti/acme, /download/report-privato. Senza questo header, ogni sito esterno verso cui i tuoi visitatori cliccano riceve quei percorsi. I concorrenti scoprono le tue fasce di prezzo e le tue linee di prodotto; gli scraper scoprono quali pagine prendere di mira.

• Il rapporto di condivisione dati indesiderato. La normativa sulla privacy si aspetta che tu sappia a chi vanno i dati personali dei tuoi clienti e che tu abbia un accordo in essere. Far trapelare indirizzi di pagine che contengono ID cliente o indirizzi email a reti pubblicitarie e società di analisi — senza accordo e senza consenso — è esattamente il tipo di flusso di dati incontrollato che trasforma un audit di routine in un rilievo, e un rilievo in una violazione da segnalare.

• La trattativa che si blocca sulla due diligence. Quando il team di sicurezza di un cliente più grande ti valuta, gli header di sicurezza standard mancanti sono una rapida casella da spuntare automatica. Vedere la Referrer-Policy assente gli dice che l’igiene di base della privacy non è mai stata impostata, e quell’impressione tinge tutto il resto della revisione.

Cos’è davvero

Per impostazione predefinita, i browser seguono un comportamento all’incirca equivalente a «strict-origin-when-cross-origin» sulle versioni moderne; ma non puoi farci affidamento, perché browser più vecchi, webview incorporate e certe configurazioni ricadono ancora su un comportamento che fa trapelare di più. L’unico modo per essere sicuro è impostare la policy esplicitamente. Quando lo fai, scegli una regola da un breve elenco. Quelle che contano:

• no-referrer — non condividere nulla. Al sito successivo non viene detto nulla su dove fosse il visitatore. Massima privacy; può frenare le tue analisi sui referral.
• same-origin — condividi l’indirizzo completo solo quando il visitatore si sposta tra pagine del tuo stesso sito; non condividere nulla con i siti esterni.
• strict-origin-when-cross-origin — l’impostazione predefinita consigliata. All’interno del tuo sito viene condiviso il percorso completo; verso i siti esterni viene condiviso solo il tuo nome di dominio nudo (e nulla del tutto passando da una pagina sicura a una non sicura). Le parti esterne scoprono che il traffico è arrivato da te, ma mai i dettagli privati dopo il dominio.
• origin — condividi sempre solo il tuo nome di dominio, anche all’interno del tuo stesso sito.

E i due valori da evitare, perché la scheda li tratta come né più né meno che l’assenza di header:

• unsafe-url — condividi l’indirizzo completo con tutti, sempre. È il caso peggiore in una sola parola.
• no-referrer-when-downgrade — il vecchio predefinito dei browser; invia ancora l’indirizzo completo ad altri siti sicuri, facendo trapelare tutto quanto descritto sopra.

Come si presenta una configurazione corretta: un header Referrer-Policy presente e impostato su un valore restrittivo — per la maggior parte delle imprese, strict-origin-when-cross-origin. Questo mantiene funzionanti le analisi sui referral assicurando al contempo che nulla oltre il tuo nome di dominio raggiunga mai un sito esterno.

Come correggerlo (gratis, circa 5 minuti)

Passa questa sezione al tuo referente IT, allo sviluppatore web o all’assistenza dell’hosting: la correzione è gratuita, è una singola riga e non romperà il tuo sito. Qui non c’è un rilascio rischioso: a differenza di alcune impostazioni di sicurezza, una Referrer-Policy sensata non può impedire ai tuoi collegamenti o alle tue pagine di funzionare. Riduce soltanto ciò che viene condiviso con gli altri siti.

L’obiettivo: impostare un header di risposta Referrer-Policy con il valore strict-origin-when-cross-origin (o un valore più rigido se preferisci condividere ancora meno).

Cloudflare (senza codice, il più facile se lo usi): Dashboard → il tuo dominio → Rules → Transform Rules → Modify Response Header → Create rule → Set static → nome header Referrer-Policy, valore strict-origin-when-cross-origin → applica a tutte le richieste in entrata → Deploy.

Google Workspace / Microsoft 365: questi gestiscono la tua email, non il tuo sito web, quindi l’header si imposta dove il tuo sito è effettivamente ospitato (il tuo host web, la CDN o il server), non nell’amministrazione di Workspace o 365. Individua l’host e usa l’opzione corrispondente qui sotto.

Nginx:

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

Apache (nella configurazione del sito o in .htaccess):

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

IIS (web.config):

<httpProtocol><customHeaders>
  <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders></httpProtocol>

Node / Express:

app.use((req, res, next) => { res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); next(); });

WordPress / host comuni: la maggior parte degli hosting WordPress gestiti e degli hosting condivisi permette di aggiungere header di risposta tramite un plugin di sicurezza, un pannello «headers» nel pannello di controllo dell’hosting, oppure lo snippet .htaccess qui sopra. Se sei dietro Cloudflare, il metodo Cloudflare è il più pulito e si applica ovunque in un colpo solo.

Dopo aver applicato: apri il tuo sito e riesegui il controllo, oppure usa gli strumenti di sviluppo del browser (scheda Network → clic sul documento principale → Response Headers) per confermare che Referrer-Policy: strict-origin-when-cross-origin sia presente.

Errori comuni

• Impostare un valore permissivo credendo che conti. unsafe-url e no-referrer-when-downgrade fanno comunque trapelare l’indirizzo completo. La scheda li valuta zero, identico all’assenza di header. Se l’header è presente ma i punti no, quasi sempre è questo il motivo.
• Impostarlo solo sulla homepage. L’header andrebbe inviato su ogni pagina, perché le fughe avvengono sulle pagine di risultati di ricerca, account e reimpostazione, non sulla homepage. Impostalo a livello di server, CDN o Cloudflare così si applica automaticamente a tutto il sito.
• Impostarlo solo in tag HTML <meta>. Un tag <meta name="referrer"> funziona in alcuni casi ma non in tutti, ed è facile che diventi incoerente tra le pagine. Impostarlo come un vero header di risposta (i metodi qui sopra) è l’approccio affidabile.
• Lasciare che uno strato sovrascriva un altro. Se sia il tuo server di origine sia la tua CDN impostano l’header con valori diversi, il risultato può essere imprevedibile. Scegli un solo punto per gestirlo — di solito la CDN o Cloudflare se ne hai una — e mantieni coerente il resto.
• Trattarlo come un sostituto del tenere i dati fuori dagli URL. L’header limita il danno, ma l’abitudine più sana a lungo termine è non mettere segreti e dati personali negli indirizzi web in primo luogo. Usa l’header ora; segnala l’igiene degli URL al tuo sviluppatore come seguito.

Una breve nota sugli header collegati

La Referrer-Policy sta accanto a un piccolo gruppo di altri header di sicurezza web che controlliamo: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options e alcuni header cross-origin avanzati. Proteggono cose diverse, quindi averne uno non copre gli altri. Se la tua Referrer-Policy manca, vale la pena chiedere a chi la corregge di confermare allo stesso tempo che gli altri header standard siano in atto, dato che di norma si configurano nello stesso unico posto e l’intervento non costa nulla in più.

In breve

La Referrer-Policy è la correzione per la privacy più economica e sicura della tua scheda: una riga, circa cinque minuti, nessun rischio di rompere nulla, e gratuita. Impedisce che i browser dei tuoi visitatori consegnino in silenzio gli indirizzi privati delle tue pagine — e qualsiasi dato personale contengano — a ogni sito esterno verso cui cliccano. Impostala su strict-origin-when-cross-origin, conferma che sia attiva su ogni pagina, e la falla di gravità media e i suoi 15 punti sono chiusi.

FAQ