Comprendre les attaques XSS : dangers, types et protections essentielles

XSS-attaque (Cross-Site Scripting) désigne une vulnérabilité des applications web, permettant à un attaquant d'exécuter son propre code JavaScript dans le navigateur d'un autre utilisateur. Le serveur du site peut continuer à fonctionner normalement : le problème vient d'un traitement incorrect des données, qui permet au navigateur de les interpréter comme partie intégrante de la page ou comme code exécutable.

Grâce à une XSS, il est possible de modifier le contenu d'un site, d'afficher de faux formulaires, d'effectuer des actions au nom de l'utilisateur et d'accéder à une partie des informations disponibles sur la page. Le danger s'accroît car le code malveillant s'exécute à l'intérieur même du site légitime et a donc les mêmes droits que le JavaScript authentique de cette page.

Qu'est-ce qu'une attaque XSS et pourquoi parle-t-on de " cross-site scripting " ?

Le cross-site scripting, ou script intersites, survient lorsqu'un site intègre des données utilisateur non fiables dans une page HTML sans les échapper correctement ou sans traitement sécurisé. Une chaîne censée s'afficher comme du texte ordinaire peut alors être interprétée par le navigateur comme du HTML ou du JavaScript.

Prenons l'exemple classique d'un site de commentaires. L'utilisateur saisit un message ; le serveur le stocke puis l'affiche à d'autres visiteurs. Si l'application insère ces données dans le HTML sans vérification, un attaquant peut injecter une construction qui obligera le navigateur à exécuter du JavaScript au lieu d'afficher du texte.

En résumé, une XSS revient à mélanger données et instructions. L'utilisateur devrait pouvoir transmettre uniquement des informations : nom, commentaire, recherche... Mais à cause d'une erreur de développement, le navigateur traite une partie de ces données comme des instructions à exécuter.

Le terme cross-site scripting peut prêter à confusion : il ne s'agit pas toujours de transférer un script d'un site à un autre. Le principal signe d'une XSS est l'exécution de code non fiable dans le contexte d'une page en laquelle l'utilisateur a confiance.

Différence entre XSS et piratage classique d'un site

Lors d'un piratage classique, l'attaquant tente d'accéder au serveur, à la base de données, au panneau d'administration ou au système de fichiers. Avec une XSS, la cible principale devient le navigateur du visiteur.

L'attaquant n'a pas besoin de prendre le contrôle total du serveur. Il lui suffit de trouver un emplacement où le site insère de façon non sécurisée des données externes dans la page. Lorsque la victime ouvre cette page, le code malveillant s'exécute dans son navigateur.

La XSS diffère donc, par exemple, de l'injection SQL. Dans une injection SQL, des données mal traitées se retrouvent dans une requête base de données ; avec la XSS, elles deviennent du code exécutable côté navigateur. Les deux attaques sont liées à une gestion non sécurisée de données non fiables, mais elles ciblent des parties différentes de l'application web.

Pour en savoir plus sur la sécurité côté serveur, consultez l'article Comprendre l'injection SQL : risques, types et protections.

Comment fonctionne une attaque XSS et comment le JavaScript malveillant arrive sur la page ?

Une attaque XSS commence lorsque l'application web reçoit des données d'une source non fiable : commentaire, recherche, paramètre d'URL, nom d'utilisateur, etc. Si le site insère ces données dans la page sans traitement sécurisé, le navigateur peut les interpréter comme du HTML ou du JavaScript au lieu de texte.

L'erreur clé survient lors de la génération de la page. Le serveur ou le code JavaScript côté client prend la valeur reçue et la place là où le navigateur attend du code ou du balisage. Résultat : les données spécialement préparées peuvent modifier la structure du document et forcer le navigateur à exécuter des instructions imprévues.

Le navigateur ne peut pas distinguer le code écrit par le développeur du site de celui injecté par l'attaquant. Si du JavaScript se retrouve dans la page et n'est pas bloqué par des mécanismes de sécurité, il s'exécute dans le contexte du site visité.

Du champ de saisie à l'exécution du script

La chaîne typique commence par un formulaire ou un paramètre de requête. L'utilisateur envoie des données, l'application les accepte puis les réinsère dans la page HTML. En cas de traitement correct, les caractères spéciaux sont convertis pour que le navigateur les affiche comme texte.

Sans échappement, le contenu peut modifier la structure HTML. Le navigateur analyse alors la page en tenant compte des éléments et gestionnaires d'événements injectés. Le vrai problème n'est pas la simple présence de données utilisateurs, mais le contexte et la façon dont elles sont affichées.

Parfois, il n'est même pas nécessaire de stocker les données côté serveur. Il suffit que l'application prenne une valeur de la barre d'adresse ou d'une autre source du navigateur et l'ajoute de façon non sécurisée au DOM. Ainsi, la XSS existe à la fois sur les sites traditionnels à rendu serveur et dans les applications web modernes construites principalement en JavaScript.

Que peut faire un JavaScript malveillant ?

Les possibilités d'une XSS dépendent du site et des paramètres du navigateur. Un script malveillant peut lire le contenu de la page, modifier l'interface, surveiller les actions de l'utilisateur et envoyer des requêtes au nom de l'onglet ouvert.

Par exemple, un attaquant peut remplacer une partie de l'interface par un faux formulaire de connexion ou tout autre élément ressemblant à l'original. Cette substitution passant par le site réel, l'utilisateur ne voit souvent pas la supercherie.

De plus, le JavaScript peut agir avec les mêmes droits que la page courante. Si l'utilisateur est déjà connecté, le navigateur envoie automatiquement ses données de session lors des requêtes au même site. Ainsi, la XSS peut servir à lire des informations ou à agir au nom de la victime.

XSS et vol de session

Un des scénarios les plus connus concerne les cookies de session. Après authentification, le site fournit au navigateur un identifiant de session pour éviter à l'utilisateur de saisir son mot de passe à chaque requête.

Si ce cookie est accessible via JavaScript, une attaque XSS réussie peut permettre à l'attaquant de le récupérer et de l'envoyer vers un serveur externe. Ce jeton peut alors être utilisé pour usurper l'identité de la victime sans connaître son mot de passe.

Les sites modernes réduisent ce risque avec l'attribut HttpOnly, qui interdit à JavaScript d'accéder au cookie protégé. Cela ne supprime toutefois pas la XSS en tant que telle : le code malveillant peut toujours interagir avec la page et effectuer certaines actions via le navigateur de l'utilisateur. La protection des sessions doit donc compléter l'élimination de la vulnérabilité, pas s'y substituer.

Types d'attaques XSS : Stored, Reflected et DOM XSS

Les principaux types de XSS se distinguent par la manière dont le code malveillant s'introduit dans la page et à quel moment il s'exécute. On distingue généralement : XSS stockée (Stored), XSS réfléchie (Reflected) et DOM XSS. Pour l'utilisateur, le résultat est identique : un script étranger s'exécute dans son navigateur, mais la cause et la livraison du code diffèrent.

XSS stockée (Stored XSS)

La XSS stockée survient lorsque des données malveillantes sont enregistrées côté site puis affichées automatiquement à d'autres utilisateurs. Cela peut provenir d'un commentaire, d'un message, d'une description de profil ou de tout champ stocké en base de données.

Le danger ici, c'est que l'attaquant n'a pas besoin d'envoyer un lien spécial à chaque victime. Il lui suffit d'insérer le fragment malveillant une fois : tous les visiteurs de la page vulnérable y seront exposés.

C'est pourquoi la XSS stockée est souvent considérée comme la plus grave. Si la page vulnérable est populaire, un script enregistré peut toucher un très grand nombre d'utilisateurs.

XSS réfléchie (Reflected XSS)

La XSS réfléchie fonctionne différemment. Les données malveillantes ne sont pas sauvegardées en base, mais transmises via une requête et immédiatement renvoyées dans la page générée.

Par exemple, un site affiche une recherche directement dans le titre du résultat ou insère un paramètre d'URL dans un message d'erreur. Sans échappement correct, une requête habilement formée peut entraîner l'exécution de JavaScript.

Ce type d'attaque nécessite généralement d'inciter l'utilisateur à ouvrir un lien préparé ou à effectuer une certaine action. La XSS réfléchie est donc souvent associée à de l'ingénierie sociale ou du phishing.

DOM XSS

La DOM XSS se produit directement dans le navigateur et dépend de la façon dont le JavaScript côté client traite les données. Le serveur peut avoir généré une page parfaitement sûre : la vulnérabilité apparaît après le chargement.

Par exemple, un script récupère une valeur dans l'URL, la partie après " # ", un paramètre de requête... et l'insère de façon non sécurisée dans la page. Si une opération permet d'interpréter la chaîne comme du HTML, l'attaquant peut modifier le DOM et exécuter du code.

La différence majeure est que le problème réside dans la logique cliente. La chaîne malveillante n'est parfois jamais envoyée au serveur, ce qui complique la détection via les journaux côté serveur.

XSS stockée implique des données enregistrées, XSS réfléchie un renvoi immédiat côté serveur, et DOM XSS un traitement non sécurisé dans le navigateur. Dans tous les cas, la cause est la même : l'application permet à des données non fiables d'entrer dans un contexte où le navigateur peut les exécuter comme code.

Pourquoi une XSS est-elle dangereuse pour les utilisateurs et les propriétaires de site ?

Le danger de la XSS, c'est que le code malveillant s'exécute au sein même du site légitime, en qui l'utilisateur a confiance. Visuellement, la page peut sembler normale, alors que le navigateur exécute déjà des actions non prévues par les développeurs.

Les conséquences varient selon l'application. Sur un site, la XSS peut se limiter à modifier l'interface ; sur un autre, elle peut permettre d'effectuer des requêtes au nom de l'utilisateur authentifié ou d'accéder à des données sensibles.

Vol de données et actions au nom de l'utilisateur

Un JavaScript malveillant peut lire les informations présentes sur la page, surveiller les interactions avec l'interface et envoyer des données à un serveur externe. Les pages d'espace personnel, d'administration ou de services internes sont particulièrement exposées.

Si l'utilisateur est connecté, le navigateur considère toujours le site comme de confiance et peut transmettre automatiquement les données de session avec les requêtes. Le script malveillant peut donc initier certaines actions au nom de la victime, même si l'identifiant de session est protégé contre la lecture directe.

Substitution de l'interface du site

La XSS permet de modifier le DOM, donc l'attaquant peut ajouter de nouveaux éléments ou en remplacer d'autres. Il peut afficher une fausse fenêtre de connexion, un message réclamant de ressaisir le mot de passe, ou un bouton menant vers un site externe.

Ce type de substitution est d'autant plus dangereux qu'il se déroule sur le domaine réel. L'utilisateur voit l'adresse familière et peut ne pas remarquer que l'interface a été modifiée par un script injecté.

Une XSS peut aussi servir à changer des liens, masquer des avertissements, remplacer le contenu des pages ou rediriger l'utilisateur vers un autre site. Dans certains cas, l'attaque est une étape supplémentaire d'une campagne de phishing.

Pourquoi la XSS reste dangereuse même sur un site HTTPS

La présence de HTTPS ne protège pas contre la XSS. HTTPS chiffre la connexion entre le navigateur et le serveur, empêchant l'interception ou la modification du trafic en cours de route, mais il ne garantit pas la sécurité du JavaScript présent dans la page elle-même.

Si le serveur du site légitime a généré une page contenant un script injecté, ou si le code client a créé un DOM vulnérable, le navigateur recevra ces données via une connexion HTTPS totalement sécurisée... et les exécutera quand même.

C'est la différence fondamentale entre la XSS et l'interception de trafic (Man in the Middle). Dans le cas d'une attaque MITM, l'attaquant s'immisce dans la communication ; pour la XSS, le code malveillant s'insère dans une page de confiance. Pour approfondir ce sujet, consultez l'article Comment fonctionne une attaque " Man in the Middle " et comment s'en protéger.

Comment protéger son site contre la XSS ?

La défense contre le script intersites repose sur un principe fondamental : les données reçues d'un utilisateur ou d'une source externe ne doivent jamais être considérées automatiquement comme sûres. L'application doit contrôler où elles sont utilisées et comment le navigateur les interprète.

Une vérification universelle ne suffit pas. Une protection efficace combine généralement : échappement correct à l'affichage, gestion sécurisée du DOM, restrictions d'exécution de scripts et mesures additionnelles pour protéger les sessions.

Échappement à l'affichage

La principale mesure anti-XSS consiste à afficher les données utilisateur comme du texte, jamais comme du code HTML. Si une personne saisit un commentaire, un nom ou une recherche, le navigateur doit traiter les caractères spéciaux comme du texte et non comme du balisage.

Le mode d'échappement dépend du contexte : HTML, attribut, URL ou chaîne JavaScript exigent des traitements différents. L'erreur survient quand l'application emploie un mode unique ou insère directement des valeurs non traitées dans la page.

Les moteurs de template et frameworks récents échappent souvent les sorties automatiquement. Mais cette protection disparaît si le développeur la désactive ou insère manuellement du HTML non filtré.

Validation et nettoyage des données

La validation limite le format des données d'entrée. Par exemple, un champ âge ne doit pas accepter de balises HTML, et un nom de fichier ne doit pas contenir de séquences de contrôle.

Si l'application doit accepter du HTML (éditeur d'articles, commentaires formatés...), l'interdiction des caractères spéciaux ne suffit plus. On applique alors un nettoyage : seuls certains tags et attributs sûrs sont autorisés, les éléments dangereux sont supprimés.

Mais le filtrage d'entrée ne remplace pas l'affichage sécurisé. Même des données bien vérifiées peuvent finir dans un autre contexte : la protection doit s'appliquer là où l'information est insérée dans la page.

Content Security Policy et gestion sûre du DOM

Un niveau de sécurité supplémentaire est offert par la Content Security Policy (CSP), qui permet de définir les sources autorisées pour charger et exécuter du JavaScript et de restreindre l'exécution de scripts non approuvés.

Une CSP bien configurée peut considérablement limiter l'impact d'une XSS, mais elle ne remplace pas la correction de la vulnérabilité elle-même. Si l'application continue à insérer des données utilisateur non filtrées, le problème subsiste.

Une vigilance particulière s'impose côté JavaScript client. Pour afficher du texte, il vaut mieux utiliser textContent que des méthodes qui interprètent les chaînes comme du HTML. Les méthodes comme innerHTML ne doivent être utilisées que si le contenu est parfaitement contrôlé ou préalablement nettoyé.

Protection des cookies et des sessions

Même si l'on ne peut totalement éliminer la XSS, il est possible d'en limiter les effets. Les cookies de session doivent utiliser l'attribut HttpOnly pour empêcher l'accès direct via JavaScript.

L'attribut Secure réserve la transmission des cookies aux connexions HTTPS, tandis que SameSite restreint leur envoi lors de requêtes cross-site. Ces mécanismes ne suppriment pas la XSS, mais compliquent certains scénarios de vol ou d'abus de session.

En pratique, une protection efficace est toujours multicouche : échappement des données à l'affichage, nettoyage du HTML potentiellement dangereux, code client évitant les opérations DOM à risque, CSP limitant l'exécution des scripts, et cookies protégés côté navigateur.

Conclusion

Une attaque XSS survient lorsqu'un site permet à des données non fiables de devenir du code exécutable dans le navigateur de l'utilisateur. Le JavaScript malveillant peut s'introduire via des données stockées, des paramètres de requête ou un traitement DOM non sécurisé, d'où la nécessité d'approches de détection différentes pour la XSS stockée, réfléchie et DOM.

La défense principale consiste à ne jamais mélanger données utilisateurs et HTML/JavaScript sans traitement sécurisé. Échappement à l'affichage, nettoyage du HTML autorisé, gestion prudente du DOM, Content Security Policy et cookies protégés doivent être combinés. Plus tôt l'application sépare les données du code exécutable, moins il y a de risques qu'un simple champ devienne un point d'entrée pour une attaque XSS.