Découvrez ce qu’est une faille XSS, comment elle fonctionne et les bonnes pratiques pour protéger efficacement vos applications web.
Quand ton site exécute du code… pour quelqu’un d’autre
Imagine un instant :
un utilisateur écrit un commentaire sur ton site… et ce commentaire contient du JavaScript.
Si ton application ne filtre rien, le navigateur va exécuter ce code comme s’il venait de ton site.
Résultat possible :
- vol de session
- redirection vers un site malveillant
- affichage de faux formulaires
- vol de données
Bienvenue dans le monde des failles XSS.
Une faille XSS, c’est quoi exactement ?
XSS signifie Cross-Site Scripting.
C’est une vulnérabilité qui permet d’injecter du code JavaScript dans une page web consultée par d’autres utilisateurs.
Ce code s’exécute dans le navigateur de la victime, avec les permissions du site.
Donc pour le navigateur, le script est "de confiance".
Documentation OWASP :
https://owasp.org/www-community/attacks/xss/
Les trois types principaux de XSS
1. XSS stockée (Stored XSS)
Le script est enregistré dans une base de données :
- commentaires
- profils utilisateurs
- forums
Chaque visiteur exécute alors le script automatiquement.
C’est la plus dangereuse.
2. XSS réfléchie (Reflected XSS)
Le script est envoyé via une URL :
site.com/search?q=alert('hack')
Si la page affiche le contenu sans filtrage, le script s’exécute.
Souvent utilisée dans des attaques par phishing.
3. XSS DOM-based
Le script est exécuté directement dans le navigateur, via JavaScript.
Aucun passage par le serveur.
Plus discrète, mais redoutable.
Guide détaillé :
https://portswigger.net/web-security/cross-site-scripting
Exemple simple de faille XSS
Supposons ce code PHP :
<?php
echo $_GET['comment'];
?>Si un utilisateur écrit :
alert('XSS')
Le script s’exécute.
Et si au lieu d’une alerte, c’était un vol de cookie ?
Pourquoi les failles XSS sont si dangereuses
Une attaque XSS peut permettre :
- vol de cookies de session
- prise de contrôle de comptes
- modification de pages
- redirections malveillantes
- keylogging
Et le pire :
l’utilisateur ne se doute de rien.
Comment se protéger efficacement
1. Échapper les données utilisateur
Toujours filtrer ce qui vient :
- des formulaires
- des URL
- des cookies
- des API
En PHP, on utilise :
<?php
echo htmlspecialchars($_GET['comment'], ENT_QUOTES, 'UTF-8');
?>Documentation officielle :
https://www.php.net/htmlspecialchars
2. Utiliser des headers de sécurité
Le header Content Security Policy (CSP) empêche l’exécution de scripts non autorisés.
Exemple :
header("Content-Security-Policy: default-src 'self'; script-src 'self'");Guide CSP :
https://developer.mozilla.org/fr/docs/Web/HTTP/CSP
3. Valider côté serveur, pas seulement côté client
Le JavaScript peut être contourné.
Le serveur, non.
Toujours valider et filtrer côté backend.
4. Éviter innerHTML en JavaScript
innerHTML peut exécuter du code.
Préférer :
- textContent
- createElement
Guide sécurité DOM :
https://developer.mozilla.org/fr/docs/Web/API/Element/innerHTML
Bonnes pratiques générales
Un site sécurisé :
- filtre toutes les entrées
- échappe toutes les sorties
- utilise HTTPS
- protège les cookies
- applique CSP
Ce sont des bases indispensables aujourd’hui.
Tester les failles XSS
Des outils existent pour tester la sécurité :
OWASP ZAP :
https://www.zaproxy.org/
Burp Suite :
https://portswigger.net/burp
Ces outils permettent de simuler des attaques pour corriger les failles avant les hackers.
Conclusion
Les failles XSS sont parmi les vulnérabilités web les plus courantes… et les plus sous-estimées.
Mais la bonne nouvelle, c’est qu’elles sont aussi parmi les plus faciles à éviter quand on applique les bonnes pratiques.
Filtrer. Échapper. Valider.
Trois mots qui peuvent sauver ton application.
