Attaques XSS : la menace invisible dans le navigateur

Le XSS, en clair

Le cross-site scripting, c'est quand un attaquant pousse un site à injecter un script malveillant dans une page que d'autres utilisateurs vont consulter. Le navigateur fait confiance au script parce qu'il provient d'un domaine légitime. Le script s'exécute alors avec les droits de la victime et accède aux cookies, aux tokens de session, au contenu de la page ou aux éléments du DOM.

L'image, pour qui n'écrit pas de code tous les jours. Imagine un post-it collé sur le tableau d'affichage d'une entreprise. Si personne ne le modère, n'importe qui peut y accrocher de fausses consignes que les collègues vont suivre. Le XSS, c'est la version numérique : du contenu douteux glissé dans un cadre qu'on croit fiable.

Trois grandes familles (et quelques cas particuliers)

Distinguer les variantes aide à identifier vite une vulnérabilité. Il y a trois grandes familles, plus une poignée de cas particuliers qui réapparaissent encore dans des campagnes réelles.

Stored XSS. Le script malveillant est stocké côté serveur (base de données, CMS ou autre) puis servi à chaque visiteur. Les zones de commentaires et les systèmes de tickets support en sont les terrains classiques. L'impact est en général large, puisque chaque lecteur déclenche la payload.

Reflected XSS. Le script malveillant est renvoyé tel quel par le serveur dans la réponse immédiate, le plus souvent via des paramètres d'URL. La victime clique sur un lien piégé, le serveur recopie l'entrée dans la page et la payload s'exécute.

DOM-based XSS. La payload n'atteint jamais le serveur. Elle s'exécute entièrement dans le navigateur, en manipulant le DOM. Côté serveur, on ne voit parfois rien passer, d'où une détection plus difficile et une présence récurrente dans les rapports d'incident.

Le self-XSS (amener un utilisateur à coller un script dans la console) et la XS-Search (abuser des formulaires de recherche pour deviner un état) restent présents dans les attaques actuelles. Les parades rejoignent largement celles du XSS classique.

Le déroulé d'une attaque XSS, étape par étape

Suivre une chaîne d'exploitation typique permet de repérer les endroits où ajouter des garde-fous.

1. 1

   Trouver un point d'entrée

   L'attaquant repère un formulaire, un paramètre d'URL ou un champ stocké qui renvoie du contenu sans assainissement correct.
2. 2

   Préparer la payload

   Il écrit du JavaScript qui pique des cookies, modifie des éléments du DOM, charge un malware ou redirige le trafic.
3. 3

   Acheminer la payload

   Via un lien piégé, un compte compromis ou un contenu déjà stocké sur la plateforme.
4. 4

   Faire exécuter chez la victime

   Le navigateur fait confiance à la payload parce qu'elle est servie depuis un domaine légitime.
5. 5

   Exfiltrer ou rebondir

   Les scripts envoient les données volées vers les endpoints de l'attaquant, ou installent d'autres malwares.

Ce que les attaquants en tirent

Le XSS ne se réduit plus au defacement. Les campagnes actuelles s'en servent pour des attaques à fort impact, et quatre objectifs reviennent le plus souvent.

Détournement de session. On vole les tokens d'authentification pour se faire passer pour un utilisateur sur des portails bancaires, des dashboards admin ou des plateformes SaaS. La victime ne voit jamais passer le vol.

Vol d'identifiants. On injecte de faux formulaires de login, ou on bidouille ceux qui existent, pour récupérer identifiants et mots de passe directement dans le navigateur, avant même que le vrai formulaire ne soit envoyé.

Diffusion de malware. On charge des scripts distants qui déposent un ransomware ou un mineur de crypto. Redoutable dans les attaques sur la supply chain, quand un script tiers réputé fiable se retrouve compromis.

Ingénierie sociale. On réécrit du contenu ou on glisse des messages de chat pour pousser l'utilisateur vers une action à risque ou un virement. Quand le site auquel il fait confiance lui demande d'envoyer de l'argent, il envoie.

Cinq cas concrets, dans cinq secteurs

Ces incidents (tirés de divulgations publiques et de la presse spécialisée) donnent une idée de l'éventail des dégâts possibles.

Plateforme média (2024). Un XSS dans la modération des commentaires a permis aux attaquants de faire liker automatiquement des chaînes d'arnaque. La casse réputationnelle a été bien réelle : 7 % de chute des indicateurs de confiance des abonnés, plus une semaine de nettoyage.

Marketplace e-commerce (2023). Un reflected XSS dans les codes promo renvoyait les acheteurs vers des pages de checkout de phishing. Bilan : 4,1 millions de dollars de transactions frauduleuses avant que l'équipe ne repère le schéma.

Portail patient santé (2022). Un stored XSS dans la messagerie patient récupérait les cookies de session et exposait des résultats d'analyses. À la clé : une notification HIPAA et un règlement à 1,2 million de dollars.

Appli bancaire (2021). Un DOM-based XSS dans des widgets injectait des demandes de virement non autorisées. La réaction rapide du SOC a évité les pertes, mais l'incident a déclenché un audit réglementaire qui a duré des mois.

CMS gouvernemental (2020). Une vieille faille XSS dans un CMS legacy a rendu possible le defacement de communications municipales sur le COVID-19. Les dégâts se sont mesurés en confiance publique en pleine crise, pas en dollars.

Pourquoi le XSS résiste encore en 2025

Malgré les frameworks modernes, le XSS revient chaque année dans l'OWASP Top 10. Les raisons sont structurelles, pas techniques.

D'immenses bases de code reposent encore sur de la concaténation de chaînes et du templating dépassé. Les widgets tiers (pixels marketing, chatbots, analytics) ajoutent une surface d'attaque que l'équipe sécurité ne maîtrise pas. Les nouvelles équipes d'ingénierie héritent de patterns peu sûrs sans connaître les incidents passés qui ont façonné le code. Les scanners automatisés passent à côté des payloads DOM-based parce qu'ils analysent la sortie rendue côté serveur, pas le DOM réellement chargé, et les pentests manuels regardent souvent ailleurs.

Se protéger au quotidien

On ne va pas patcher tout internet, mais on peut limiter les dégâts. Quatre habitudes couvrent l'essentiel du risque réel.

Ouvre les liens douteux dans Browser.lol, histoire qu'aucun script ne tourne sur ta machine. Désactive les extensions de navigateur dont tu ne te sers pas, beaucoup élargissent la surface d'attaque XSS. Tiens ton navigateur à jour : une CSP (Content Security Policy) moderne bloque les scripts inline et bon nombre de techniques XSS classiques. Déconnecte-toi des sites sensibles quand tu ne les utilises pas, les cookies volés ne valent plus grand-chose dès que la session expire.

Checklist pour les dévs et les équipes sécu

Si tu construis ou maintiens des applis web, cinq contrôles donnent le meilleur retour sur effort.

Échapper la sortie selon le contexte. Les contextes HTML, JavaScript, URL et CSS demandent des règles d'escaping différentes. Une fonction "sanitize" générique passe presque toujours à côté d'une catégorie.

S'appuyer sur des frameworks avec assainissement intégré. React, Vue et Angular réduisent la manipulation directe du DOM et font de la voie sûre la voie par défaut.

Déployer une Content Security Policy. Restreins les sources de scripts et interdis l'inline dès que tu peux. La CSP fait partie des défenses au meilleur rapport efficacité-coût jamais embarquées dans un navigateur.

Utiliser des linters et des SAST orientés sécurité. Les plugins sécurité d'ESLint, Semgrep et SonarQube attrapent les patterns courants tôt, quand corriger ne coûte presque rien.

Planifier des revues de sécurité régulières. Intègre des labos de payloads XSS dans la QA et dans le scope du bug bounty. Avec Browser.lol dans la chaîne QA, tu peux faire tourner des PoC douteux sans mettre en danger les machines de tes dévs.

Contenir le script, garder la main sur le risque

Le XSS ne disparaîtra pas. La surface d'attaque grandit avec chaque widget, chaque pixel marketing et chaque intégration tierce. Mais tu n'es pas désarmé pour autant. Un code rigoureux évite les failles, une hygiène utilisateur proactive limite l'exposition, et les navigateurs virtuels font en sorte qu'un script malveillant qui s'exécute ne touche jamais ton matériel.

Considère chaque site inconnu comme un vecteur XSS potentiel. Navigue depuis un environnement isolé, garde identifiants et cookies bien cloisonnés, et pousse tes équipes à s'attaquer aux causes profondes. C'est comme ça qu'on empêche un script invisible de se transformer en incident à plusieurs millions.