Faille XSS : définition, exemples et moyens de protection

Qu'est-ce qu'une faille XSS ?

Une faille XSS est une faiblesse d'un site web qui laisse un attaquant insérer du code JavaScript dans une page consultée par d'autres personnes. Le sigle vient de l'anglais cross-site scripting. On écrit XSS plutôt que CSS pour ne pas confondre avec les feuilles de style.

Le principe est simple. Le site reçoit un texte, par exemple un commentaire ou une recherche, puis il le renvoie dans la page sans le contrôler. Si ce texte contient une balise script, le navigateur ne voit pas la différence entre le code du site et celui de l'intrus. Il l'exécute donc comme s'il était légitime.

Ce n'est pas le serveur qui est attaqué en premier lieu. La cible, c'est l'utilisateur qui visite la page. Le code tourne côté client, avec les mêmes droits que le site lui-même. C'est pour cela que la faille figure depuis des années dans le classement OWASP Top 10 des risques web, au sein de la famille des injections.

Pourquoi le nom cross-site scripting ?

Le terme décrit le trajet du code. Un script écrit par un tiers traverse la frontière entre son site et le vôtre, puis il s'exécute sous votre nom de domaine. Le navigateur web fait confiance à votre domaine. Il accorde donc au code étranger l'accès aux cookies, au contenu de la page et aux actions de l'utilisateur connecté.

À quoi sert une attaque XSS pour un pirate ?

Une fois son code exécuté, l'attaquant dispose de nombreuses possibilités. Il agit dans la session de la victime, sans avoir besoin de son mot de passe. Pour une PME, les conséquences touchent à la fois les clients, l'image de marque et le chiffre d'affaires.

• Le vol de cookies de session, qui permet de se connecter au compte d'un client ou d'un administrateur.
• La modification du contenu affiché : faux formulaire de paiement, faux numéro de téléphone, fausse promotion.
• Le code peut rediriger vers un site frauduleux qui imite le vôtre pour récupérer des identifiants.
• L'envoi de requêtes au nom de l'utilisateur : changer son adresse email, passer une commande, publier un message.
• L'enregistrement des frappes au clavier dans un champ de connexion ou de carte bancaire.

Certains de ces scénarios nécessitent un administrateur connecté. C'est le cas le plus grave : si le compte d'un gestionnaire est compromis, tout le site peut basculer. Si cela vous arrive, notre guide site piraté, que faire détaille les gestes à poser dans l'ordre.

Comment fonctionne une faille XSS ?

Toute exploitation d'une faille XSS suit le même schéma. Une donnée entre dans le site, elle ressort dans le HTML, et le navigateur l'interprète comme du code. On distingue trois grandes familles selon le chemin que prend cette donnée.

Le XSS réfléchi

Ici, le code malveillant n'est pas enregistré. Il voyage dans l'URL, souvent dans un paramètre de recherche ou de message d'erreur. L'attaquant envoie le lien piégé par email ou sur un réseau social. La victime clique, la page renvoie le paramètre tel quel, et le script se déclenche aussitôt.

Le XSS stocké

C'est la forme la plus dangereuse. Le code est envoyé une fois, puis enregistré dans la base de données du site : avis client, commentaire, pseudo, fiche de contact. Les données stockées sont ensuite affichées à chaque visiteur, sans qu'il ait besoin de cliquer sur un lien suspect. Une seule injection peut toucher des centaines de personnes.

Le XSS de type DOM (DOM-based XSS)

Dans ce cas, le serveur n'est même pas impliqué. Le problème vient du JavaScript de la page, qui lit une valeur, par exemple la partie de l'URL après le dièse, puis l'insère dans la page avec une fonction comme innerHTML. Le code fragile se trouve dans le front end, ce qui rend ce type d'attaques plus difficile à repérer avec les outils classiques.

Un exemple concret de faille XSS

Prenons le moteur de recherche interne d'un site de vente en ligne. Quand le client cherche « chaussures », la page affiche : Résultats pour chaussures. Le code PHP se contente de reprendre la valeur du paramètre et de l'écrire dans la page.

Le même scénario existe sous WordPress. Le cœur du CMS est bien surveillé, mais une extension mal codée peut afficher un champ de formulaire sans filtrage. C'est l'une des raisons pour lesquelles une maintenance régulière du site, avec mises à jour des extensions, reste indispensable.

Comment se protéger d'une faille XSS ?

La règle d'or tient en une phrase : ne jamais faire confiance aux entrées par l'utilisateur. Toute donnée venue de l'extérieur doit être contrôlée à l'arrivée et neutralisée au moment de l'afficher. Plusieurs couches de protection se complètent.

Échapper les caractères à l'affichage

La défense principale consiste à remplacer les caractères spéciaux par leurs entités HTML. Le chevron < devient &lt;, le chevron > devient &gt;, l'apostrophe et le guillemet sont eux aussi convertis. Une fois encodées, ces valeurs s'affichent à l'écran comme du texte, mais le navigateur ne peut plus les interpréter comme une balise.

En PHP, la fonction htmlspecialchars fait ce travail : htmlspecialchars($texte, ENT_QUOTES, 'UTF-8'). Il faut l'appliquer partout où une donnée variable est écrite dans la page. Les frameworks modernes comme React, Vue ou les moteurs de templates Twig et Blade échappent par défaut. Le risque revient dès qu'un développeur contourne ce comportement pour gagner du temps.

Valider les données reçues

Avant même l'affichage, il est utile de vérifier que chaque champ contient ce qu'il doit contenir. Un code postal ne compte que des chiffres, une date suit un format précis, un email respecte une structure. Cette validation ne remplace pas l'encodage, mais elle réduit fortement la surface d'attaque. Les mêmes principes s'appliquent pour sécuriser un formulaire de contact.

Ajouter une Content Security Policy

La Content Security Policy est un en-tête HTTP qui indique au navigateur quelles sources de scripts sont autorisées. Bien réglée, cette security policy bloque l'exécution de tout script injecté dans la page, même si une faille subsiste. C'est un filet de sécurité précieux, pas une excuse pour négliger l'échappement.

Protéger les cookies de session

Les cookies sensibles doivent porter l'attribut HttpOnly. Le JavaScript de la page ne peut alors plus les lire, ce qui empêche le vol de session le plus courant. Les attributs Secure et SameSite complètent ce réglage et limitent aussi le risque de CSRF.

Les erreurs courantes qui ouvrent la porte au XSS

La plupart des failles ne viennent pas d'un manque de compétence, mais de raccourcis pris sous la pression des délais. Ce sont souvent les mêmes, d'un projet à l'autre.

• Filtrer uniquement la balise script : un attaquant passera par une image avec un attribut onerror ou un lien en javascript:.
• Encoder à l'entrée puis oublier l'affichage dans un autre contexte, comme un attribut HTML ou un bloc JavaScript.
• Utiliser innerHTML ou document.write avec des données issues de l'URL.
• Faire confiance au back-office : un champ réservé aux administrateurs peut aussi servir de point d'entrée.
• Laisser vieillir des extensions ou des bibliothèques non mises à jour.

Pour faire le point sur l'ensemble de votre site, et pas seulement sur le XSS, notre checklist sécurité site web passe en revue les points à contrôler. Et si vous lancez un nouveau projet, nous intégrons ces protections dès la création de site internet, plutôt que de les ajouter après coup.

Questions fréquentes