TL;DR, Réponse rapide
10 min de lectureLe CNAME cloaking fait pointer un sous-domaine de votre site, comme metrics.example.com, vers un traqueur tiers via un enregistrement DNS CNAME, si bien que le navigateur traite le traqueur comme first-party et le laisse déposer et lire des cookies sur votre domaine. Safari 14 et iOS 14 plafonnent à 7 jours les cookies déposés dans des réponses tierces masquées par CNAME, Brave compare le nom canonique à ses listes de filtres depuis la version 1.17, et uBlock Origin démasque les CNAME dans Firefox. Un reverse proxy sur votre propre serveur est une configuration différente qui ne correspond pas à la définition du cloaking selon WebKit.
Qu'est-ce que le CNAME cloaking ?
Un fournisseur de suivi recourt au CNAME cloaking lorsqu'un propriétaire de site fait pointer l'un des sous-domaines de son propre site, comme metrics.example.com, vers le serveur du fournisseur via un enregistrement DNS CNAME, si bien que le navigateur traite les requêtes du fournisseur comme first-party. Les navigateurs distinguent first-party et third-party par le domaine enregistrable, et un CNAME cache la vraie destination une couche sous le web, dans le DNS. Le fournisseur obtient l'accès aux cookies de votre propre site sans apparaître comme un domaine distinct.
John Wilander, de WebKit, en a expliqué l'effet dans un billet du 12 novembre 2020 : le domaine tiers "is cloaked as sub.blog.example and thus has the same powers as the true first party." Le guide du rapport de confidentialité de Safari signale les endpoints masqués par CNAME comme un point à auditer.
Comment un enregistrement CNAME fait-il passer un traqueur pour first-party ?
Un enregistrement CNAME fait passer un traqueur pour first-party en créant un alias entre un nom sous votre domaine et le nom d'hôte du traqueur avant même que le navigateur voie une adresse IP, si bien que chaque vérification du navigateur ne voit que votre domaine. La chaîne se présente ainsi :
- La page sur
www.example.comcharge un script ou envoie une requête àmetrics.example.com. - Le DNS répond que
metrics.example.comest un CNAME decollect.tracker.example. - Le DNS résout
collect.tracker.examplevers l'adresse IP du fournisseur. - Le navigateur se connecte, mais l'URL, le nom du certificat TLS et la portée des cookies indiquent tous
metrics.example.com.
Deux règles sur les cookies rendent ce montage rentable pour un traqueur. Les requêtes vers metrics.example.com transportent tous les cookies dont la portée est example.com, ce qui, selon WebKit, inclut les "login cookies and user identity cookies." Et la réponse peut déposer de nouveaux cookies pour example.com via un en-tête Set-Cookie, que le navigateur classe comme cookies first-party.
C'est à cause de cette seconde règle que les traqueurs ont poussé ce montage. L'Intelligent Tracking Prevention de Safari supprime les cookies créés en JavaScript après 7 jours sans interaction de l'utilisateur avec le site, ce que détaille le guide de la limite de 7 jours des cookies dans Safari. Avant novembre 2020, les cookies déposés par un serveur dans une réponse HTTP échappaient à ce plafond. WebKit l'a dit sans détour : "Cross-site trackers have convinced site owners to set up CNAME cloaking in order to circumvent tracking prevention."
Comment Safari détecte-t-il le CNAME cloaking ?
Safari détecte le CNAME cloaking en comparant le CNAME par lequel se résout une sous-ressource first-party avec le domaine du site et avec le CNAME de la page principale, et il plafonne à 7 jours tout cookie déposé dans une réponse qui ne correspond pas. WebKit a livré cette défense dans Safari 14 sur macOS Big Sur, iOS 14 et iPadOS 14, annoncée le 12 novembre 2020 : "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days."
WebKit définit précisément le déclencheur : "a first-party subresource that resolves through a CNAME that differs from the first-party domain and differs from the top frame host's CNAME, if one exists." Cette dernière clause couvre les sites derrière un CDN ou un hébergeur edge, où tout le site se résout via un CNAME. Le tableau de WebKit couvre ces cas :
| Site principal (www.blog.example) | Sous-domaine de suivi (track.blog.example) | Expiration des cookies |
|---|---|---|
| Pas de cloaking | Pas de cloaking | Aucun plafond |
| Pas de cloaking | Pointe vers other.blog.example | Aucun plafond |
| Pas de cloaking | Pointe vers tracker.example | Plafond de 7 jours |
| Pointe vers abc123.edge.example | Pas de cloaking | Aucun plafond |
| Pointe vers abc123.edge.example | Pointe vers le même abc123.edge.example | Aucun plafond |
| Pointe vers abc123.edge.example | Pointe vers other.blog.example | Aucun plafond |
| Pointe vers abc123.edge.example | Pointe vers tracker.example | Plafond de 7 jours |
La page actuelle de WebKit sur la prévention du suivi étend la même règle aux astuces d'adressage qui se passent entièrement de noms DNS : "ITP detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days." Cela couvre la variante où l'enregistrement d'adresse d'un sous-domaine pointe vers l'adresse IP d'un fournisseur au lieu de son nom d'hôte.
Un cookie issu d'une réponse masquée expire désormais 7 jours après son dépôt, la même limite que les cookies JavaScript, donc le cloaking n'apporte plus d'ID à durée de vie plus longue dans Safari.
Comment Brave et uBlock Origin démasquent-ils les traqueurs CNAME ?
Brave et uBlock Origin démasquent les traqueurs CNAME en résolvant eux-mêmes le nom d'hôte et en comparant le nom canonique à leurs listes de filtres de traqueurs, puis en bloquant la requête si la vraie destination y figure.
uBlock Origin dans Firefox. uBlock Origin 1.25.0 a ajouté une demande de la permission dns de Firefox, et ses notes de version indiquent "From now on uBO will CNAME-uncloak network requests." La fonctionnalité repose sur l'API browser.dns de Mozilla, et l'équipe de recherche de Brave a noté que "this solution only works in Firefox, as Chromium does not provide the browser.dns API." Le wiki de uBlock Origin précise que le réglage "Uncloak canonical names" est un réglage standard depuis uBO 1.34.0, qu'il est "default enabled", et qu'il "is currently supported only on Firefox." uBlock Origin sur Chrome ne voit pas du tout le CNAME.
Brave Shields. Brave a annoncé le blocage basé sur les CNAME le 20 juillet 2020 et l'a livré à tous ses utilisateurs avec Brave 1.17. Brave vérifie deux URL pour chaque requête vers un hôte doté d'un CNAME : "first, the original URL requested by the page, and second, the same URL, but with the CNAME'ed domain name replaced with the resolved 'canonical' domain name." Son exemple était 16ao.mathon.fr, un sous-domaine d'apparence first-party dont le nom canonique était et5.eulerian.net, un traqueur tiers.
Un détail de Brave piège les propriétaires de sites. Depuis la version 1.30, le mode Shields "standard" par défaut de Brave n'applique pas les listes de filtres réseau aux sous-ressources same-site, et le mode "aggressive" les applique à "all sub-resource requests, first and third-party alike." Les billets de Brave ne disent pas comment le mode standard traite un sous-domaine masqué une fois démasqué, alors testez votre propre site en mode aggressive avant de compter sur l'un ou l'autre résultat. Les bloqueurs de publicités et les navigateurs axés sur la confidentialité réduisent déjà les totaux d'analytics, comme l'explique le guide sur l'effet des bloqueurs de publicités sur la précision de l'analytics. Le CNAME cloaking ne récupère pas ces données de façon fiable.
Quels sont les risques de sécurité du CNAME cloaking ?
Le CNAME cloaking place le serveur d'un fournisseur dans la portée de vos cookies, donc chaque cookie que votre site associe au domaine racine, cookies de connexion et de session compris, part chez ce fournisseur à chaque requête. C'est un risque pour la vie privée des visiteurs et un risque de sécurité pour vous. Le billet de WebKit cite deux problèmes. Les propriétaires de sites qui laissent un sous-domaine masqué en place après la fin du contrat "risk full website takeovers or customer cookie hijacking if the CNAME records aren't properly managed." Il cite aussi un rapport sur 250 sites web "of banks, healthcare companies, restaurant chains, and civil rights groups" compromis à cause d'un CNAME cloaking mal géré. Un visiteur qui inspecte les requêtes dans DevTools ne voit d'ailleurs que metrics.example.com, sans aucun signe que les données partent chez une entreprise extérieure.
Tableau de bord en temps réel
Suivi des objectifs
Suivi sans cookies
Un reverse proxy est-il la même chose que le CNAME cloaking ?
Un reverse proxy n'est pas du CNAME cloaking, parce que votre propre serveur reçoit la requête sur votre domaine et la transmet au fournisseur, donc le DNS de ce nom d'hôte se résout vers votre infrastructure et non vers celle du fournisseur. Selon la définition de WebKit, le cloaking signifie que la sous-ressource "resolves through a CNAME that differs from the first-party domain." Un chemin comme example.com/api/track traité par votre propre serveur web ne correspond pas à cette définition.
Les différences qui comptent pour l'analytics :
| Question | CNAME cloaking | Reverse proxy sur votre serveur |
|---|---|---|
| Vers où pointe le DNS ? | Vers le nom d'hôte du fournisseur | Vers votre propre serveur |
| Qui reçoit les cookies de votre domaine racine ? | Le fournisseur, directement | Votre serveur, qui choisit ce qu'il transmet |
| Safari plafonne-t-il les cookies de la réponse ? | Oui, 7 jours | Pas au titre des règles de cloaking CNAME ou IP |
| Brave ou uBO voient-ils un domaine de traqueur ? | Oui, après démasquage | Aucun nom d'hôte de traqueur à démasquer, mais les règles de filtrage par chemin s'appliquent toujours |
| Devez-vous toujours déclarer le fournisseur ? | Oui | Oui |
Un proxy ne change pas qui traite les données, donc un fournisseur qui construit des profils intersites pose le même problème de confidentialité avec l'un ou l'autre montage. Le guide du suivi côté serveur traite des serveurs de tagging placés derrière un CNAME.
Comment vérifier si votre site utilise le CNAME cloaking ?
Vous vérifiez la présence de CNAME cloaking en listant chaque sous-domaine auquel vos pages envoient des requêtes, en résolvant chacun d'eux et en signalant ceux qui se résolvent vers une entreprise que vous ne gérez pas :
- Ouvrez votre site dans Chrome DevTools, allez dans le panneau Network, rechargez et notez chaque requête vers un sous-domaine de votre propre domaine qui n'est pas votre hôte principal.
- Pour chacun, lancez
dig CNAME metrics.example.comounslookup -type=CNAME metrics.example.comdans un terminal. - Comparez la réponse avec votre propre infrastructure. Votre CDN ou votre hébergeur est attendu. Un fournisseur d'analytics, d'ad tech ou de données clients est un traqueur masqué.
- Vérifiez dans les en-têtes de réponse de ces requêtes la présence de
Set-Cookie. Un cookie associé à votre domaine racine et venant d'un hôte de fournisseur correspond au schéma que Safari plafonne. - Supprimez les CNAME qui pointent vers des fournisseurs que vous n'utilisez plus.
Comment Flowsery gère-t-il les configurations avec proxy ?
La documentation de Flowsery décrit une configuration avec proxy, pas un CNAME : vous faites passer le script /js/main.js et l'endpoint /api/track par votre propre serveur, et "Flowsery Analytics auto-detects proxied setups. No data-api is needed if you proxy both /js/main.js and /api/track." La documentation publie des guides de proxy pour Next.js, Express.js, PHP, Flask, FastAPI, Vue.js, Nginx, Caddy, Astro, Laravel et DigitalOcean. Le script de suivi de Flowsery fonctionne sans cookies avec un hash de visiteur renouvelé chaque jour et ne collecte aucune donnée personnelle, donc dans ce mode il n'existe tout simplement aucun cookie de visiteur que Safari pourrait plafonner. La page sur l'analytics respectueux de la vie privée liste ce que le traqueur stocke et ce qu'il laisse de côté.
Questions fréquentes
Le CNAME cloaking compte-t-il pour un analytics sans cookies ?
La défense de Safari contre le CNAME cloaking plafonne les cookies, donc un script qui ne dépose aucun cookie ne laisse rien à plafonner. uBlock Origin sur Firefox résout toujours le nom d'hôte et bloque un sous-domaine masqué dont le nom canonique figure dans ses listes, et Brave effectue la même vérification du nom canonique. Un script sans cookies servi via un proxy sur votre propre serveur ne leur donne aucun nom d'hôte de fournisseur à démasquer.
Le CNAME cloaking contourne-t-il les bloqueurs de publicités ?
Le CNAME cloaking contourne les bloqueurs à base de listes qui ne voient que le nom d'hôte, ce qui inclut uBlock Origin sur Chrome. uBlock Origin sur Firefox résout le nom canonique et bloque la requête quand il correspond à un traqueur connu, et Brave effectue la même vérification depuis la version 1.17. Safari ne bloque pas la requête mais plafonne à 7 jours les cookies qu'elle dépose.
Quelle version de Safari a ajouté la défense contre le CNAME cloaking ?
Safari 14 l'a ajoutée sur macOS Big Sur, iOS 14 et iPadOS 14, annoncée par WebKit le 12 novembre 2020. Le même plafond de 7 jours couvre désormais aussi le masquage par adresse IP tierce.
Un CNAME de CDN compte-t-il comme du cloaking dans Safari ?
Non, pas quand le CDN sert tout votre site. La règle de WebKit exempte un sous-domaine dont le CNAME correspond au CNAME de la page principale, donc un site et ses sous-domaines sur le même hébergeur edge gardent une expiration normale des cookies. Le plafond s'applique quand un sous-domaine se résout vers un hôte tiers différent.
Le tagging côté serveur derrière un CNAME échappe-t-il à ITP ?
Non. Un serveur de tagging joint via un CNAME vers le service hébergé d'un fournisseur correspond à la définition du CNAME cloaking tiers selon WebKit, donc Safari plafonne à 7 jours les cookies qui en proviennent. Faire tourner le serveur sur votre propre infrastructure, avec un DNS pointant vers votre propre IP, évite cette règle.
Comment supprimer le CNAME cloaking de mon site ?
Supprimez l'enregistrement CNAME du sous-domaine du fournisseur dans votre zone DNS et retirez les tags qui l'appellent. Si vous avez encore besoin du fournisseur, faites passer son endpoint par un reverse proxy que vous exploitez et mentionnez le fournisseur dans votre politique de confidentialité.
Pourquoi les traqueurs utilisent-ils le CNAME cloaking ?
Le navigateur traite un sous-domaine de votre site comme du first-party. Les requêtes vers ce sous-domaine portent les cookies du domaine racine, et la réponse peut créer de nouveaux cookies pour ce domaine. Avant novembre 2020, les cookies posés par un serveur dans une réponse HTTP échappaient à la limite de 7 jours de Safari.
Brave bloque-t-il le CNAME cloaking par défaut ?
Brave compare le nom canonique à ses listes de filtres depuis la version 1.17. Depuis la version 1.30, le mode standard de Shields n'applique pas les listes de filtres réseau aux sous-ressources du même site, alors que le mode agressif les applique à toutes les requêtes de sous-ressources. Les articles de Brave ne disent pas comment le mode standard traite un sous-domaine camouflé, donc testez votre site en mode agressif.
uBlock Origin bloque-t-il le CNAME cloaking sur Chrome ?
Pas sur Chrome. Chromium ne fournit pas l'API browser.dns, donc uBlock Origin sur Chrome ne peut pas voir le CNAME. Dans Firefox, le réglage "Uncloak canonical names" est activé par défaut et bloque les requêtes dont le nom canonique correspond à un traqueur connu.
Tableau de bord en temps réel
Suivi des objectifs
Suivi sans cookies
Qu'est-ce que le IP address cloaking ?
Le IP address cloaking est la variante où l'enregistrement d'adresse d'un sous-domaine pointe vers l'adresse IP d'un fournisseur plutôt que vers son nom d'hôte. Le DNS n'affiche aucun CNAME. Selon WebKit, ITP le détecte et limite à 7 jours les cookies de la réponse HTTP, comme pour le CNAME cloaking.
Cet article vous a-t-il été utile ?
Dites-nous ce que vous en pensez !
Nous voir plus souvent sur Google
Un clic définit Flowsery comme source préférée. Nos articles remontent alors dans vos À la une, en mode IA et dans les aperçus IA.
Avant de partir...
Flowsery
Des analyses orientées revenus pour votre site web
Suivez chaque visiteur, source et conversion en temps réel. Simple, puissant et sans cookies.
Tableau de bord en temps réel
Suivi des objectifs
Suivi sans cookies
Termes connexes du glossaire
Comment le cookie syncing associe les ID publicitaires d'un site à l'autre
L'ad tech utilise le cookie syncing pour échanger des ID via redirections et pixels. Safari, Firefox et Chrome face à lui, et pourquoi l'analytics s'en passe.
Créer des métriques calculées GA4 avec un quota de cinq emplacements
Google limite les métriques calculées GA4 à 5 par propriété standard. Syntaxe des formules, unités, emplacements et ce qu'une formule ne peut pas utiliser.
Configurer le regroupement de contenu GA4 avec un seul paramètre
Configurez le regroupement de contenu GA4 avec le paramètre content_group dans gtag ou Tag Manager, lisez la dimension Content group et évitez les (not set).
Ce qu'envoient les User-Agent Client Hints, et ce que l'analytics voit encore
Dans Chrome, les User-Agent Client Hints répartissent les données du navigateur en en-têtes Sec-CH-UA. Entropie, Accept-CH, UA réduit et ce que lit l'analytics.
Pourquoi le sens de visiteurs uniques change d'un outil à l'autre
Le sens de visiteurs uniques dépend de l'outil: GA4 l'estime, Matomo refuse de le calculer sur de longues périodes, Adobe déduplique sur tout le rapport.
Google recense sept causes distinctes de not set dans GA4
Google donne à not set dans GA4 une cause par dimension, d'un session_start absent à un content_group vide. Voici chaque cause et le correctif associé.
Articles connexes
Comment les cookies partitionnés CHIPS donnent à chaque site son propre pot
Poser des cookies partitionnés CHIPS exige Secure, SameSite=None et un attribut de plus, et le navigateur garde une copie par site de premier niveau.
Sous le GDPR, la réversibilité tranche pseudonymisation vs anonymisation
La réversibilité tranche pseudonymisation vs anonymisation. Les données de l'Article 4(5) restent personnelles, les données anonymes sortent du GDPR.
Ce que le server-side tracking corrige, et ce qu'il laisse intact
Ce que le server-side tracking déplace sur votre serveur, les plafonds de cookies Safari qu'il évite, la déduplication des événements et le consentement dû.