Qu'est-ce que le XSS ? Pourquoi les navigateurs exécutent-ils du contenu qui ne devrait pas être exécuté ?
Les sites Web traitent quotidiennement les entrées des utilisateurs, telles que les commentaires, les pseudonymes, les mots-clés de recherche, les critiques de produits et les profils personnels. Ces données sont généralement stockées dans une base de données ou renvoyées au navigateur via des paramètres d'URL. Si un site Web ne traite pas correctement le contenu non fiable, le navigateur pourrait interpréter le texte devant être affiché comme du HTML, du JavaScript ou d'autres contenus exécutables. Ce problème est connu sous le nom d’attaque par script intersite, en anglais Cross-Site Scripting, ou XSS. L'accent n'est pas mis sur le fait de traverser différents sites, mais sur l'exécution de contenu malveillant au sein d'un site de confiance pour la victime. Lorsque l'utilisateur est déjà connecté à un site, les risques peuvent inclure la modification de l'écran, la manipulation des actions de l'utilisateur, la lecture de données sensibles ou des conséquences sur le comportement du compte. Les causes du XSS ne proviennent généralement pas d'un navigateur soudainement hors de contrôle, mais plutôt du fait que le site n'a pas clairement séparé les données et le contenu exécutable.
Quelles sont les différences entre le XSS réfléchi, le XSS stocké et le XSS basé sur le DOM ?
Le XSS réfléchi se produit généralement lorsque le site renvoie immédiatement le contenu de la requête à la page. Par exemple, une page de résultats de recherche qui affiche directement les mots-clés de l’URL sans traitement approprié. Un utilisateur peut être amené à visiter le site via un lien contenant du contenu malveillant, donc les administrateurs de sites doivent vérifier les paramètres d'URL, les champs de recherche et la façon dont sont affichées les pages d'erreur. Le XSS stocké, quant à lui, consiste à ce que le site enregistre d'abord des contenus non fiables pour les afficher ensuite à d'autres utilisateurs. Les zones de commentaires, les critiques de produits, les articles de forum et les profils personnels peuvent être des lieux nécessitant des vérifications. Son impact peut être plus vaste qu'une simple réflexion, car une fois que le contenu est enregistré, d'autres personnes visitant la page concernée peuvent également être exposées à des contenus problématiques. Le XSS basé sur le DOM survient principalement lorsque du JavaScript frontal traite les données de la page. Même si le backend ne renvoie pas directement le contenu, les scripts frontaux peuvent encore
Comment les sites Web peuvent-ils empêcher le XSS par l'encodage de sortie ?
La défense contre le XSS n'est pas simplement de supprimer quelques symboles spéciaux, mais plutôt d'exécuter une encodage contextualisée en fonction de l'emplacement de sortie. Les données placées dans le texte HTML nécessitent un traitement de sécurité différent de celles placées dans des attributs HTML, des chaînes JavaScript, du CSS ou des URL. L'utilisation d'une méthode d'encodage incorrecte peut donner l'impression que le site filtre, tout en laissant en réalité des risques. Les administrateurs de sites peuvent d'abord examiner chaque point d'entrée et de sortie :
- Lister les sources non fiables, telles que les commentaires, les recherches, les pseudonymes, les profils personnels, les paramètres d'URL et les réponses d'API.
- Confirmer le contexte final dans lequel chaque donnée sera insérée dans HTML, attributs, JavaScript, CSS, URL ou manipulations DOM.
- Utiliser des bibliothèques de sécurité fournies par des frameworks pour l'encodage automatique des sorties, plutôt que de créer des règles de filtrage incomplètes.
- Si le produit doit effectivement autoriser un peu de HTML, utiliser des bibliothèques d'assainissement fiables tout en limitant les balises et attributs autorisés.
- Vérifier dans un environnement de test autorisé si le texte normal, les symboles spéciaux et le contenu de différentes langues s'affichent correctement après la correction.
Dans le code frontal, les développeurs devraient privilégier l'utilisation des API sécurisées qui traitent le contenu comme du texte brut, afin d'éviter de placer des données non fiables directement dans des positions d'exécution HTML ou de scripts dangereux. La feuille de triche sur la prévention des scripts intersites de l'OWASP fournit les principes complets pour choisir les mesures de défense en fonction du contexte de sortie. La validation des entrées reste précieuse, mais ne peut remplacer l'encodage de sortie. Elle est adéquate pour limiter le format des données, par exemple la longueur d'un nom d'utilisateur, la conformité d'une URL aux formats autorisés ou la conformité des champs de tri à une liste fixe ; elle ne peut pas être considérée comme la seule ligne de défense contre le XSS.
Que peuvent faire le CSP, les Cookies et les en-têtes de sécurité ?
La politique de sécurité du contenu, ou CSP, indique aux navigateurs via des en-têtes HTTP quelles sources sont autorisées à charger des scripts, des images, des styles et d'autres ressources. Une CSP bien configurée peut réduire l'impact de certaines attaques XSS et aider un site à détecter le chargement de ressources non conformes. Toutefois, la CSP est une défense supplémentaire et ne remplace pas l'encodage de sortie sécurisé et les corrections de code. Les sites peuvent d'abord utiliser le mode rapport dans un environnement de test pour observer quelles ressources sont bloquées par la politique, puis progressivement restreindre les sources autorisées. Lors de la configuration de la CSP, il ne faut pas autoriser toutes les sources ou assouplir les restrictions de scripts pour restaurer rapidement toutes les fonctionnalités. Le guide de la politique de sécurité du contenu de MDN peut servir de référence pour comprendre les en-têtes et les restrictions de ressources. Les Cookies doivent également être configurés avec des attributs de sécurité appropriés en fonction de la sensibilité des données. HttpOnly peut réduire la probabilité que les scripts frontaux lisent directement
Comment tester légalement si un site Web présente des risques de XSS ?
Avant de tester, il est essentiel de confirmer la portée, le timing, les outils autorisés et la manière de traiter les données. Le moyen le plus sûr d'apprendre est de suivre le cours XSS de PortSwigger Web Security Academy, ou de pratiquer sur ses propres projets locaux, serveurs de test et cibles délibérément conçues. Ces environnements permettent aux apprenants de comprendre les causes des vulnérabilités sans infliger de dommages à des sites inconnus. Les tests de défense peuvent être effectués dans cet ordre : d’abord évaluer les points d’entrée, puis confirmer le contexte de sortie ; ensuite vérifier si les frameworks effectuent un encodage automatique, si le front-end utilise des API DOM sécurisées, si la CSP fonctionne correctement et si les cookies ont les attributs appropriés. Pendant les tests, utiliser des comptes fictifs et des données non sensibles, et lors de la conclusion, nettoyer les contenus de test et conserver les résultats avant et après les corrections. Il ne faut pas coller directement dans de vrais sites des chaînes de test XSS trouvées sur Internet, ni tester la lecture de cookies, l'exploitation de comptes ou le contournement d’autorisations. Les
Questions fréquentes sur le XSS
Le XSS vole-t-il directement le mot de passe de tous les utilisateurs d'un site ?
Pas nécessairement. L'impact réel du XSS dépend de la page présentant la vulnérabilité, des permissions utilisateur, des paramètres de cookies, de la CSP, des fonctionnalités frontales et de la structure des données du site. Certains XSS peuvent seulement modifier l’affichage d’une page spécifique, tandis que d'autres peuvent affecter les actions des utilisateurs ou exposer des données pouvant être lues par des scripts. On ne peut pas déduire que tous les comptes ont été compromis dès que l'on voit les trois lettres XSS. Les administrateurs de sites doivent d'abord vérifier le type de vulnérabilité et l'étendue de son impact, puis examiner les journaux, les activités de connexion, les rapports CSP et les fonctionnalités sensibles. Lors de la correction, il convient de partir du contexte de sortie, des API DOM dangereuses et de la conception des autorisations, plutôt que de simplement supprimer un contenu suspect ou de bloquer une URL.
Est-ce qu'une CSP peut complètement prévenir le XSS ?
Non. La CSP est une couche de défense du navigateur qui réduit les impacts ; si la politique est trop permissive ou autorise des sources de scripts non fiables, ou si le site lui-même place des entrées dans des positions de sortie dangereuses, les risques demeurent. Les différents navigateurs, les ressources tierces et les fonctionnalités des sites peuvent également affecter l'efficacité de la politique. Une approche plus complète consiste à utiliser la CSP en conjonction avec l'encodage contextuel de sortie, l'assainissement HTML, des API DOM sécurisées, des cookies HttpOnly, des révisions de code et des tests dans un environnement de vérification. La CSP doit d'abord être observée en mode rapport, puis être progressivement resserrée en fonction des ressources réelles du site, sans la considérer comme la seule méthode de correction.
Que devrait faire un utilisateur lambda en cas de fenêtres contextuelles ou de contenu Web suspect ?
Ne pas entrer de mots de passe, de codes de vérification ou de données de carte de crédit, et ne pas suivre les demandes de téléchargements de fichiers ou d’installations d’extensions inconnues. Fermez la page suspecte et accédez de nouveau au service via une URL officielle saisie manuellement ; si vous avez déjà saisi des informations de compte, changez immédiatement votre mot de passe et vérifiez les activités de connexion depuis un appareil sécurisé. Si vous soupçonnez une vulnérabilité du site ou une page de phishing, conservez l'URL, l'heure et une capture d'écran, mais ne partagez pas d'informations personnelles ou ne renvoyez pas de liens suspects. Vous pouvez en informer le propriétaire via les canaux de sécurité officiels du site ; si cela concerne des pertes de comptes ou des violations de données personnelles, contactez également la plateforme et les organismes concernés dans votre région.
Un point essentiel à retenir : L'encodage de sortie et le CSP sont au cœur de la défense contre le XSS.