Tracking server-side : reverse proxy et DNS cloaking

Introduction

Le server-side tracking est souvent présenté comme la réponse universelle aux bloqueurs de publicités, à l’ITP de Safari, à la durée de vie limitée des cookies, à la fin des cookies tiers et à la perte de données. La croyance courante est simple : « si le tracking tourne sur le serveur, les navigateurs ne peuvent plus interférer ». C’est incomplet.

Les navigateurs ne bloquent pas selon l’endroit où tourne votre conteneur. Ils appliquent leurs restrictions selon la propriété du domaine, la résolution DNS, la délégation réseau, le comportement des cookies et les infrastructures de tracking connues. Le server-side n’est pas un bouclier, c’est un changement d’architecture, et une architecture peut être résiliente ou fragile.

Ce que « first-party » veut vraiment dire

Beaucoup d’équipes pensent : « si le sous-domaine m’appartient, il est first-party ». Prenons cet exemple :

sst.yourdomain.com  → CNAME → vendor.infrastructure.com

Techniquement, le nom d’hôte vous appartient, mais l’enregistrement DNS pointe ailleurs. Le navigateur peut suivre la chaîne de CNAME, Safari voit que le CNAME mène vers un autre domaine, et la requête atterrit finalement sur l’infrastructure d’un tiers. C’est le DNS cloaking : cela ressemble à du first-party, mais ce ne l’est pas sur le plan architectural. Le vrai contrôle first-party est un contrôle au niveau du réseau.

DNS cloaking et détection par l’ITP

L’Intelligent Tracking Prevention (ITP) de Safari examine la chaîne de CNAME du sous-domaine et, depuis Safari 16.4, vérifie aussi si son adresse IP appartient à un autre réseau que le site principal (WebKit Tracking Prevention). Un simple dig montre la délégation :

dig sst.yourdomain.com
sst.yourdomain.com CNAME vendor.example.net

Conséquence : les cookies posés par les réponses HTTP de ce sous-domaine sont plafonnés à 7 jours. Le DNS cloaking masque la délégation, il ne la supprime pas.

Ce que change vraiment un reverse proxy

Sans reverse proxy, le navigateur appelle sst.yourdomain.com, qui renvoie par CNAME vers vendor.infrastructure.com. Avec un reverse proxy (DNS proxifié chez Cloudflare), le navigateur parle à l’edge Cloudflare, qui relaie vers le serveur d’origine du fournisseur :

Browser → Cloudflare edge (sst.yourdomain.com) → Vendor origin server

Le TLS se termine alors chez vous, l’infrastructure est abstraite, les en-têtes sont contrôlables et les cookies peuvent être ancrés correctement. Mais attention : depuis Safari 16.4, si sst.yourdomain.com résout vers des IP dont la première moitié diffère de celle de www.yourdomain.com (par exemple, le site est hébergé ailleurs et seul sst. passe par Cloudflare), Safari plafonne quand même ses cookies à 7 jours (WebKit bug 246477). Servir en same-origin (www.yourdomain.com/metrics) ou placer le site principal derrière le même edge évite ce piège.

Avec un DNS proxifié, la poignée de main TLS se fait entre le navigateur et Cloudflare, pas entre le navigateur et l’infrastructure du fournisseur. Cela vous donne la maîtrise des en-têtes et du routage, mais ce n’est pas, en soi, ce que Safari vérifie : Safari regarde le CNAME et l’IP.

Les cookies générés par le serveur : le vrai test

Une architecture résiliente doit générer les cookies côté serveur. SameSite=Lax suffit pour un cookie de mesure first-party ; None ne sert qu’au cross-site (voir MDN Set-Cookie) :

Set-Cookie: fp_id=abc123;
Domain=.yourdomain.com;
Secure;
HttpOnly;
SameSite=Lax;
Path=/;

Pour valider, deux vérifications :

Dans le navigateur : DevTools, onglet Network, cliquez une requête vers https://sst.yourdomain.com et cherchez Set-Cookie dans les Response Headers. S’il est absent, aucun cookie n’est généré côté serveur.
En ligne de commande : curl -I https://sst.yourdomain.com. Avec Cloudflare, vous devez voir server: cloudflare. Avec un autre CDN ou un load balancer, vérifiez que les IP renvoyées par dig sst.yourdomain.com et dig www.yourdomain.com partagent la même première moitié.

Sans Set-Cookie, l’architecture est incomplète : sans cookies générés par le serveur, il n’y a rien à restaurer. La configuration recommandée par Google est le same-origin (www.yourdomain.com/metrics), qui évite aussi le contrôle d’IP de Safari (Google : custom domain for server-side tagging).

Servir le loader en first-party

Le loader par défaut est https://www.googletagmanager.com/gtm.js. En first-party, il devient https://sst.yourdomain.com/gtm.js. Les bénéfices : une surface de domaine unifiée, une origine de requête cohérente et moins de requêtes vers des hôtes tiers. Cela ne change rien aux obligations de consentement (Google tag gateway, CNIL). Si le loader reste tiers, une partie de votre tracking reste exposée.

Construire un reverse proxy programmable (Cloudflare Worker)

Un reverse proxy programmable permet d’inspecter les en-têtes, de router dynamiquement, de gérer plusieurs origines, d’enrichir les requêtes et de filtrer. Exemple minimal :

export default {
  async fetch(request) {
    const url = new URL(request.url);
    url.hostname = "vendor.origin.net";

    const modifiedRequest = new Request(url, request);
    return fetch(modifiedRequest);
  }
}

Cela ouvre la normalisation du trafic, l’abstraction multi-fournisseurs, le routage contrôlé et la logique de résilience. Mais cela exige de comprendre le TLS, de préserver l’intégrité du header Host et des cookies, et d’avoir une discipline stricte sur le cache. C’est une décision d’architecture, pas un gain rapide.

Comparaison des modèles d’architecture

Modèle	Complexité	Contrôle	Risque du plafond Safari de 7 jours
CNAME vers le fournisseur	Faible	Faible	Oui
Reverse proxy managé	Moyenne	Moyen	Oui, si la plage d’IP diffère de celle du site principal
Proxy Worker sur mesure	Élevée	Très élevé	Oui, si la plage d’IP diffère de celle du site principal
Chemin same-origin (`www.yourdomain.com/metrics`)	—	—	Non

Le bon choix dépend de votre autonomie technique, de votre tolérance au risque, de la diversité de vos fournisseurs et de votre stratégie d’infrastructure à long terme.

Checklist d’audit pratique

Votre DNS est-il proxifié ?
Le TLS se termine-t-il sur votre edge ?
dig sst.yourdomain.com et dig www.yourdomain.com renvoient-ils des IP de même première moitié (ou servez-vous en same-origin) ?
Set-Cookie est-il généré côté serveur ?
Votre loader est-il first-party ?
Savez-vous expliquer votre chaîne de CNAME ?
Maîtrisez-vous le flux des en-têtes ?
L’état du consentement est-il transmis avec chaque requête et appliqué avant tout transfert ?

Si ce n’est pas le cas, votre setup server-side n’est peut-être pas structurellement résilient.

Conclusion

Le server-side tracking n’est pas une fonctionnalité, c’est de l’architecture réseau. La différence entre « ça marche aujourd’hui » et « ça tiendra demain » ne tient pas au conteneur : elle tient au DNS, au TLS, aux en-têtes, aux cookies et à la conception du proxy. Un système de tracking résilient se conçoit, il ne s’installe pas.

Sources

Pour aller plus loin, lisez la version complète de l’article (en anglais) : Server-Side Tracking Architecture: Reverse Proxy, DNS Cloaking, and First-Party Resilience Explained.

Besoin d’aide sur ce sujet ? Commanders Act et server-side.

Architecture du tracking server-side : reverse proxy, DNS cloaking et résilience first-party