La plupart des défenses contre l’injection de scripts agissent sur les données reçues par le serveur, mais une catégorie d’attaques échappe à cette surveillance : celles qui se jouent entièrement dans le navigateur, au moment où du code JavaScript écrit dynamiquement dans la page. C’est précisément le terrain des Trusted Types, un mécanisme récent qui force le code à ne manipuler que des valeurs explicitement marquées comme sûres avant de les insérer dans des emplacements dangereux. Plutôt que d’espérer que chaque développeur pense à nettoyer ses données, le navigateur impose lui-même la règle. Voyons ce que recouvre cette approche, comment elle s’applique concrètement, ce qu’elle protège, et comment l’adopter sans paralyser un code existant.

Les Trusted Types, définition d’une défense contre le DOM XSS

Les Trusted Types sont une fonctionnalité de sécurité des navigateurs qui empêche le code JavaScript d’insérer des chaînes de caractères brutes dans les points sensibles de la page. Ils visent une variété précise de failles de sécurité d’un site appelée DOM XSS, où l’injection ne passe jamais par le serveur. En exigeant des valeurs validées, ils transforment une bonne pratique facultative en règle obligatoire, appliquée par le navigateur lui-même.

Le DOM XSS, une menace qui échappe au serveur

Le DOM XSS se distingue des autres injections par le fait qu’il ne touche jamais le serveur. Une donnée issue de l’URL, d’un champ ou d’un message est directement écrite dans la page par du JavaScript, sans jamais faire l’aller-retour qui permettrait au serveur de la filtrer. L’attaque vit donc entièrement côté navigateur, dans l’angle mort des protections traditionnelles centrées sur les requêtes entrantes. Cette particularité rend le DOM XSS sournois et difficile à détecter. Les pare-feux applicatifs, qui inspectent le trafic réseau, ne voient rien passer puisque la donnée malveillante ne quitte pas le poste de l’internaute. C’est ce qui en fait un angle d’attaque privilégié pour qui cherche à contourner des défenses serveur par ailleurs solides, sur des applications modernes riches en JavaScript. Le problème s’aggrave avec la complexité des applications actuelles. Plus une page exécute de code pour construire son interface, plus elle multiplie les endroits où une donnée non fiable peut se glisser jusqu’à un point sensible. Cette surface d’écriture dynamique étendue est précisément ce que les Trusted Types cherchent à reprendre en main, en encadrant chacune de ces écritures.

Ce que change la notion de type de confiance

L’idée centrale des Trusted Types est de remplacer les chaînes brutes par des objets spéciaux, créés uniquement à travers des règles de validation que vous définissez. Là où le code écrivait directement du texte dans la page, il doit désormais fournir une valeur estampillée comme digne de confiance, faute de quoi le navigateur refuse l’opération et lève une erreur. Ce déplacement est subtil mais puissant. Le problème de sécurité passe d’une question diffuse (« cette chaîne est-elle dangereuse ? ») à une question nette et vérifiable (« cette valeur a-t-elle été validée ? »). En rendant la sûreté visible dans le type même de la donnée, on transforme une vigilance permanente et faillible en une garantie structurelle, contrôlée à chaque écriture. Cette approche par les types s’inspire d’un principe éprouvé en sécurité : rendre l’état sûr difficile à contourner par accident. Un développeur ne peut plus écrire une chaîne dangereuse par simple distraction, car le navigateur l’en empêche. La sécurité ne dépend alors plus de la mémoire de chacun mais d’une contrainte imposée par la plateforme, bien plus fiable à grande échelle.

Comment fonctionnent les Trusted Types dans le navigateur

Le fonctionnement des Trusted Types repose sur l’interception des écritures vers les emplacements sensibles du DOM. Comprendre ce mécanisme aide à voir précisément où la protection s’applique et pourquoi elle est si difficile à contourner une fois activée. Ce sujet complète notre précédent article : Cross-Site Scripting (XSS).

Les points d’injection et leur interception

Le navigateur connaît la liste des emplacements réputés dangereux, ceux qui interprètent une chaîne comme du code ou du balisage : l’écriture de HTML dans un élément, l’insertion de scripts, certaines manipulations d’URL. Ces points sont communément appelés des sinks. Les Trusted Types placent un contrôle à chacun de ces points, et bloquent toute valeur qui n’aurait pas été préalablement validée. Quand le mécanisme est actif, écrire une chaîne brute dans l’un de ces emplacements déclenche immédiatement une erreur. Le code doit obligatoirement passer par un objet de confiance, ce qui coupe la route habituelle du DOM XSS. L’attaquant qui parvenait à injecter une donnée dans la page se heurte désormais à un refus systématique au moment crucial de l’écriture. Cette interception est exhaustive par conception. Plutôt que de tenter de deviner quelles chaînes sont dangereuses, le navigateur considère toutes les écritures non validées comme suspectes. Ce refus par défaut de l’inconnu est la marque des défenses robustes, car il ne laisse aucune exception silencieuse par laquelle une attaque pourrait se faufiler discrètement.

Les politiques de création de valeurs sûres

Pour produire une valeur de confiance, le développeur définit une politique, c’est-à-dire une fonction qui reçoit la chaîne d’origine et renvoie une version validée ou nettoyée. C’est dans ces politiques que se concentre toute la logique de sécurité, ce qui rassemble en un seul endroit ce qui était auparavant éparpillé dans tout le code. Une application peut définir plusieurs politiques nommées, mais l’usage recommandé reste d’en limiter le nombre. Moins il y a de points où une valeur de confiance peut naître, plus il est facile de les auditer. Cette concentration volontaire des entrées simplifie énormément la revue de sécurité, qui se résume alors à vérifier un petit nombre de fonctions bien identifiées. Le tableau ci-dessous distingue les principaux types de valeurs encadrés par le mécanisme.

L’activation par l’en-tête CSP

Les Trusted Types ne s’activent pas tout seuls : ils se déclarent via la Content Security Policy, par une directive dédiée qui demande au navigateur d’exiger des valeurs de confiance. Ce rattachement à la CSP les inscrit dans la même logique d’en-têtes de sécurité que les autres protections modernes, déclarées côté serveur et appliquées côté client. La même CSP permet de restreindre les politiques autorisées, voire d’en imposer une seule. On peut ainsi interdire la création de nouvelles politiques non prévues, ce qui verrouille la liste des points de confiance et empêche un script malveillant d’en fabriquer une à son profit. La protection se referme alors complètement sur elle-même. Cette intégration présente un avantage opérationnel : la configuration vit au même endroit que le reste de votre politique de sécurité. Les équipes habituées à gérer la CSP retrouvent un terrain connu, et peuvent piloter les Trusted Types avec les mêmes outils, sans introduire un mécanisme de configuration entièrement séparé à maintenir en parallèle.

Pourquoi les Trusted Types renforcent réellement la sécurité de vos pages

Adopter les Trusted Types complète idéalement d’autres pratiques comme le nettoyage du HTML côté éditeur, en garantissant qu’aucune écriture non validée n’atteint le DOM. La protection ne repose plus sur la discipline de chaque développeur mais sur une règle appliquée sans exception par le navigateur, à chaque point sensible.

Éliminer une classe entière de vulnérabilités

L’intérêt majeur des Trusted Types est qu’ils ne corrigent pas une faille isolée, mais ferment toute une famille d’attaques d’un seul geste. Tant que le mécanisme est actif et bien configuré, le DOM XSS devient structurellement impossible sur les points couverts. On passe d’une chasse aux bugs sans fin à une garantie obtenue par construction, bien plus rassurante. Cette bascule a une valeur considérable pour les grandes applications. Auditer des milliers de lignes de JavaScript à la recherche d’écritures dangereuses est un travail interminable et jamais terminé. Imposer les Trusted Types rend cet audit largement superflu, puisque le navigateur refuse de lui-même ce que l’on cherchait péniblement à débusquer à la main. L’effet est d’autant plus précieux que le DOM XSS figure parmi les vulnérabilités les plus difficiles à éradiquer durablement. Chaque nouvelle fonctionnalité pouvait jusque-là réintroduire une faille. Avec les Trusted Types, cette régression silencieuse devient impossible, car tout code fautif se signale immédiatement par une erreur dès la phase de développement.

Centraliser et fiabiliser le contrôle

En concentrant toute la validation dans quelques politiques, les Trusted Types transforment la sécurité d’un problème diffus en un point de contrôle unique. C’est dans ces fonctions que l’on applique le nettoyage, que l’on choisit une bibliothèque de confiance, et c’est là, et là seulement, qu’une revue de sécurité doit porter son attention. Cette centralisation du contrôle réduit drastiquement le risque d’oubli. Cette organisation profite aussi à la maintenance dans le temps. Le jour où une faille est découverte dans une méthode de nettoyage, la corriger à un seul endroit protège instantanément toute l’application. On évite ainsi la situation classique où un correctif doit être répliqué dans des dizaines de fichiers, avec le risque permanent d’en oublier un au passage. Pour les équipes, cette clarté a une vertu pédagogique. Un développeur qui débute sur le projet comprend vite où se joue la sécurité des écritures, plutôt que de devoir intérioriser une multitude de règles tacites. La protection devient lisible et transmissible, ce qui la rend bien plus durable que des consignes orales qui se perdent au fil des départs et des arrivées.

Mettre en place les Trusted Types sans casser votre code

Déployer les Trusted Types sur une application existante demande de la méthode, car activer brutalement le mécanisme ferait échouer toutes les écritures non encore adaptées. L’approche raisonnable consiste à observer d’abord, puis à migrer progressivement le code vers les politiques de confiance.

Commencer en mode rapport

Comme pour les autres directives de la CSP, on commence par un mode d’observation qui signale les violations sans rien bloquer. Le navigateur recense alors toutes les écritures qui devraient passer par une politique, dressant un inventaire précis des points à adapter. On découvre ainsi l’ampleur réelle du chantier sans prendre le moindre risque pour les utilisateurs. Cette phase est précieuse car elle révèle souvent des écritures insoupçonnées, nichées dans des bibliothèques tierces ou de vieux scripts. Plutôt que de tout corriger en aveugle, on priorise selon la fréquence des violations remontées, en traitant d’abord les points les plus sollicités, là où le gain de sécurité est le plus immédiat. Le mode rapport sert aussi à mesurer l’effort avant de s’engager. En estimant le volume de code concerné, on planifie la migration de façon réaliste, étape par étape. Cette visibilité préalable sur le travail évite les déploiements précipités qui, en cassant des fonctionnalités, finiraient par discréditer toute la démarche auprès des équipes.

Définir les politiques et adapter le code

Le coeur de la migration consiste à créer une ou deux politiques de confiance et à rediriger vers elles toutes les écritures sensibles. On y intègre une bibliothèque de nettoyage éprouvée plutôt que d’écrire soi-même une validation, car réinventer un nettoyeur de HTML est une source d’erreurs bien connue. Mieux vaut s’appuyer sur des outils dont la robustesse a été démontrée. Le code applicatif est ensuite ajusté pour ne plus jamais écrire de chaîne brute dans un point sensible. Ce travail, fastidieux mais mécanique, se mène fichier par fichier en s’appuyant sur les violations remontées. Chaque écriture corrigée referme un peu plus la surface d’attaque, jusqu’à ce que plus aucune voie non contrôlée ne subsiste vers le DOM. Il faut prêter une attention particulière aux dépendances tierces, qui écrivent parfois directement dans la page. Lorsqu’une bibliothèque n’est pas compatible, on l’encapsule ou on la remplace, sans céder à la tentation de tout autoriser pour gagner du temps. Préserver l’intégrité de la protection vaut mieux qu’une exception commode qui rouvrirait la porte que l’on cherchait à fermer.

Passer en mode strict et surveiller

Une fois les violations résorbées, on bascule du mode rapport vers l’application stricte, qui bloque désormais toute écriture non conforme. Ce passage doit s’accompagner d’une surveillance attentive des premiers jours, le temps de confirmer qu’aucun parcours légitime n’a été oublié et que l’expérience des visiteurs reste intacte. La protection se maintient ensuite dans la durée, car chaque nouvelle fonctionnalité peut introduire une écriture non validée. Conserver la directive active et garder un oeil sur les rapports permet de détecter aussitôt une régression, qui se manifeste dès le développement plutôt que des mois plus tard sur un site déjà exposé. Le tableau suivant résume les étapes d’un déploiement progressif des Trusted Types.