cybercursus

Qu'est-ce qu'une XSS et pourquoi c'est dangereux

9 min · Débutant · 7 août 2026

Sommaire
  1. Le même principe, une cible différente
  2. Pourquoi « cross-site »
  3. Ce que ça change concrètement
  4. Une première exécution, pour de vrai

Le même principe, une cible différente

Le cours sur les injections SQL a posé un principe : un serveur qui mélange du code et des données non fiables peut être trompé. Le Cross-Site Scripting (XSS) applique exactement le même principe, mais du côté du navigateur : une page web qui insère une donnée non fiable directement dans le HTML qu’elle affiche peut être amenée à exécuter du code que son auteur n’a jamais écrit.

text
Injection SQL : la donnée non fiable finit dans une requête envoyée à la base de données
XSS            : la donnée non fiable finit dans du HTML envoyé au navigateur

Pourquoi « cross-site »

Le nom vient du scénario classique : un attaquant héberge son code sur un site qu’il contrôle, mais le fait exécuter dans le contexte d’un site totalement différent, celui de la victime. D’où « cross-site » (« entre sites ») : le code traverse une frontière qu’il n’aurait jamais dû franchir.

Ce que ça change concrètement

Une fois qu’un script injecté s’exécute dans le navigateur d’une victime, il hérite de tout ce à quoi cette page a normalement accès : lire le contenu affiché, manipuler le DOM, intercepter ce que la victime tape dans un formulaire, ou lire un cookie non protégé (voir le chapitre sur le vol de session, plus loin dans ce cours).

Danger

Un script injecté ne s’exécute jamais « à distance » : il tourne dans le navigateur de la victime, avec les mêmes droits que n’importe quel script légitime du site. C’est précisément ce qui le rend dangereux, et ce qui le distingue d’une simple erreur d’affichage.

Une première exécution, pour de vrai

Le bac à sable ci-dessous s’exécute dans une iframe isolée (aucun accès à ce site ni à tes données, voir les mentions légales), mais le mécanisme est le même que dans une vraie XSS : une valeur non fiable est insérée directement dans le HTML de la page via innerHTML, sans aucun échappement.

html
<!-- HTML -->
<p>Message du jour : <span id="zone"></span></p>

// JS
// Une donnee non fiable, inseree telle quelle dans le HTML de la page
const donneeNonFiable = "<img src=x onerror=\"console.log('XSS executee')\">";
document.getElementById('zone').innerHTML = donneeNonFiable;

Essaie de modifier donneeNonFiable : tant qu’elle finit dans innerHTML sans être échappée, n’importe quel contenu que tu y places s’exécute comme du HTML actif, y compris du JavaScript.

Astuce

Remarque le payload utilisé : <img src=x onerror="...">, pas <script>...</script>. C’est volontaire, pas une préférence esthétique : les navigateurs n’exécutent jamais un <script> inséré via innerHTML (c’est une protection intégrée). Un gestionnaire d’évènement comme onerror ou onload, en revanche, s’exécute normalement dès son insertion dans le DOM. Retiens ce détail : il explique pourquoi les charges XSS réelles utilisent rarement une simple balise <script>.

Dans une attaque XSS réussie, dans le navigateur de qui le code de l'attaquant s'exécute-t-il ?
Quelle est la différence fondamentale entre une injection SQL et une XSS ?

Pour aller plus loin

Commentaires

Recherche