SaaSFort Demandez à un éditeur SaaS comment il détecterait qu’un script tiers de son application a été modifié. La plupart des réponses tombent dans trois catégories.
« Nous n’utilisons que des prestataires réputés. » C’est de la sélection de fournisseurs, pas de la détection.
« Nous avons une CSP. » Une CSP autorise cette origine. Le script modifié arrive exactement d’où la politique dit que les scripts peuvent venir.
« Nous revoyons nos dépendances. » Cela couvre ce que vous construisez, pas ce qu’un CDN sert.
La réponse honnête, pour la plupart des éditeurs, est qu’ils ne le sauraient pas.
Pourquoi cette attaque passe tous les contrôles habituels
Déroulons ce qui se produit quand un CDN servant votre analytics ou votre widget de support est compromis et commence à servir du JavaScript modifié.
| Contrôle | État pendant l’attaque |
|---|---|
| TLS | Valide. La connexion est correctement chiffrée. |
CSP script-src | Passe. L’origine est en liste blanche. |
| Authentification | Non affectée. L’utilisateur est légitimement connecté. |
| WAF | Ne voit rien. La requête va du navigateur au CDN, sans toucher votre infrastructure. |
| Analyse de dépendances | Ne voit rien. Ce n’est pas dans votre package.json au moment du build. |
| Pentest du trimestre dernier | A testé le script qui était là en juin. |
Le script s’exécute dans votre origine, avec accès à votre DOM, vos formulaires et tout jeton atteignable depuis JavaScript. C’est un chemin crédible vers un vol massif d’identifiants, et il a été utilisé ainsi à plusieurs reprises.
La raison pour laquelle il échappe à tout est structurelle : chacun des contrôles ci-dessus valide la provenance ou le transport, et aucun ne valide le contenu.
Le contrôle qui valide le contenu
Subresource Integrity. Vous publiez l’empreinte du fichier que vous avez approuvé, le navigateur calcule celle de ce qu’il a reçu, et une divergence empêche l’exécution du script.
<script src="https://cdn.example.com/widget.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
Cela fonctionne, avec un défaut sans rapport avec la cryptographie : c’est facultatif, balise par balise. Le script que quelqu’un ajoutera le trimestre prochain sans attribut integrity n’est pas protégé, et une couverture SRI partielle ne protège rien, car il suffit à l’attaquant d’un seul script non protégé.
La couverture se dégrade par défaut. Ce n’est pas un problème de discipline, c’est ce qui arrive à tout contrôle dont l’application repose sur la mémoire de chacun, pour toujours.
Rendre le contrôle structurel
Integrity-Policy déplace l’exigence de la balise vers la page. Le navigateur bloque alors tout script arrivant sans métadonnées d’intégrité, y compris celui ajouté le trimestre prochain.
Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint)
Reporting-Endpoints: integrity-endpoint="https://example.com/_reports/integrity"
Le piège à anticiper : il n’existe aucune exemption pour la première partie. Vos propres bundles ont aussi besoin de métadonnées d’intégrité, ce qui est un changement de chaîne de build et non d’en-tête. Déployez d’abord Integrity-Policy-Report-Only, traitez la liste de violations obtenue comme votre inventaire, et appliquez une fois qu’elle est vide.
Le chemin de déploiement complet et le support navigateur.
Répondre à la question dans un questionnaire
L’écart entre une réponse faible et une réponse forte est ici inhabituellement large, car la plupart des concurrents donnent la faible.
Faible : « Nous utilisons des prestataires tiers réputés et les revoyons annuellement. »
Forte :
Les scripts tiers sont épinglés par des empreintes Subresource Integrity générées au build.
Integrity-Policyest appliqué par le navigateur, donc tout script servi sans métadonnées d’intégrité est bloqué plutôt qu’exécuté silencieusement, y compris ceux ajoutés récemment. Les violations remontent vers un point de collecte interne qui déclenche une alerte. Notre CSP utilise nonce plusstrict-dynamicplutôt qu’une liste blanche d’origines, donc une origine autorisée compromise n’est pas automatiquement de confiance.
Quatre mécanismes distincts, chacun vérifiable, et cela répond directement à la question de détection plutôt qu’à celle de sélection.
L’obligation derrière la question
Ce n’est pas qu’une affaire de bonne pratique. La sécurité de la chaîne d’approvisionnement est une obligation explicite :
- NIS2 article 21(2)(d), sécurité de la chaîne d’approvisionnement, y compris les aspects de sécurité des relations avec les fournisseurs directs. Où la plupart des éditeurs ont un trou.
- NIS2 article 21(2)(g), hygiène informatique de base.
- ISO/IEC 27001:2022 A.5.21, gestion de la sécurité dans la chaîne d’approvisionnement TIC, et A.8.28, développement sécurisé.
- DORA article 28, risque lié aux tiers TIC, où l’exigence est contractuelle autant que technique.
Le cadrage réglementaire est passé de « choisissez de bons fournisseurs » vers « démontrez que vous détecteriez la défaillance d’un fournisseur ». L’application de SRI est l’un des très rares contrôles qui répond à la seconde formulation par un mécanisme technique plutôt que par un document de processus.
Comment cela s’articule avec un SBOM
Un SBOM dit de quoi vous dépendez. L’application de l’intégrité dit que ce qui a été livré est ce que vous avez approuvé. Les deux sont complémentaires et fréquemment confondus.
Un SBOM n’aurait pas détecté un CDN compromis, car la liste de dépendances était correcte tout du long. C’est le fichier à cette URL qui a changé.
En résumé
Un script tiers compromis passe TLS, la CSP, l’authentification, votre WAF et votre analyse de dépendances, car tous vérifient d’où vient le code et aucun ne vérifie ce qu’il contient.
SRI vérifie le contenu. Integrity-Policy rend SRI impossible à oublier. Ensemble, ils constituent la seule réponse à « comment le sauriez-vous » qui soit un mécanisme plutôt qu’un espoir.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.