Referrer-Policy è un header di risposta. Dice cosa della URL può finire in Referer. Il default è strict-origin-when-cross-origin. unsafe-url non si usa. Il banner cookie non lo imposta.
Il banner cookie non scrive l’header Referrer-Policy. Referrer-Policy è un header di risposta con cui il server dice al browser cosa può mettere nel campo Referer della richiesta successiva: origin, path, query, oppure niente. Il nome del campo, Referer, è uno sbaglio di ortografia. L’header della policy, Referrer-Policy, la doppia erre ce l’ha. Non è un plugin «privacy». Non è il consenso al marketing.
In breve: default nei browser, strict-origin-when-cross-origin. Same-origin: origin + path + query. Cross-origin HTTPS→HTTPS: solo origin. Downgrade HTTPS→HTTP: niente. unsafe-url manda path e query a chiunque. no-referrer non manda nulla. Verifica del 21 settembre 2026 su MDN.
Cosa trovi in questo articolo
Cosa è Referrer-Policy (e cosa non è il banner)
MDN, sulla pagina dell’header Referrer-Policy, parte da un fatto: ogni navigazione, ogni immagine remota, ogni fetch() può spedire al destinatario l’indirizzo della pagina di partenza. Quell’indirizzo sta nell’header di richiesta Referer. Path e querystring ci stanno, se la policy lo consente. Frammento di sezione e credenziali nell’URL no. MDN avverte: il campo può avere conseguenze indesiderate su privacy e sicurezza. Un token in query, un ID di reset password, un percorso interno dell’admin: finiscono dal lato di un CDN, di un font, di un pixel, se la policy è larga.
Non è CORS. CORS decide quale origin può leggere una risposta. Non è la CSP: la CSP limita cosa la pagina può eseguire. Non è HSTS: HSTS impedisce di tornare in HTTP sul nome. Non è il cookie SameSite: SameSite decide se il cookie parte. Referrer-Policy decide cosa della propria URL si regala a terzi. Quattro mestieri. Il plugin che promette «privacy GDPR» e scrive solo il banner è un quinto script, sul piano sbagliato.
Questo pezzo sta nel cluster Sicurezza, accanto al mixed content — HTTP su una pagina HTTPS — e a SRI. SRI verifica i byte del CDN. Mixed content è il lucchetto che mente. Referrer-Policy è la URL che esce.
Le direttive: default, origin, unsafe-url
MDN marca l’header Baseline, widely available. Elenca le direttive. Una è il default, da revisione della spec del novembre 2020. Prima il default era no-referrer-when-downgrade.
| Direttiva | Cosa spedisce il browser |
|---|---|
no-referrer | niente. L’header Referer non parte |
strict-origin-when-cross-origin (default) | same-origin: origin + path + query. Cross-origin con lo stesso livello di sicurezza: solo origin. HTTPS→HTTP: niente |
strict-origin | solo origin, e solo se il livello di sicurezza non scende. HTTPS→HTTP: niente |
origin | solo origin, anche sul downgrade |
origin-when-cross-origin | same-origin: origin + path + query. Cross-origin: solo origin, anche su HTTP |
same-origin | origin + path + query solo same-origin. Cross-origin: niente |
no-referrer-when-downgrade | origin + path + query ovunque, tranne HTTPS→HTTP |
unsafe-url | origin + path + query a chiunque, anche su HTTP. MDN: lascia uscire informazioni potenzialmente private. Non si usa in produzione |
Il default tiene il path in casa e manda solo l’origin ai terzi HTTPS. È già meglio del vecchio no-referrer-when-downgrade, che regalava l’intero URL a ogni CDN. Non basta se l’admin sta su https://app.example/clienti/123/edit e la pagina include uno script di terzi: l’origin esce lo stesso. Per quelle superfici si stringe a same-origin o no-referrer. unsafe-url è il valore di un tutorial copiato nel 2015.
Header, meta, rel=noreferrer
La policy si mette sulla risposta. MDN: header HTTP, oppure un meta con name=referrer e content=origin sul documento, oppure attributo referrerpolicy su link, immagini, iframe, script e fogli collegati. Si può anche mettere rel=noreferrer su un link. Attenzione all’ortografia, scrive MDN: la relazione è noreferrer, senza trattino; il meta è no-referrer, con il trattino. Due stringhe, un mestiere, un errore da copia-incolla.
Sull’header HTTP si possono elencare più valori, l’ultimo è quello desiderato, i precedenti sono fallback per browser vecchi: Referrer-Policy: no-referrer, strict-origin-when-cross-origin. Sull’attributo HTML la lista multipla non è supportata. I fogli CSS esterni usano il default, a meno che la risposta del CSS non porti un Referrer-Policy proprio. Un plugin «abilita privacy» che non tocca gli header del server non ha fatto il lavoro.
Si verifica sugli header della risposta, in staging, e sulla richiesta in uscita verso un terzo: DevTools, scheda Network, colonna Referer. Non sul lucchetto della home. Non sul testo del banner. Il certificato TLS cifra il transito; non decide cosa ci sta scritto dentro.
Errori da evitare
Lasciare
unsafe-url«per le analytics»: path e query finiscono da un fornitore, token compresi.Confondere
rel="noreferrer"(senza trattino) con il metano-referrer(con il trattino) e copiare la stringa sbagliata.Trattare il banner cookie come Referrer-Policy: il consenso non scrive l’header.
Confondere Referrer-Policy con CORS, CSP o HSTS: tre header, tre mestieri, più questo.
Mettere token di sessione o reset password in query e affidarsi al default: same-origin il path esce comunque verso le proprie risorse.
Fidarsi del plugin «GDPR pack» senza leggere
Referrer-Policysulla risposta eReferersulla richiesta al CDN.
In sintesi
Referrer-Policy è un header di risposta. Dice cosa della propria URL può finire in Referer. Il default è strict-origin-when-cross-origin. unsafe-url non si usa. Il banner cookie non lo imposta. Si verifica sugli header, non sul testo del consenso. MDN, 21 settembre 2026.
