Un site vitrine d'un de mes clients s'était mis, du jour au lendemain, à rediriger certains visiteurs vers une page douteuse. La cause : un champ de commentaire qui acceptait n'importe quoi, y compris du code. C'est l'exemple type d'une faille XSS, l'une des vulnérabilités web les plus répandues. Une faille XSS permet à un attaquant d'injecter du code malveillant dans une page web, qui s'exécutera ensuite dans le navigateur des visiteurs. Concrètement, la vraie question pour qui gère un site n'est pas « est-ce que ça peut m'arriver », mais « est-ce que mon site filtre correctement ce que les utilisateurs y saisissent, car c'est là que tout se joue ».
Comprendre la XSS, c'est surtout comprendre comment s'en protéger. Ce texte explique le mécanisme et insiste sur la défense, sans fournir de mode d'emploi d'attaque. Posons le cadre.
Quel est le principe d'une faille XSS ?
XSS signifie « Cross-Site Scripting ». Le principe : un site web affiche, sans le filtrer, un contenu fourni par un utilisateur. Si ce contenu contient du code (typiquement du JavaScript, le langage qui s'exécute dans les navigateurs), ce code sera exécuté dans le navigateur des autres visiteurs, comme s'il faisait partie du site légitime. La faille ne vient donc pas du visiteur, mais du site qui fait confiance à des données non vérifiées.
Pour comprendre, il faut savoir comment une page s'affiche. Le navigateur reçoit du HTML (le langage qui structure la page) et l'affiche, en exécutant au passage le JavaScript qu'il contient. Normalement, un texte saisi par un utilisateur devrait rester du texte. Mais si le site insère ce texte tel quel dans la page sans précaution, et que ce texte est en réalité du code, le navigateur l'exécute. C'est cette confusion entre « contenu » et « code » qui est au cœur de toute faille XSS.
Que peut faire un attaquant via une faille XSS ?
Une fois du code exécuté dans le navigateur de la victime, les conséquences peuvent être sérieuses. Les principaux risques sont les suivants.
- Voler un identifiant de session, pour usurper l'identité de l'utilisateur connecté.
- Récupérer des informations personnelles ou des données affichées dans la page.
- Accéder à des informations de connexion saisies par la victime.
- Modifier le contenu affiché à l'insu de l'utilisateur.
- Rediriger la victime vers un site malveillant.
- Mener d'autres actions au nom de l'utilisateur, selon ses droits sur le site.
Le point commun : l'attaquant agit avec les droits et au nom de la victime, ce qui rend l'attaque particulièrement insidieuse.
À retenir : une faille XSS naît quand un site affiche du contenu utilisateur sans le filtrer, permettant l'exécution de code dans le navigateur des visiteurs. La cause est toujours la même : la confiance accordée à des données non vérifiées.
Quels sont les types de XSS les plus connus ?
On distingue trois grandes catégories de failles XSS, selon la façon dont le code malveillant atteint la victime. Les comprendre aide à savoir où porter ses efforts de protection.
Quelle est la différence entre XSS stockée, réfléchie et DOM ?
| Type | Principe | Particularité |
|---|---|---|
| XSS stockée (permanente) | Le code est enregistré dans la base de données du site et réaffiché à chaque visite | La plus dangereuse, touche tous les visiteurs de la page |
| XSS réfléchie | Le code est renvoyé immédiatement par le site, souvent via un lien piégé | Temporaire, nécessite que la victime clique sur un lien |
| XSS DOM-based | Le code s'exécute via une manipulation côté navigateur, sans passer par le serveur | Plus rare et difficile à détecter |
La XSS stockée est la plus grave : le code malveillant logé dans la base de données (par exemple via un champ de commentaire ou de messagerie mal protégé) s'affiche pour chaque visiteur de la page, automatiquement. La XSS réfléchie est temporaire : elle repose sur un lien piégé qu'il faut faire cliquer à la victime, et ne persiste pas. La XSS basée sur le DOM (Document Object Model, la représentation de la page que le navigateur manipule) se joue entièrement côté navigateur, ce qui la rend plus discrète. Ces trois variantes partagent la même cause profonde, et donc largement les mêmes protections.
Comment se protéger d'une faille XSS ?
C'est la partie qui compte vraiment. La bonne nouvelle : la XSS est une faille bien connue, et les protections sont éprouvées. Elles relèvent surtout du développement du site, et reposent sur un principe simple : ne jamais faire confiance à ce que saisit un utilisateur.
Qu'est-ce que l'assainissement des entrées (sanitization) ?
C'est la première ligne de défense. L'assainissement (ou « sanitization ») consiste à nettoyer et vérifier toute donnée fournie par un utilisateur avant de la traiter ou de l'afficher. Concrètement, on s'assure qu'un champ censé contenir du texte ne contient bien que du texte, en neutralisant les caractères qui pourraient être interprétés comme du code. À cela s'ajoute l'échappement des sorties (« output encoding ») : au moment d'afficher une donnée dans la page, on la convertit pour que le navigateur la traite comme du texte inoffensif, jamais comme du code exécutable. Ces deux réflexes, appliqués systématiquement, bloquent l'immense majorité des attaques XSS.
Les autres protections essentielles
Plusieurs mesures se combinent pour une défense solide.
- Valider les entrées côté serveur, en n'acceptant que les formats attendus pour chaque champ.
- Échapper les sorties selon le contexte d'affichage (HTML, attribut, JavaScript), pour neutraliser tout code.
- Mettre en place une politique de sécurité du contenu (CSP), un en-tête qui limite les scripts que le navigateur accepte d'exécuter.
- Protéger les cookies de session (attribut HttpOnly), pour qu'un script ne puisse pas les voler.
- S'appuyer sur des frameworks récents, qui intègrent par défaut une bonne part de ces protections.
Aucune de ces mesures n'est suffisante seule, mais ensemble, elles rendent une faille XSS très difficile à exploiter. C'est l'approche en couches qui fait la solidité.
Point clé pour la décision : la protection contre la XSS repose sur une règle d'or, ne jamais faire confiance aux données utilisateur. Validez les entrées, échappez les sorties, et appuyez-vous sur un framework à jour. Ces réflexes doivent être systématiques, pas ponctuels.
Quelle est la différence entre une faille XSS et une injection SQL ?
Les deux sont des attaques par injection, souvent confondues, mais elles ne visent pas la même cible. La XSS injecte du code qui s'exécute dans le navigateur d'un autre utilisateur : la victime est le visiteur du site. L'injection SQL, elle, injecte des commandes dans la base de données du site : la victime directe est le serveur, et l'objectif est d'accéder ou de modifier des données stockées. En clair : la XSS s'attaque au client (le navigateur), l'injection SQL au serveur (la base de données). Leur point commun, et leur parade commune, c'est qu'elles exploitent toutes deux des données utilisateur mal filtrées. Valider et assainir les entrées protège contre les deux.
Une faille XSS est-elle dangereuse pour une entreprise ?
Oui, et il serait imprudent de la sous-estimer. Pour une entreprise dont le site est exploité, les conséquences vont du vol de données clients à l'usurpation de comptes, en passant par la redirection des visiteurs vers des sites frauduleux et l'atteinte à la réputation. Si des données personnelles sont compromises, s'ajoute le volet réglementaire : le RGPD (Règlement général sur la protection des données, le cadre européen sur les données personnelles) impose de protéger ces données, sous peine de sanctions. Une faille XSS sur un site marchand ou un espace client n'est donc pas qu'un problème technique, c'est un risque commercial, juridique et d'image. C'est précisément pourquoi la sécurité doit être intégrée dès la conception du site, pas ajoutée après coup.
Par où commencer concrètement
Une faille XSS permet à un attaquant d'injecter du code qui s'exécute dans le navigateur des visiteurs d'un site, parce que ce site affiche du contenu utilisateur sans le filtrer. Elle se décline en trois types (stockée, réfléchie, DOM), mais partage une cause unique et des protections communes : ne jamais faire confiance aux données utilisateur, valider les entrées, échapper les sorties. Pour une entreprise, le risque est réel, technique comme juridique.
Ce qu'il faut arbitrer : le niveau de protection de votre site et qui s'en charge. Pour avancer, partez d'un état des lieux honnête. Votre site accepte-t-il des contenus saisis par les utilisateurs (commentaires, formulaires, messagerie), et sont-ils filtrés ? Votre code échappe-t-il systématiquement les données avant de les afficher ? Utilisez-vous un framework récent intégrant ces protections ? Avez-vous mis en place une politique de sécurité du contenu (CSP) ? Si ces questions restent sans réponse claire, faites auditer votre site par un professionnel de la sécurité web, et formez vos développeurs aux bons réflexes. La XSS est une faille connue et évitable, à condition d'intégrer la sécurité dès la conception plutôt que de la traiter après un incident.
Ce sujet touche à la sécurité informatique. Les éléments ci-dessus sont fournis dans une optique défensive, pour protéger vos systèmes et vos utilisateurs. Si vous gérez un site et soupçonnez une vulnérabilité, je vous recommande de faire appel à un professionnel de la cybersécurité pour un audit adapté à votre situation.
