Confidentialité par défaut au niveau HTTP : les en-têtes qui réduisent votre surface de pistage

L'essentiel du travail sur la confidentialité se fait en JavaScript — logique de consentement, contrôle des tags, rotation des identifiants. Mais le navigateur vous donne deux en-têtes de réponse HTTP qui ferment la surface de surveillance avant même qu'un seul script ne s'exécute, et la plupart des sites n'en envoient aucun. Permissions-Policy et Referrer-Policy sont du privacy-by-design dans sa forme la plus littérale : de la configuration, pas du code.

Ils comptent plus aujourd'hui qu'il y a un an. Avec le retrait par Google, en octobre 2025, de la plupart des API du Privacy Sandbox, les directives ad-tech résiduelles que ces API avaient introduites restent câblées dans Chrome — et un site peut désormais les désactiver activement au lieu d'attendre leur suppression.

Permissions-Policy : refusez les fonctionnalités que vous n'utilisez jamais

Permissions-Policy contrôle quelles fonctionnalités du navigateur un document et ses frames intégrés peuvent utiliser. C'est le même mécanisme qui régit camera, geolocation et microphone — mais il régit aussi les API proches du pistage auxquelles l'ad-tech a recours.

L'allowlist par défaut de la plupart d'entre elles est permissive. browsing-topics, la directive qui contrôle la Topics API, a pour valeur par défaut * — toute origine sur la page, y compris les frames tiers, peut l'appeler sauf indication contraire. La désactiver tient en une ligne :

Permissions-Policy: browsing-topics=()

Une allowlist vide () refuse la fonctionnalité à tout le monde, y compris à votre propre origine. Vous pouvez verrouiller tout le bloc d'API d'intérêt publicitaire et de mesure dans un seul en-tête :

Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=(), private-aggregation=()

Tout script — first-party ou intégré — qui appelle document.browsingTopics() ou envoie un en-tête de requête Sec-Browsing-Topics échoue désormais avec une NotAllowedError. Vous ne faites pas confiance aux tiers pour bien se comporter ; vous supprimez la capacité au niveau de la plateforme.

Ces directives sont dépréciées en même temps que le Privacy Sandbox, donc certaines disparaîtront de Chrome au fil des prochaines versions. Les définir à () est sans effet une fois qu'elles ont disparu et protecteur jusque-là.

Referrer-Policy : arrêtez de fuiter vos URL

Chaque requête de navigation et de sous-ressource peut transporter un en-tête Referer nommant la page d'où vient l'utilisateur. Les URL complètes fuitent les query strings, les identifiants encodés dans le chemin, les termes de recherche et la structure interne des pages vers chaque tiers que vous chargez — fournisseurs d'analytics, polices, CDN, pixels publicitaires.

Les navigateurs modernes utilisent par défaut strict-origin-when-cross-origin, qui est déjà un plancher raisonnable :

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

Sous cette politique, le navigateur envoie l'URL complète uniquement sur les requêtes same-origin, envoie uniquement l'origine sur les requêtes cross-origin sécurisées, et n'envoie rien lors d'une rétrogradation de HTTPS vers HTTP. Ainsi https://app.example/orders/4815?token=abc parvient à un tiers sous la forme https://app.example/ — l'origine, sans chemin, sans query.

Cette valeur est devenue celle par défaut de la spécification en novembre 2020, mais vous devriez tout de même définir l'en-tête explicitement. Un upstream mal configuré, une valeur par défaut héritée d'un ancien framework ou une balise <meta> referrer peuvent l'écraser, et un en-tête explicite est auditable. Si vous n'intégrez rien de sensible dans les URL et voulez être strict, strict-origin supprime aussi le chemin sur les requêtes same-origin.

Pourquoi cela s'accorde avec l'analytics sans cookies

Ces en-têtes et un tracker respectueux de la vie privée résolvent le même problème par deux directions. Le tracker contrôle ce que votre analytics collecte ; les en-têtes contrôlent ce que tous les autres sur la page peuvent atteindre.

Un tracker sans cookies qui dérive l'identité d'un hash quotidien à sens unique — SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) — n'a jamais besoin de l'URL complète du referrer ni de la Topics API pour faire son travail. Il lit document.referrer uniquement pour attribuer la source d'une visite, et l'origine suffit pour cela. Donc resserrer Referrer-Policy ne coûte rien à votre analytics tout en colmatant une fuite pour chaque autre requête de la page.

Le même alignement vaut pour la performance. Les en-têtes coûtent zéro octet de JavaScript et zéro temps de thread principal ; ils sont évalués par le navigateur avant le parsing. Vous obtenez une amélioration mesurable de la confidentialité sans impact sur le Largest Contentful Paint ni sur l'Interaction to Next Paint — le compromis inverse d'une plateforme de gestion du consentement, qui ajoute du poids de script pour gérer des permissions qu'un en-tête aurait pu refuser d'emblée.

Déployez-les à l'edge

Définissez les deux en-têtes à votre edge ou sur votre serveur d'origine pour que chaque réponse les transporte, y compris les assets statiques et le HTML :

Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=()
Referrer-Policy: strict-origin-when-cross-origin

Sur Cloudflare, ajoutez-les dans une Transform Rule ou un Worker ; dans Next.js, dans la configuration headers() ; dans n'importe quel reverse proxy, une seule ligne add_header. Il n'y a aucun risque de déploiement : vous refusez des capacités que vous n'utilisez pas et coupez des données que vous n'avez jamais voulu envoyer.

La confidentialité par conception est généralement présentée comme une décision d'architecture. Au niveau HTTP, ce sont deux lignes de configuration, et elles sont ouvertes par défaut tant que vous ne les fermez pas.

Sources

• En-tête Permissions-Policy (MDN Web Docs)
• Permissions-Policy : directive browsing-topics (MDN Web Docs)
• En-tête Referrer-Policy (MDN Web Docs)
• Contrôler les fonctionnalités du navigateur avec Permissions Policy (Chrome for Developers)
• Mise à jour sur les plans pour les technologies du Privacy Sandbox (Google)