Le sigle XSS désigne le « cross-site scripting » : un attaquant parvient à faire afficher son propre script par le site, qui s’exécute alors dans le navigateur de chaque visiteur avec les mêmes droits que n’importe quel code légitime de la page — capable, par exemple, de lire des cookies de session ou de rediriger l’utilisateur vers un site frauduleux.
Où le risque apparaît dans WordPress
Un commentaire, un champ de profil utilisateur ou un paramètre d’URL affiché sans échappement sont des points d’entrée classiques : si un thème affiche <?php echo $_GET['recherche']; ?> sans passer par esc_html(), tout script glissé dans ce paramètre s’exécute chez chaque visiteur qui suit ce lien.
Exemple
// vulnérable
echo 'Résultats pour : ' . $_GET['q'];
// protégé
echo 'Résultats pour : ' . esc_html($_GET['q']);
Deux variantes à connaître
Le XSS dit « réfléchi » n’affecte que la victime qui clique sur un lien piégé spécialement construit, tandis que le XSS « stocké » enregistre le script malveillant en base (dans un commentaire, par exemple) pour l’exécuter chez tous les visiteurs qui consultent ensuite cette page, ce qui le rend nettement plus dangereux car il ne nécessite aucune action ciblée supplémentaire de l’attaquant. Une troisième variante, dite « XSS basé DOM », se joue entièrement côté navigateur, sans même repasser par le serveur, quand un script JavaScript du thème manipule une donnée d’URL et l’injecte directement dans la page sans la neutraliser.
Bon à savoir
Un en-tête Content-Security-Policy bien configuré côté serveur limite fortement les dégâts d’un XSS réussi, en interdisant par exemple l’exécution de scripts provenant d’un domaine non explicitement autorisé, même si une faille venait à être exploitée malgré les protections applicatives déjà en place.