Cross-site scripting (XSS)
Une attaque qui fait exécuter un script malveillant dans le navigateur des visiteurs d'un site, en le glissant dans une page qui affiche une saisie sans la neutraliser.
Définition
Le cross-site scripting, abrégé XSS, est une attaque qui fait exécuter un script malveillant dans le navigateur des visiteurs d’un site, en le glissant dans une page qui affiche une saisie sans la neutraliser. En français, on parle aussi de faille XSS ou de script intersite. La cible n’est pas le serveur, mais les personnes qui consultent la page.
Comment fonctionne une faille XSS ?
En faisant passer du code pour du texte à afficher.
Un site affiche sans cesse des données qui viennent de l’extérieur : le mot saisi dans la recherche, le nom laissé dans un commentaire, un paramètre présent dans l’adresse. Tant que ces données sont traitées comme du texte, elles s’affichent telles quelles et ne font rien.
Si le code de la page les insère sans les neutraliser, un attaquant peut y glisser du JavaScript. Le navigateur du visiteur ne fait pas la différence entre ce script et ceux du site : il l’exécute avec les mêmes droits, sur le même domaine. Le script peut alors lire ce que la page affiche, envoyer des requêtes au nom du visiteur, ou le rediriger ailleurs.
La vulnérabilité n’est donc pas dans le navigateur ni dans le serveur. Elle est dans l’application web qui a mélangé une donnée saisie et le code de la page, exactement comme une injection SQL mélange une saisie et une requête de base de données.
Quelles sont les formes de XSS ?
Trois, selon l’endroit où le script attend sa victime.
| Forme | Où vit le script | Ce que cela signifie |
|---|---|---|
| XSS stockée | en base de données, dans un commentaire, un profil ou un champ d’extension | chaque visiteur de la page est touché, sans rien faire d’autre que la consulter |
| XSS reflétée | dans un lien piégé, renvoyé par le site dans sa réponse | il faut amener la victime à cliquer, souvent par un courriel ou un message |
| XSS basée sur le DOM | dans le JavaScript de la page, qui réécrit son contenu à partir de l’adresse | le serveur peut ne jamais voir passer l’attaque |
La forme stockée est la plus grave sur un site WordPress, parce qu’elle attend patiemment. Un script déposé dans un champ que seul l’administrateur consulte, un formulaire ou un réglage d’extension, se déclenche le jour où il ouvre l’écran concerné.
Quels sont les impacts d’une attaque XSS ?
Tout ce que le navigateur de l’utilisateur peut faire sur le site.
Un script injecté agit dans la page, avec les données qu’elle contient. Il peut modifier le HTML affiché pour remplacer un texte ou un formulaire, ce qui ressemble alors à une défiguration. Il peut envoyer le visiteur vers un autre site, c’est une redirection malveillante. Il peut enfin lire ce que l’utilisateur saisit dans un formulaire de la page, puis l’envoyer à l’attaquant.
Le vol de session est l’impact le plus cité. WordPress marque ses cookies de connexion pour que le JavaScript de la page ne puisse pas les lire, ce qui ferme la voie la plus directe. Le script n’a toutefois pas besoin du cookie pour agir : il lui suffit d’envoyer ses requêtes depuis la page, pendant que la session est ouverte.
Pourquoi l’administrateur est-il la cible idéale ?
Parce que son navigateur peut tout faire sur le site.
Quand un administrateur connecté affiche une page piégée, le script agit avec ses droits. Il peut créer un nouveau compte administrateur, installer une extension ou modifier un fichier du thème si l’éditeur de fichiers n’est pas désactivé. Une faille qui semblait se limiter à l’affichage devient alors une prise de contrôle du site, ce qu’on appelle une élévation de privilèges.
WordPress limite ce risque par les jetons de sécurité, appelés nonces, que chaque action d’administration doit présenter. Ils empêchent un site tiers de déclencher une action à la place de l’utilisateur. Ils n’arrêtent pas un script qui s’exécute déjà sur le site lui-même, puisque ce script peut lire le jeton dans la page.
Le cœur de WordPress échappe ce qu’il affiche. Les extensions ne le font pas toutes. Les failles XSS publiées portent presque toujours sur une extension ou un thème précis, dans une version précise, corrigée dans la suivante. Une extension abandonnée garde la sienne pour toujours.
Comment protéger un site WordPress ?
Quatre gestes, du plus efficace au complément.
Mettre à jour
Appliquer les mises à jour de sécurité des extensions et des thèmes dès leur publication. La correction d’une faille XSS est connue du public dès sa sortie, les sites non mis à jour deviennent des cibles faciles.
Réduire
Supprimer les extensions inutilisées et limiter le nombre de comptes qui peuvent publier du contenu sans relecture. Chaque champ affiché est une porte possible.
Poser une politique de sécurité du contenu
L’en-tête HTTP Content-Security-Policy indique au navigateur quels scripts il a le droit d’exécuter. Bien réglé, il empêche un script injecté de s’exécuter ou d’envoyer des données ailleurs. Il se teste avant d’être imposé, parce qu’un réglage trop strict casse des fonctions du site.
Filtrer
Un pare-feu applicatif bloque une partie des motifs d’attaque connus avant qu’ils n’atteignent le site. Il complète les gestes précédents, il ne corrige pas le code fautif.
Ce que montre un site réel
Relevé du 28 septembre 2026 sur ilti.fr, en lecture seule. Une recherche interne lancée avec un mot entouré d’une balise de mise en gras revient sept fois dans la page de résultats, et les sept fois sous forme de texte neutralisé : la balise s’affiche, elle n’est jamais interprétée. Le moteur de recherche du site échappe donc correctement ce qu’il réaffiche. En revanche, la réponse du serveur ne porte aucun des en-têtes qui limitent les dégâts d’une faille XSS : ni politique de sécurité du contenu, ni interdiction d’intégrer le site dans un cadre, ni consigne de ne pas deviner le type des fichiers. Une extension dédiée à ces en-têtes est pourtant active. Installer l’outil ne suffit pas, il faut le régler, puis vérifier ce que le serveur envoie réellement.
Questions fréquentes
Que signifie XSS ?
Cross-site scripting, soit script intersite. Le X tient lieu du mot cross, et le sigle désigne la même attaque en français comme en anglais.
Une faille XSS peut-elle faire pirater un site entier ?
Oui, par rebond. Si le script s’exécute dans le navigateur d’un administrateur connecté, il peut agir avec ses droits, créer un compte ou installer une extension. C’est la raison pour laquelle une faille classée moyenne se corrige sans attendre.
Comment savoir si mon site est concerné ?
Un test d’intrusion, ou pentest, cherche les failles XSS en essayant chaque entrée du site. En comparant les versions des extensions et du thème installés aux failles publiées, par exemple dans le registre des CVE. Un script inconnu dans le code source d’une page, ou une redirection inattendue, sont des signes qu’une faille a déjà servi.
Quelle différence avec une injection SQL ?
L’injection SQL vise la base de données du site, sur le serveur. Le XSS vise le navigateur des visiteurs. Les deux naissent de la même erreur : traiter une saisie comme du code au lieu d’une simple valeur.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.