tech

Safari 27 bloque des domaines adtech au niveau réseau : ce que dit WebKit, ce que j’ai mesuré, comment auditer

Par Laurent Fidahoussen, le 12 novembre 2026

Pendant neuf ans, la prévention du tracking de Safari a suivi une seule règle : la requête peut partir, mais elle voyage léger. Pas de cookie tiers, un cookie first-party raccourci, un referrer tronqué. Le pixel se déclenchait quand même, et quelqu’un recevait un hit à l’autre bout.

Safari 27 casse cette règle. Pour une liste de domaines choisie par Apple, la requête est refusée avant d’atteindre le réseau. Pas de hit, pas de ligne de log chez le fournisseur, rien à modéliser.

Je voulais comprendre le mécanisme : j’ai lu les commits WebKit qui implémentent le blocage et le bug public où The Trade Desk demande à Apple de le lever, et reproduit le comportement sur Safari 27.2 avec une page de test. Quand je relaie une trouvaille sans l’avoir vérifiée, je le dis.

La version courte

De « affamer le cookie » à « refuser la requête »

Les réflexes d’audit de la plupart d’entre nous datent de l’ancien monde. La référence Tracking Prevention de WebKit décrit les couches précédentes :

CoucheCe qu’elle faitLa requête part-elle ?
Blocage des cookies tiers« ITP by default blocks all third-party cookies. There are no exceptions to this blocking. »Oui, sans cookies
Défense contre le cloaking CNAME et IPLes cookies posés par réponse HTTP sont plafonnés à 7 jours quand un sous-domaine « first-party » résout vers un tiersOui
Blocage par politique de tracking de Safari 27Les requêtes cross-site vers les domaines listés sont refuséesNon

Chaque couche précédente dégradait la donnée. Celle-ci la supprime. Pour le diagnostic, la différence compte : un signal dégradé laisse une trace comparable, un signal absent laisse un trou qui ressemble à moins de trafic.

Ce que dit vraiment le code source de WebKit

WebKit est open source : le mécanisme est public, même si la liste ne l’est pas. Six commits racontent l’histoire.

DateCommitCe qu’il fait
13 fév. 2026307525@main (PR 58670)« Unconditionally block requests going to certain domains » : 11 lignes, la liste elle-même vit dans un fichier qu’Apple ne publie pas
2 juil. 2026bug 318165Simplifie la règle en « bloquer toute sous-ressource non main-frame dont la destination est un domaine ciblé » et supprime le verrou qui laissait passer la première requête
25 sept. 2026bug 324589Remplace la liste statique par une content rule list fournie par le framework WebPrivacy, rechargée à chaque mise à jour

Le commit de février est celui que tout le monde cite. Voici l’extrait utile de Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm :

#if !defined(IS_REQUEST_UNCONDITIONALLY_BLOCKABLE)
#define IS_REQUEST_UNCONDITIONALLY_BLOCKABLE(domain) false
#endif

// inside isRequestBlockable()
auto domain = WebCore::RegistrableDomain { URL { makeString("http://"_s, request.url().host()) } };
if (IS_REQUEST_UNCONDITIONALLY_BLOCKABLE(domain))
    return true;

La macro renvoie false dans le dépôt public : la vraie liste n’existait que dans le build interne d’Apple. Et le test porte sur le domaine enregistrable (eTLD+1) : lister adsrvr.org bloque tous ses sous-domaines d’un coup.

Les quatre conditions d’un blocage

Le commit du 25 septembre a réécrit la décision dans NetworkLoadChecker::shouldBlockForTrackingPolicy. Sans la plomberie :

if (parameters.isMainFrameNavigation)
    return false;                                   // 1. navigations are never blocked

if (!networkSession->isTrackingPreventionEnabled())
    return false;                                   // 2. tracking prevention must be on

if (RegistrableDomain(request.url()).matches(topOrigin->data()))
    return false;                                   // 3. same-site requests are exempt

if (!backend->shouldBlockLoad({ request.url(), m_mainDocumentURL, m_frameURL, resourceType, false, requestMethod }))
    return false;                                   // 4. the URL must match the rule list

return true;                                        // blocked by tracking protections

La liste est devenue modifiable à distance le 25 septembre

Le message de commit dit : « This patch replaces the static domain list in the network process with a content rule list that WebPrivacy provides. […] It caches the list, sends it to the network process, and reloads it when WebPrivacy posts an update. » Avant, changer la liste exigeait de livrer un build ; après, elle est de la donnée. Une content rule list peut aussi cibler des motifs d’URL, des types de ressources et des méthodes, donc être plus chirurgicale qu’un domaine entier, ou plus large. La préférence qui commande tout, ScriptTrackingPrivacyNetworkRequestBlockingEnabled, vaut true par défaut.

Qui était sur la liste : le ticket de The Trade Desk

La liste est privée, mais une version est publique parce qu’un fournisseur l’a écrite. Le 21 septembre 2026, Ian Meyers de The Trade Desk a ouvert le bug WebKit 324771, priorité P1, contre Safari 27 sur iOS 27, avec neuf entrées :

DomainePropriétaireRôle
uidapi.comUnified ID 2.0Identité
adsrvr.orgThe Trade DeskRequêtes et diffusion publicitaires
id5-sync.com, eu-1-id5-sync.comID5Identité
rlcdn.com, pippio.comLiveRampIdentité
permutive.comPermutiveDonnées d’audience
ad.gtAudigentDonnées d’audience
tainted.exampleAppleDomaine de test

Son argument : adsrvr.org, domaine cœur de diffusion de l’entreprise, n’a pas sa place sur une liste visant l’identité « post-cookie ». Selon AdExchanger le 29 septembre, The Trade Desk ne pouvait plus diffuser dans Safari sur iOS 27, sorti le 14 septembre. John Wilander, de l’équipe WebKit d’Apple, a répondu le lendemain, renvoyé vers une bêta d’iOS 27.2 le 5 octobre et marqué le bug résolu le 9 octobre. La résolution ne couvre qu’un domaine, pas les huit autres.

Ce que j’ai mesuré sur Safari 27.2

Lire du code dit ce qui peut arriver ; je voulais voir ce qui arrive. J’ai construit une petite page de test, servie en local et ouverte dans une fenêtre Safari normale aux réglages par défaut, qui appelle une liste d’hôtes par un fetch cross-site en mode no-cors. Une requête bloquée est rejetée ; une requête qui part est résolue, quelle que soit la réponse du serveur. Pour écarter un problème réseau, j’ai appelé les mêmes hôtes en ligne de commande hors navigateur. La machine tourne sous macOS 27.2 avec Safari 27.2, la ligne bêta qui porte le correctif Trade Desk.

HôteSafari 27.2DuréeHors navigateur
prod.uidapi.comLoad failed5 msRépond
id5-sync.comLoad failed0 msRépond
cdn.permutive.comLoad failed1 msRépond
match.adsrvr.orgSent294 msRépond
ad.doubleclick.netSent310 msRépond
www.google-analytics.comSent482 msRépond
connect.facebook.netSent570 msRépond
snap.licdn.comSent698 msRépond

Trois lectures :

Limites : un seul appareil, macOS et non iOS, un build bêta, une page servie depuis 127.0.0.1.

Ce que cela casse, et pour qui

Safari pèse environ 18,2 % de l’usage mondial (Statcounter, septembre 2026), et ce chiffre sous-estime la surface : sur iOS, hors Union européenne et Japon, tous les navigateurs reposent sur WebKit. Que Chrome ou Firefox sur iOS appliquent le même blocage, je ne l’ai pas testé.

Auditer votre site en dix minutes

  1. Collectez les hôtes que vos pages appellent : enregistrez une session Chrome (page produit, panier, confirmation), exportez le HAR et extrayez les hôtes tiers distincts, plus ceux que votre tag manager, votre CMP ou votre wrapper peuvent appeler.
  2. Testez-les dans Safari 27. Ouvrez une page locale vierge (pas votre site), pour que chaque hôte soit cross-site et que votre Content Security Policy n’interfère pas. Dans la console du Web Inspector :
const hosts = [
  'id5-sync.com',
  'ad.doubleclick.net',
  // paste your hosts here
];

const rows = [];
for (const host of hosts) {
  const start = performance.now();
  let result = 'sent';
  try {
    await fetch('https://' + host + '/?t=' + Date.now(), { mode: 'no-cors', cache: 'no-store' });
  } catch (error) {
    result = 'failed';
  }
  rows.push({ host, result, ms: Math.round(performance.now() - start) });
}
console.table(rows);

Lecture : Sent = la requête a quitté le navigateur ; Failed en moins de 10 ms = refusée localement (faites le contrôle) ; Failed après plusieurs secondes = timeout réseau, filtre DNS ou hôte mort, pas ce mécanisme.

  1. Faites le contrôle. Un échec rapide peut venir d’une extension de blocage ou d’un filtre DNS qui répond instantanément. Désactivez les extensions Safari pour le test et appelez le même hôte depuis un terminal avec curl -s -o /dev/null -w '%{http_code}' https://host/. Si le terminal reçoit un statut HTTP et que Safari échoue en quelques millisecondes, c’est bien le navigateur qui refuse.
  2. Confirmez dans vos rapports. Segmentez la métrique touchée par navigateur et par version d’OS. La signature est étroite : Safari sur iOS 27 ou macOS 27, à partir du jour de la mise à jour de vos utilisateurs, les autres navigateurs restant stables. Réconciliez avec un système indépendant du navigateur, comme les commandes du back office (voir Why GA4, SFCC and Offline Orders Will Never Match). Refaites le test après chaque mise à jour de Safari : la liste est de la donnée, la réponse a donc une date d’expiration.

Ce qui part encore

Retour aux quatre conditions : deux sont des exemptions écrites dans le code, et elles définissent ce qui survit.

L’architecture qui survit est donc celle vers laquelle beaucoup d’équipes migrent déjà : un endpoint de collecte first-party sur votre propre domaine, un serveur de tagging derrière, et des API fournisseurs appelées depuis ce serveur. Le consentement s’applique toujours : ne transmettez que ce que l’utilisateur a accepté.

Ce qui ne règle rien

Protection de la vie privée ou contrôle d’accès ?

Il y a deux lectures honnêtes, et vous croiserez les deux en réunion. La première est la position ancienne d’Apple : l’identité cross-site construite à l’insu de l’utilisateur est précisément ce que la prévention du tracking doit stopper, et les identifiants conçus pour remplacer les cookies tiers en sont une version rebaptisée. Vue ainsi, la liste, c’est ITP qui termine son travail.

La seconde, défendue par l’avocat Alan Chapell dans un essai pour Marketecture (des arguments, pas des faits établis) : hors UE, tous les navigateurs iOS tournent sur le moteur d’Apple ; la liste est secrète et unilatérale ; Google semble en être absent ; Apple construit sa propre activité publicitaire.

Ma lecture reste proche de ce qui se démontre : le code est public et les conditions sont étroites, la liste est privée et mise à jour sans version d’OS, et la seule version connue incluait le domaine de diffusion d’un concurrent, retiré en bêta trois semaines après la sortie. Planifiez pour le mécanisme, pas pour l’intention.

Ce que je n’ai pas pu vérifier, et ce qu’il faut surveiller

À surveiller : la forme de la liste (reste-t-elle sur l’identité, ou glisse-t-elle vers la diffusion et la mesure ?) et son rythme, maintenant qu’une mise à jour n’exige plus de release.

Sources

Pour aller plus loin, lisez la version complète de l’article (en anglais) : Safari 27 Blocks Adtech Domains at the Network Layer: What the WebKit Source Says, What I Measured, and How to Audit Your Site.

Besoin d’aide sur ce sujet ? Consent Mode v2 et CMP.

Vous doutez de votre tracking ?

Réserver un appel Ou commencez par l’audit analytics gratuit →