Les attaques par cross-site scripting sont des exploitations de failles dans les applications web et les serveurs web, qui surviennent en raison d’une vulnérabilité dans le code du serveur ou de l’application. Elles sont particulièrement dangereuses, car il est difficile pour les équipes de sécurité ou de développement de détecter une vulnérabilité XSS, et il est également difficile de voir les effets d’une attaque avant que la compromission qui s’ensuit ne soit déjà bien avancée. Pour empêcher les attaques XSS, votre équipe doit savoir à quoi elles ressemblent et déterminer si vos systèmes y sont vulnérables.
- Comment fonctionne le cross-site scripting ?
- 3 types courants d’attaques par cross-site scripting
- 5 principaux risques associés aux attaques XSS
- Comment savoir si vous êtes vulnérable aux attaques XSS
- Peut-on empêcher le cross-site scripting ?
- Foire aux questions (FAQ)
- En résumé : le cross-site scripting met en danger les données, les applications et la réputation de l’entreprise
Comment fonctionne le cross-site scripting ?
Une attaque par cross-site scripting se produit lorsqu’un acteur malveillant injecte du code ou un script malveillant dans le code d’une page d’application web. Cela se produit généralement sur des pages web dynamiques, qui changent fréquemment ou peuvent être manipulées activement par les utilisateurs (par exemple, une barre de recherche dans laquelle les utilisateurs peuvent saisir des requêtes).
Le code d’origine de la page web est considéré comme fiable. Généralement, lorsqu’un utilisateur accède à la page web, son navigateur la charge conformément aux instructions reçues. Mais si un acteur malveillant a ajouté du nouveau code à la page web, celle-ci peut ne pas se charger comme prévu à l’origine, sans que l’utilisateur ni le navigateur ne s’en aperçoivent. Le nouveau code malveillant est conçu pour voler des données — comme des cookies ou des identifiants — dans cette application web.

Les attaques par cross-site scripting sont dangereuses, car elles sont difficiles à détecter. La vulnérabilité se trouve dans le code, et les équipes de sécurité ne pourront pas la voir à moins de connaître le langage de programmation dans lequel la page est écrite. Souvent, il faut utiliser un logiciel d’analyse des applications pour trouver les indicateurs d’une attaque XSS. La recherche manuelle demande trop de travail, et les employés peuvent passer à côté de la vulnérabilité, surtout s’ils ne connaissent pas le langage utilisé.
Si votre application web est victime d’une attaque XSS, celle-ci peut être stockée, réfléchie ou basée sur le modèle objet de document (DOM). Les attaques XSS présentent plusieurs risques pour la sécurité et l’entreprise, notamment le vol d’identifiants et l’atteinte à la réputation de l’entreprise. Pour déterminer si vous êtes vulnérable, vous devez tester vos applications web, rester attentif aux signes évidents d’une attaque et utiliser des solutions logicielles pour rechercher les vulnérabilités dans votre code et vos applications.
3 types courants d’attaques par cross-site scripting
Le XSS stocké, le XSS réfléchi et le XSS basé sur le DOM sont les trois types les plus courants d’attaques par cross-site scripting. Ils se distinguent par le fait qu’ils touchent le côté serveur ou le côté client de l’application web.
XSS stocké
Dans une attaque XSS stockée, le script malveillant est écrit directement dans le code de l’application web, ce qui affecte à la fois le côté client et le côté serveur. Il demeure en permanence dans le code de ce serveur ou de cette application jusqu’à ce que les administrateurs ou une solution de sécurité automatisée l’éliminent. Le XSS stocké est une attaque XSS particulièrement grave, car le code malveillant est toujours présent dans l’application.
Par exemple, si un acteur malveillant écrit un script malveillant sur le serveur web d’une entreprise de services financiers, sur une page où les utilisateurs saisissent leurs données financières, il peut voler ces données chaque fois qu’une personne utilise la page. Comme le code malveillant est écrit sur le serveur web, il affecte chaque utilisation de l’application web. Les utilisateurs ignorent que le code de la page web des services financiers est malveillant, car elle semble légitime, et ils continuent de l’utiliser jusqu’à ce que la menace soit découverte.
XSS réfléchi
Le XSS réfléchi tient son nom du fait qu’un attaquant injecte du code malveillant dans une URL ou des paramètres de requête, et que la réponse du serveur web reflète ce code injecté. Le XSS réfléchi n’est pas stocké durablement dans le back-end de l’application ou dans le code du serveur. L’attaque est menée dans les limites des données saisies par l’utilisateur, comme l’URL ou les paramètres de requête. Le XSS réfléchi peut être grave si un attaquant l’utilise pour voler des cookies de session ou des identifiants utilisateur.
Un exemple de XSS réfléchi serait celui d’un acteur malveillant qui intercepte les paramètres de requête d’un ingénieur logiciel cherchant à accéder à une application d’ingénierie populaire. L’acteur malveillant modifie subtilement l’URL, de sorte que l’utilisateur accède à une page web vulnérable au lieu de la page légitime attendue. À partir de là, l’acteur malveillant peut mener plusieurs actions pour compromettre le travail de l’ingénieur, par exemple voler les informations qu’il saisit sur la page.
XSS basé sur le DOM
Dans une attaque XSS basée sur le DOM, l’attaquant manipule le modèle objet de document (DOM) du navigateur de l’utilisateur. Le code réel de l’application web ne change pas côté serveur, mais il s’exécute de manière malveillante côté utilisateur. Le XSS basé sur le DOM est particulièrement difficile à détecter, car les modifications se produisent côté client, dans le modèle objet de document, et peuvent ne jamais atteindre le serveur web.
Par exemple, si un attaquant vole des éléments d’une URL et les utilise dans une fonction JavaScript permettant l’exécution dynamique de code, il peut manipuler le code côté client d’une application web. Si l’attaquant choisit de manipuler la page principale d’un produit de gestion de la relation client (CRM), la réponse HTTP réelle de la page ne sera pas différente, mais le code visible côté client le sera. L’acteur malveillant pourrait lancer une attaque à l’aide des fragments d’URL.
5 principaux risques associés aux attaques XSS
Les attaques par cross-site scripting sont notoirement difficiles à détecter, car elles se font passer pour un comportement légitime d’une page web. Elles permettent également aux acteurs malveillants de voler les identifiants et les cookies de session de votre application web, et peuvent perturber les processus métier courants tout en portant atteinte à la réputation de votre entreprise.
Les attaques XSS sont difficiles à détecter
Comme les attaques XSS manipulent des processus parfaitement légitimes d’une application web, elles sont difficiles à détecter. De plus, elles font souvent intervenir un type de code précis, généralement JavaScript. Même un administrateur de la sécurité ou du développement peut ne pas savoir comment neutraliser l’attaque s’il ne connaît pas le langage de programmation dans lequel elle est écrite — à supposer déjà qu’il se rende compte qu’une attaque XSS a eu lieu.
Les attaquants peuvent voler vos identifiants
Dans l’un des pires scénarios impliquant une attaque XSS, un acteur malveillant peut voler des identifiants une fois que l’utilisateur les a saisis sur une page web dont il ignore qu’elle a été piratée. Tout d’abord, l’acteur malveillant doit compromettre une page web sur laquelle les utilisateurs se connectent à un service ou à une application. Il doit ensuite se connecter avec succès et voler le code saisi par l’utilisateur afin de pouvoir le réutiliser pour se connecter lui-même à l’application, si possible sans se faire remarquer.
Si le compte dispose de privilèges élevés, la situation est encore plus dangereuse. Il est possible que l’attaquant puisse élever ses privilèges après avoir volé un jeu d’identifiants, puis accéder à des données plus sensibles.
Les attaquants peuvent détourner les cookies de session
Un attaquant peut injecter un script dans un site web vulnérable aux attaques XSS et utiliser des fichiers pour voler les informations contenues dans les cookies de session. S’il configure le script de manière à voler les données de session sans que l’utilisateur ne remarque quoi que ce soit d’alarmant, il ne lui signalera même pas qu’une attaque a eu lieu.
Lorsqu’une personne vole des cookies de session, elle peut reproduire une session sur une page web, ce qui signifie qu’elle pourrait accéder aux données sensibles de cette application et y apporter des modifications. Cette attaque ressemble à une attaque par vol d’identifiants et pourrait entraîner une situation similaire si le cookie contient des informations de connexion.
Les attaques XSS sont chronophages et irritantes
Si une attaque XSS met une page hors service ou provoque une redirection vers la mauvaise fenêtre, cela crée un véritable casse-tête non seulement pour le service informatique de votre entreprise, mais aussi pour tous les autres utilisateurs qui doivent accéder à la page. C’est particulièrement vrai pour les applications web essentielles aux opérations de l’entreprise et auxquelles les employés accèdent fréquemment. Si la page ne fonctionne pas pendant longtemps, il ne s’agit pas seulement d’une irritation et d’une interruption, mais aussi d’une menace pour les processus critiques de l’organisation.
Les attaques réussies peuvent nuire à votre entreprise
Si une page web devient indisponible ou si un acteur malveillant falsifie son contenu, les dommages causés à votre entreprise peuvent être graves. Une application web qui se comporte étrangement nuit à la réputation de cette application, ainsi qu’à celle de l’organisation qui l’exploite. Si un attaquant accède à un compte privilégié, il peut même compromettre des données sensibles de clients. La falsification de contenu serait un type d’attaque plus rare, mais elle n’est pas impossible pour un acteur malveillant très compétent.
Si vous vous inquiétez des effets d’une attaque contre une application web sur l’ensemble du réseau de votre entreprise, lisez-en davantage sur la sécurité réseau.
Comment savoir si vous êtes vulnérable aux attaques XSS
Même s’il est difficile de savoir immédiatement que vous avez été attaqué, vos équipes de sécurité et informatiques peuvent prendre certaines mesures pour se former au cross-site scripting. Pour déterminer si les serveurs web et les applications de votre entreprise sont susceptibles d’être vulnérables aux attaques XSS, testez-les, surveillez les signes les plus évidents et évaluez en permanence les vulnérabilités de sécurité.
Effectuer des tests ou faire appel à un pentester
Si vous disposez de personnel expérimenté en sécurité ou en informatique, vous pouvez tout à fait tester vous-même le code de vos serveurs web et de vos applications web. Suivre les recommandations d’organismes experts en sécurité comme OWASP est un bon point de départ pour protéger vos systèmes contre les attaques XSS.
Il peut également être utile de faire appel à un testeur d’intrusion. Les pentesters sont spécialement engagés pour s’introduire dans vos systèmes et révéler leurs vulnérabilités. Si vous en engagez un pour se concentrer sur les applications web et les vulnérabilités du code, vous aurez plus de chances de savoir si vos pages web sont vulnérables aux attaques XSS.
Pour en savoir plus sur les tests dynamiques de sécurité des applications, un outil utile pour découvrir les vulnérabilités des applications web.
Surveiller les signes évidents d’une attaque
De nombreuses attaques XSS ne seront pas évidentes, mais restez attentif aux signes les plus flagrants indiquant qu’une attaque est en cours. Si vos pages web redirigent de manière incorrecte ou si un utilisateur apparemment authentifié commence soudainement à effectuer des modifications étranges dans une application web privilégiée, c’est le signal qu’il faut examiner de plus près le code de la page web. Même si peu d’attaques seront évidentes, surveillez attentivement celles qui le sont.
Rechercher régulièrement les vulnérabilités
Effectuez régulièrement des analyses de vulnérabilité sur l’ensemble de votre infrastructure, mais pour trouver les vulnérabilités XSS, analysez en particulier vos applications web. Les outils d’analyse des vulnérabilités tiennent compte des schémas et identifient les problèmes que les équipes de sécurité n’ont pas le temps de trouver manuellement. Certains outils d’analyse des vulnérabilités extraient également des informations de bases de données ou de bibliothèques contenant des signatures ou des indicateurs courants de menaces, ce qui vous aide à les trouver dans vos propres systèmes et applications.
Découvrez notre sélection des meilleurs scanners de vulnérabilités web et applicatives, ainsi que les critères à prendre en compte pour choisir un scanner.
Peut-on empêcher le cross-site scripting ?
Les entreprises peuvent empêcher le cross-site scripting, mais leurs équipes de sécurité et de développement d’applications web devront s’engager à appliquer de bonnes pratiques de sécurité. Elles devront :
- Vérifier régulièrement que le code des applications ne présente pas de problèmes : Analysez le code tout au long du cycle de développement afin de déterminer s’il présente des vulnérabilités.
- Encoder les sorties et valider les entrées : Encodez les données lors de leur écriture dans une application web, puis validez et assainissez les données saisies par l’utilisateur avant de les envoyer au navigateur.
- Utiliser des outils de sécurité avancés : Les logiciels de sécurité des applications web sont conçus pour protéger les applications web et sont particulièrement utiles pour empêcher les attaques XSS.
- Enseigner les bonnes pratiques DevOps : Tous les développeurs web doivent connaître les attaques XSS et savoir les réduire en créant du code robuste et sécurisé.
Pour en savoir plus sur la prévention des attaques XSS, notamment des exemples concrets d’attaques et des outils pouvant aider votre entreprise.
Foire aux questions (FAQ)
Quel est un exemple concret de XSS ?
En 2018, British Airways a été attaquée par un groupe de pirates qui a exploité une vulnérabilité XSS dans une bibliothèque JavaScript. Les pirates ont envoyé les données des clients à un serveur qui tentait d’usurper le nom de domaine de British Airways. Avant que quiconque ne découvre l’attaque, les pirates ont récupéré les données de cartes bancaires de plus de 350 000 transactions. C’est un bon exemple du temps que peut prendre la détection d’une attaque XSS.
Que peuvent faire les pirates avec le XSS ?
Même si les attaquants peuvent utiliser le XSS pour voler des données et des cookies, leurs objectifs peuvent aussi être moins dommageables. Un attaquant pourrait utiliser le cross-site scripting pour ralentir les performances d’un site web concurrent ou ajouter du contenu inapproprié à une page légitime. Les atteintes à la réputation restent toutefois préjudiciables.
Quelle est la cause fondamentale des attaques XSS ?
Les attaques par cross-site scripting se produisent parce que le contenu d’une requête adressée à une application web n’a pas été correctement validé. Même s’il est difficile de déterminer si votre code web est vulnérable au XSS, les équipes de développement et de sécurité disposent de moyens pour corriger ces failles, par exemple en validant toutes les entrées avant d’envoyer une requête utilisateur au navigateur web.
En résumé : le cross-site scripting met en danger les données, les applications et la réputation de l’entreprise
Les attaques par cross-site scripting exposent les applications et les serveurs web à des risques et créent des difficultés pour les équipes de sécurité et de développement web, qui peuvent ne même pas savoir qu’elles sont vulnérables. Mais si les capacités humaines à trouver les vulnérabilités dans le code et à repérer les compromissions sont limitées, l’utilisation de solutions de sécurité automatisées — comme les scanners de vulnérabilités et les outils de test de la sécurité des applications — est utile.
Vous devez tester le code de vos applications web et créer des pipelines de développement sécurisés afin de réduire la probabilité que des vulnérabilités apparaissent pendant le processus de développement. Même si empêcher les vulnérabilités et les attaques XSS peut sembler accablant, prendre soin de votre code et investir dans des solutions de sécurité automatisées contribuera à protéger vos applications web sur le long terme.
Si vous souhaitez en savoir plus sur la sécurité d’autres applications, et pas seulement des applications web, découvrez les différents types de sécurité des applications. Cela inclut la sécurité des applications cloud et mobiles, ainsi que des applications de données et d’entreprise.





