Privacy by Default a livello HTTP: gli header che riducono la tua superficie di tracciamento
Due header di risposta — Permissions-Policy e Referrer-Policy — decidono quanto le tue pagine possono trasmettere ad ad-tech e terze parti. Impostali una volta e la superficie di sorveglianza si chiude di default.
La maggior parte del lavoro sulla privacy avviene in JavaScript — logica di consenso, gating dei tag, rotazione degli identificatori. Ma il browser ti mette a disposizione due header di risposta HTTP che chiudono la superficie di sorveglianza prima che venga eseguito un solo script, e la maggior parte dei siti non ne imposta nessuno. Permissions-Policy e Referrer-Policy sono la privacy by design nella sua forma più letterale: configurazione, non codice.
Oggi contano più di un anno fa. Con il ritiro da parte di Google, nell'ottobre 2025, della maggior parte delle API Privacy Sandbox, le direttive ad-tech residue introdotte da quelle API restano comunque cablate in Chrome — e un sito ora può disattivarle attivamente invece di aspettare che vengano rimosse.
Permissions-Policy: nega le funzionalità che non usi mai
Permissions-Policy controlla quali funzionalità del browser un documento e i suoi frame incorporati possono usare. È lo stesso meccanismo che regola camera, geolocation e microphone — ma regola anche le API affini al tracciamento a cui l'ad-tech ricorre.
L'allowlist di default per la maggior parte di queste è permissiva. browsing-topics, la direttiva che controlla la Topics API, ha come default * — ogni origin presente nella pagina, inclusi i frame di terze parti, può chiamarla a meno che tu non dica diversamente. Disabilitarla è una riga:
Permissions-Policy: browsing-topics=()
Un'allowlist vuota () nega la funzionalità a tutti, incluso il tuo stesso origin. Puoi bloccare l'intero cluster di API di ad-interest e di misurazione in un singolo header:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=(), private-aggregation=()
Qualunque script — first-party o incorporato — che chiama document.browsingTopics() o invia un header di richiesta Sec-Browsing-Topics ora fallisce con un NotAllowedError. Non stai confidando nel buon comportamento delle terze parti; stai rimuovendo la capability a livello di piattaforma.
Queste direttive sono deprecate insieme a Privacy Sandbox, quindi alcune spariranno da Chrome nelle prossime release. Impostarle a () è innocuo una volta che saranno scomparse e protettivo fino ad allora.
Referrer-Policy: smetti di far trapelare i tuoi URL
Ogni navigazione e ogni richiesta di subresource può trasportare un header Referer che indica la pagina da cui proviene l'utente. Gli URL completi fanno trapelare query string, identificatori codificati nel path, termini di ricerca e struttura interna delle pagine verso ogni terza parte che carichi — fornitori di analytics, font, CDN, pixel pubblicitari.
I browser moderni usano come default strict-origin-when-cross-origin, che è già una base ragionevole:
Referrer-Policy: strict-origin-when-cross-origin
Con questa policy il browser invia l'URL completo solo nelle richieste same-origin, invia solo l'origin nelle richieste sicure cross-origin e non invia nulla quando si effettua un downgrade da HTTPS a HTTP. Così https://app.example/orders/4815?token=abc arriva a una terza parte come https://app.example/ — origin, niente path, niente query.
Quel default è diventato il default della specifica a novembre 2020, ma dovresti comunque impostare l'header esplicitamente. Un upstream mal configurato, un vecchio default di framework o un tag referrer <meta> possono sovrascriverlo, e un header esplicito è verificabile. Se non incorpori nulla di sensibile negli URL e vuoi essere rigoroso, strict-origin elimina il path anche nelle richieste same-origin.
Perché si abbina all'analisi cookie-free
Questi header e un tracker privacy-first risolvono lo stesso problema da due direzioni. Il tracker controlla cosa raccoglie la tua analisi; gli header controllano cosa possono raggiungere tutti gli altri sulla pagina.
Un tracker cookie-free che deriva l'identità da un hash giornaliero a senso unico — SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) — non ha mai bisogno dell'URL completo del referrer o della Topics API per svolgere il suo compito. Legge document.referrer solo per attribuire la sorgente di una visita, e per questo l'origin basta. Quindi irrigidire la Referrer-Policy non costa nulla alla tua analisi, mentre chiude una falla per ogni altra richiesta sulla pagina.
Lo stesso allineamento vale per le performance. Gli header costano zero byte di JavaScript e zero tempo di main-thread; vengono valutati dal browser prima del parsing. Ottieni un miglioramento misurabile della privacy senza alcun impatto su Largest Contentful Paint o Interaction to Next Paint — il trade-off opposto rispetto a una piattaforma di consent management, che aggiunge peso di script per gestire permessi che un header avrebbe potuto negare del tutto.
Distribuiscili all'edge
Imposta entrambi gli header sul tuo server edge o di origine in modo che ogni risposta li trasporti, inclusi asset statici e HTML:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=()
Referrer-Policy: strict-origin-when-cross-origin
Su Cloudflare aggiungili in una Transform Rule o in un Worker; in Next.js, nella configurazione headers(); in qualunque reverse proxy, una singola riga add_header. Non c'è rischio di rollout: stai negando capability che non usi e tagliando dati che non hai mai voluto inviare.
La privacy by design viene di solito inquadrata come una decisione architetturale. A livello HTTP sono due righe di configurazione, e restano aperte di default finché non le chiudi.
Comments
Loading comments…