Tous les articles

27 octobre 2026 · 2 min de lecture

La faille XSS : quand un commentaire cache du code pour vos visiteurs

Une faille XSS laisse du code caché dans un commentaire s'exécuter chez vos visiteurs. Le principe, les risques et les bons réflexes pour s'en protéger.

  • sécurité
  • tech

Une faille XSS (cross-site scripting) survient quand un site affiche un contenu saisi par quelqu'un, un commentaire par exemple, sans le neutraliser. Le navigateur des autres visiteurs le prend alors pour du code du site et l'exécute.

L'analogie : la note dans le livre d'or

Un restaurant laisse un livre d'or. Un client y écrit un mot gentil, un autre y glisse une fausse consigne destinée au personnel : « Remettez la caisse au porteur de ce papier. » Si le restaurant lit à voix haute toutes les pages à chaque service, sans distinguer une note d'une consigne, le personnel peut obéir.

Un site fait la même chose quand il affiche en brut ce que ses utilisateurs ont écrit : le navigateur ne distingue pas le texte du contenu du code de la page.

Pourquoi c'est un problème

Le code ainsi exécuté tourne dans la page de votre site, avec les mêmes droits que lui chez le visiteur. Il peut notamment :

  • modifier ce qui s'affiche (un faux formulaire de connexion, par exemple) ;
  • agir au nom du visiteur ;
  • tenter de lire ce que le navigateur garde pour votre site, si cela n'est pas protégé.

L'attaque vise vos visiteurs, par l'intermédiaire de votre site, et c'est votre réputation qui en pâtit.

Où ça se loge

Là où du contenu venant de l'extérieur est affiché : commentaires, noms de profil, messages, champs de recherche qui répètent ce qu'on a tapé, descriptions de produits saisies par des tiers.

Les bons réflexes

  • Échapper à l'affichage : transformer les caractères spéciaux pour qu'ils s'affichent comme du texte et ne s'interprètent jamais comme du code. Les frameworks modernes le font par défaut.
  • Se méfier des fonctions « afficher du HTML brut » que ces frameworks proposent : à n'utiliser que sur du contenu maîtrisé, ou nettoyé par une bibliothèque dédiée.
  • Si vous devez accepter du formatage (gras, liens), utiliser une liste blanche de balises autorisées.
  • Ajouter une politique de sécurité du contenu (CSP) qui limite les scripts que le navigateur accepte d'exécuter.
  • Marquer les cookies de connexion HttpOnly : les scripts de la page ne pourront pas les lire.

À retenir

Tout ce qui vient de l'extérieur est du texte, jamais du code. On l'échappe à l'affichage, on se méfie du HTML brut, et on ajoute des protections en couches.

Et pour votre produit ?

Les applications qui affichent du contenu d'utilisateurs ont généralement au moins une zone à vérifier. Un audit de votre application relit ces endroits, avec les droits et les cookies concernés. Nous pouvons en parler pendant 30 minutes.

À lire aussi : l'injection SQL, le CORS et session ou JWT.