Contexte et découverte

En juillet 2025, un domaine autrefois exploité par un réseau de diffusion de contenu (CDN) a été réenregistré après plusieurs années d’inactivité. Le CDN avait été arrêté, son nom de domaine laissé expirer, mais les références codées en dur vers les sous‑domaines de ce domaine persistaient dans plus de quelques milliers de sites web, dépôts de code et pages de documentation. Le nouveau propriétaire a configuré un enregistrement DNS générique (wildcard) couvrant l’ensemble du domaine, de sorte que toute requête vers *.exemple-cdn.com résout vers l’infrastructure qu’il contrôle. La page d’accueil du domaine sert aujourd’hui un simple téléchargeur de médias chargé de publicités, mais le véritable risque réside dans le contrôle du contenu chargé par les sites tiers.

Mécanisme d’exploitation via scripts tiers

Le problème n’est pas isolé. En juin 2024, le domaine polyfill.io, intégré via une balise dans plus de 110 000 sites, a changé de propriétaire et a commencé à renvoyer des redirections conditionnelles vers des ressources mobiles. Aucun site n’a été compromis ; ils avaient simplement externalisé un il y a des années et n’ont jamais revu la décision. Ces scénarios illustrent une faille de la chaîne d’approvisionnement côté client : le code tiers est récupéré par le navigateur depuis un serveur hors du contrôle de l’organisation, ce qui rend les analyses de dépendances et les scanners de composition logicielle inefficaces. Le script peut varier selon la géolocalisation, l’agent utilisateur ou l’heure, de sorte qu’un crawler basé sur un centre de données peut voir un fichier propre tandis qu’un utilisateur mobile dans un autre pays reçoit un payload malveillant.

Réponse avec Content Security Policy

Le navigateur reste le seul observateur fiable. Une politique de sécurité du contenu (CSP) peut restreindre quels scripts sont autorisés à s’exécuter et générer des rapports lorsqu’une violation survient. En mode Content-Security-Policy-Report-Only, aucune requête n’est bloquée ; le serveur reçoit uniquement des rapports détaillant les tentatives d’exécution non autorisées. Cette approche permet de cartographier l’inventaire réel des scripts exécutés, souvent bien plus étendu que prévu. Un exemple de configuration CSP en mode rapport :

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://trusted.cdn.com; report-uri https://csp-report.example.com/report

Les alertes issues de ces rapports proviennent de sessions réelles, incluant les utilisateurs situés dans des pays spécifiques ou utilisant des réseaux mobiles, ce qui rend la détection de comportements ciblés possible.

Implications réglementaires et bonnes pratiques

Depuis le 31 mars 2025, les exigences PCI DSS v4.0.1 (sections 6.4.3 et 11.6.1) imposent la validation de chaque script présent sur une page de paiement, la tenue d’un inventaire signé et la mise en place d’un mécanisme d’alerte sur toute modification non autorisée. Les plateformes comme Report URI offrent un moyen de satisfaire ces exigences en fournissant à la fois l’inventaire, les preuves d’audit et les alertes en temps réel. Une analyse de dix ans de crawls quotidiens du million de sites les plus visités montre une hausse de plus de 12 000 % de l’adoption de CSP, reflétant le besoin croissant de visibilité sur le code exécuté côté client. En pratique, les organisations doivent déployer d’abord un mode rapport, collecter les données pendant une semaine, établir un inventaire, puis affiner la politique pour bloquer les sources non approuvées. Cette démarche réduit le risque de scénarios comme celui du CDN réenregistré, où un tiers peut injecter du code malveillant sans jamais toucher les serveurs de l’entreprise.