Le Cross-Site Scripting (XSS) expliqué simplement

C’est quoi, au juste ?

Votre site réaffiche en permanence du texte tapé par les visiteurs : un commentaire, un avis client, un nom de profil. Le problème apparaît quand ce texte est réaffiché tel quel, sans être neutralisé au préalable.

Si un visiteur tape un vrai morceau de code au lieu d’un simple texte, ce code s’exécute dans le navigateur de TOUS ceux qui verront la page — pas seulement le sien. C’est comme réafficher sur un panneau public tout ce que les gens y écrivent, sans jamais vérifier ce qu’ils y ont vraiment déposé.

Un exemple concret

Un champ « Votre avis » sur une fiche produit. Au lieu d’écrire « Très bon produit », un attaquant y dépose un petit script. Si le site l’affiche tel quel, dès qu’un autre client ouvre la page, ce script s’exécute dans SON navigateur, avec SES droits à lui — jamais ceux de l’attaquant.

Variante plus vicieuse : un lien « vérifiez votre commande » envoyé par e-mail contient le piège directement dans l’URL. La victime clique, la page s’affiche normalement, et le script agit en une fraction de seconde, invisible à l’œil nu.

Pourquoi c’est grave

Une fois exécuté dans le navigateur de la victime, le script peut voler son cookie de session — c’est-à-dire se faire passer pour elle sans connaître son mot de passe — afficher un faux formulaire de connexion pour capturer ses identifiants, ou agir en son nom : changer son adresse de livraison, valider un virement, publier en son nom.

C’est l’une des failles les plus répandues du web, classée A03:2021 – Injection dans l’OWASP Top 10, précisément parce qu’il suffit d’un seul champ oublié pour exposer tous vos visiteurs.

Comment s’en protéger

La règle d’or : neutraliser (échapper) tout ce qui vient du visiteur avant de le réafficher. Le caractère < devient &lt;, le caractère > devient &gt; — le texte reste du texte, jamais du code exécutable.

Utilisez l’échappement natif de votre outil : Twig et Jinja échappent par défaut, React aussi via JSX, htmlspecialchars() en PHP pur. En JavaScript, préférez toujours textContent à innerHTML pour afficher du texte. Ajoutez une Content-Security-Policy stricte, et mettez vos cookies de session en HttpOnly : même en cas d’oubli, ils resteront invisibles au script injecté.

Comment SauronSec la détecte

SauronSec dépose un marqueur inoffensif dans chaque champ, puis vérifie le CONTEXTE exact où il atterrit dans la page : à l’intérieur d’une balise HTML, d’un attribut, d’un bloc de script. Un simple reflet ne suffit jamais à conclure — SauronSec vérifie que le code s’exécuterait réellement à cet endroit précis avant de signaler quoi que ce soit.

Pour les cas stockés (commentaires, profils, avis), un marqueur inerte est déposé puis recherché sur une page consultée séparément, sans le payload dans l’URL : la preuve qu’il persiste vraiment, et pas seulement dans la réponse immédiate.