Parmi les vulnérabilités web, peu sont aussi anciennes et aussi répandues que le Cross-Site Scripting. Le principe est redoutablement simple : un attaquant parvient à faire exécuter son propre code JavaScript dans le navigateur d’autres visiteurs, en l’injectant dans une page qui leur fait confiance. À partir de là, il peut voler des identifiants, détourner une session ou modifier ce que l’internaute voit, le tout sans que la victime ne se doute de rien. Comprendre comment cette injection opère est la première étape pour s’en défendre efficacement. Voyons ce que recouvre exactement le XSS, ses différentes formes, pourquoi il reste une menace majeure, et quelles pratiques permettent de le tenir à distance.

Le XSS (Cross-Site Scripting), définition d’une injection de script

Le Cross-Site Scripting, abrégé en XSS, est une faille de sécurité web qui permet à un attaquant d’insérer du code exécutable dans une page consultée par d’autres internautes. Le navigateur de la victime, incapable de distinguer ce script malveillant du code légitime du site, l’exécute avec les mêmes droits que la page elle-même, ce qui ouvre la voie à de nombreux abus.

Le principe de l’injection de script

Tout part d’un endroit où un site affiche une donnée fournie par l’utilisateur sans la traiter correctement : un commentaire, un champ de recherche, un paramètre d’URL. Si cette donnée contient du code et que la page l’insère telle quelle, le navigateur l’interprète comme une instruction plutôt que comme du simple texte, et l’exécute sans la moindre méfiance. La gravité tient à ce que ce code s’exécute dans le contexte du site visité, et non dans celui de l’attaquant. Il hérite donc de l’accès aux informations de la page, aux cookies et à la session de la victime. Cette usurpation du contexte de confiance est ce qui distingue le XSS d’une simple nuisance et en fait une porte d’entrée vers des actions lourdes de conséquences. Le scénario ne requiert aucune compromission du serveur ni vol de mot de passe. Il suffit que la victime visite une page piégée, parfois via un simple lien. C’est cette facilité de déclenchement qui explique la persistance du XSS au sommet des classements de vulnérabilités, des années après sa première description publique.

Les données non fiables comme porte d’entrée

Le coeur du problème est la confusion entre données et code. Tout ce qui provient de l’extérieur, formulaire, URL, en-tête, contenu importé, doit être considéré comme potentiellement hostile par défaut. Dès qu’une de ces sources se retrouve affichée sans précaution, elle devient un vecteur d’injection possible, quelle que soit son apparence anodine. Cette méfiance doit s’appliquer y compris aux données déjà stockées en base. Un contenu enregistré hier par un utilisateur peut très bien renfermer un script qui ne s’activera qu’au moment de son affichage. Considérer qu’une donnée est sûre parce qu’elle vient de sa propre base est une erreur fréquente, car cette base a pu être alimentée par une saisie malveillante. Le risque se déplace ainsi au gré des flux de données dans l’application. Plus une donnée non fiable circule loin de son point d’entrée avant d’être affichée, plus il devient difficile de garder en tête qu’elle reste dangereuse. Suivre le trajet des données jusqu’à leur affichage est précisément la discipline qui permet de repérer les points où une injection peut survenir.

Comment fonctionne une attaque XSS, type par type

On regroupe généralement les attaques de Cross-Site Scripting en trois grandes familles, selon le chemin que suit le code injecté. Les distinguer est utile, car chacune appelle des réflexes de protection légèrement différents. Ce sujet complète notre précédent article : Content Security Policy (CSP).

Le XSS réfléchi

Dans le XSS réfléchi, le code malveillant est renvoyé immédiatement par le serveur dans sa réponse, sans être stocké. L’attaquant glisse son script dans un paramètre, par exemple celui d’une recherche, puis pousse la victime à cliquer sur un lien piégé. La page renvoie alors la donnée injectée, et le navigateur exécute le script au passage, le temps d’un seul affichage. Cette forme repose entièrement sur l’ingénierie sociale, puisqu’il faut amener la cible à suivre un lien préparé. Elle reste néanmoins très répandue, car un lien se diffuse facilement par message ou par courriel. Sa nature éphémère la rend en outre discrète et difficile à tracer, l’attaque ne laissant aucune empreinte durable sur le site visé. La protection passe ici par un traitement systématique de toute donnée renvoyée dans la réponse. Dès lors qu’un paramètre se retrouve affiché, il doit être neutralisé avant d’atteindre la page. C’est cette vigilance sur les valeurs réfléchies qui ferme la porte à cette première famille, souvent la plus simple à exploiter pour un attaquant.

Le XSS stocké

Le XSS stocké est le plus dangereux des trois. Le code malveillant est enregistré durablement par le site, dans un commentaire, un profil ou un message, puis servi à chaque visiteur qui consulte la page concernée. Une seule injection réussie peut ainsi frapper tous les internautes qui passeront par là, sans aucune action de leur part. Cette persistance démultiplie l’impact. Là où le XSS réfléchi vise une victime à la fois, la version stockée peut toucher des milliers de personnes à partir d’un unique point d’injection. Sur une plateforme à fort trafic, elle se rapproche d’un ver capable de se propager, ce qui en fait la hantise des sites communautaires et des espaces de contenu généré par les utilisateurs. La défense exige de traiter la donnée à deux moments : lors de son enregistrement et lors de son affichage. Ne se fier qu’à un nettoyage à l’entrée laisse passer ce qui aurait été inséré par d’autres voies. Appliquer une protection au moment de l’affichage reste la garantie la plus fiable, car c’est là que le danger se concrétise réellement.

Le XSS basé sur le DOM

Le XSS basé sur le DOM se joue entièrement dans le navigateur, sans que le serveur ne voie jamais passer la donnée malveillante. Du JavaScript lit une valeur, souvent issue de l’URL, et l’écrit directement dans la page. Comme le serveur n’est pas impliqué, ses protections restent totalement aveugles à ce type d’attaque, qui prospère sur les applications très riches en code client. Cette variante gagne en importance à mesure que les sites déportent leur logique vers le navigateur. Les interfaces dynamiques modernes multiplient les écritures dans la page, et donc les occasions d’injection côté client. C’est précisément cette famille que des mécanismes comme les Trusted Types cherchent à neutraliser, en encadrant les écritures dans le DOM. Le tableau ci-dessous compare les trois grandes familles de XSS.

Pourquoi le XSS reste une menace majeure

Se protéger du Cross-Site Scripting va de pair avec d’autres mesures comme le nettoyage du HTML des contenus saisis, car une faille XSS peut réduire à néant des protections par ailleurs solides. Une fois le script attaquant exécuté, il agit avec les droits de la victime, ce qui en fait un tremplin vers des compromissions plus graves.

Vol de session et usurpation d’identité

L’usage le plus redouté du XSS est le vol de session. En accédant aux cookies ou aux jetons de la victime, l’attaquant peut se faire passer pour elle sans connaître son mot de passe. Il hérite alors de tous les droits du compte détourné, du simple profil jusqu’aux espaces d’administration, avec les dégâts que cela suppose sur un site sensible. Au-delà du vol pur, le script injecté peut agir directement au nom de la victime : publier, modifier des réglages, déclencher des opérations. L’utilisateur devient ainsi, à son insu, l’instrument involontaire de l’attaque, ses propres droits servant à commettre des actions qu’il n’a jamais voulues, parfois irréversibles. Ces capacités font du XSS un point de départ idéal pour des attaques en chaîne. Un compte compromis en sert à en compromettre d’autres, et l’incident initial se transforme en problème de grande ampleur. Cette capacité d’escalade explique pourquoi une faille XSS, même d’apparence mineure, est toujours traitée avec le plus grand sérieux par les équipes de sécurité.

Atteinte aux visiteurs et à la réputation

Le XSS ne nuit pas qu’au site : il frappe ses visiteurs, dont les données et les comptes se retrouvent exposés sur une plateforme à laquelle ils faisaient confiance. Ce sentiment de trahison pèse lourd, car l’internaute associe l’incident au site visité, pas à l’attaquant invisible. La confiance accordée à la marque en sort durablement entamée. Sur le plan de l’image, une attaque visible, défiguration de page ou redirection vers un contenu douteux, se remarque immédiatement et se partage vite. Les conséquences dépassent alors le seul cadre technique pour devenir un problème de communication délicat à gérer, surtout si l’attaque touche un service réputé sûr. S’ajoute une dimension réglementaire de plus en plus présente. Lorsqu’une faille XSS conduit à une fuite de données personnelles, l’éditeur s’expose aux obligations et aux sanctions prévues par les textes sur la protection des données. Prévenir le XSS relève donc autant de la conformité que de la sécurité technique pure.

Se protéger du XSS : les bonnes pratiques essentielles

Se prémunir du Cross-Site Scripting ne repose pas sur une mesure unique mais sur une superposition de défenses qui se complètent. Aucune n’est infaillible seule, mais leur combinaison rend l’injection extrêmement difficile à réussir.

Échapper et valider les données

La défense fondamentale consiste à échapper systématiquement toute donnée affichée, c’est-à-dire à neutraliser les caractères qui pourraient être interprétés comme du code. L’échappement doit être adapté au contexte d’affichage, car les règles diffèrent selon que la donnée apparaît dans du texte, un attribut ou du JavaScript. Cet échappement contextuel rigoureux est la pierre angulaire de toute protection. La validation des entrées vient en renfort, en refusant d’emblée les données qui ne correspondent pas au format attendu. Un champ censé contenir un numéro n’a aucune raison d’accepter des balises. Réduire ainsi ce que l’application accepte limite la matière première disponible pour une injection, sans pour autant remplacer l’échappement à l’affichage. Lorsqu’un site doit autoriser du contenu riche, comme un texte mis en forme, le simple échappement ne suffit plus. Il faut alors recourir à un nettoyage qui ne conserve qu’une liste blanche de balises et d’attributs sûrs. S’appuyer sur une bibliothèque de nettoyage reconnue vaut infiniment mieux que d’écrire ce filtrage soi-même, exercice notoirement piégeux.

CSP et en-têtes en défense de profondeur

Même avec un échappement soigné, une erreur reste toujours possible, et c’est là qu’intervient la Content Security Policy. En restreignant les sources de scripts autorisées, elle empêche l’exécution d’un code injecté qui aurait franchi les premières barrières. La CSP joue ainsi le rôle d’un filet de sécurité ultime, qui rattrape les oublis inévitables. D’autres en-têtes et réglages complètent ce dispositif. Marquer les cookies de session comme inaccessibles au JavaScript, par exemple, prive l’attaquant de sa cible favorite même en cas d’injection réussie. Ces mesures forment une succession de barrières indépendantes, chacune réduisant un peu plus la portée d’une attaque qui passerait la précédente. Pour les écritures côté navigateur, les Trusted Types ajoutent une couche spécifiquement dédiée au DOM XSS. Combinés à la CSP, ils complètent la défense là où l’échappement serveur n’a pas de prise. Cette stratégie en couches successives est précisément ce qui distingue une protection sérieuse d’une simple mesure isolée, toujours contournable.

Tester et maintenir la protection

Une protection contre le XSS se vérifie régulièrement, à l’aide d’outils d’analyse automatisée et de tests d’intrusion ciblés qui tentent d’injecter du code dans chaque point d’entrée. Ces contrôles révèlent les oublis avant qu’un attaquant ne les trouve, et transforment la sécurité en démarche active plutôt qu’en pari sur la perfection du code. La vigilance doit accompagner toute la vie de l’application, car chaque nouvelle fonctionnalité ajoute des points d’affichage potentiels. Intégrer la question du XSS aux revues de code et aux tests avant chaque mise en production évite de réintroduire une faille que l’on avait pris soin de fermer auparavant. Le tableau suivant récapitule les couches de protection contre le XSS.