flawopen.com/XSS/Types de XSS
XSS réfléchi, stocké et DOM : quelles différences ?
Les XSS réfléchi, stocké et DOM décrivent différents chemins entre une donnée non fiable et un contexte navigateur dangereux. Ils peuvent se chevaucher : déterminez l’origine de la valeur, sa persistance, le code qui la rend et les utilisateurs concernés.
Les trois types
Une valeur de requête est insérée dans la réponse sans encodage adapté au contexte, puis interprétée par le navigateur comme du balisage ou un script. Un attaquant peut envoyer un lien préparé à une victime, mais la faille est le rendu non sûr des données de requête. Corrigez l’encodage au point de rendu.
Un contenu non fiable est enregistré puis rendu sans protection à d’autres utilisateurs, par exemple dans un commentaire ou un profil. Chaque visiteur qui consulte ce contenu peut recevoir le même contexte dangereux jusqu’à la correction de la valeur stockée ou du chemin de rendu.
Le JavaScript côté client lit une source non fiable (comme location.hash, un paramètre d’URL ou une donnée du serveur) et l’envoie vers un sink DOM non sûr tel que innerHTML. La valeur peut ne jamais atteindre le serveur, mais ce n’est pas requis : XSS DOM décrit le chemin source-sink côté client et peut se combiner avec une livraison réfléchie ou stockée. Corrigez le flux client.
Pourquoi cette distinction guide la correction
Corrigez le XSS au point de rendu avec un encodage adapté au contexte ou une API DOM sûre. Le XSS réfléchi et stocké implique souvent un rendu serveur, mais le rendu client peut aussi créer un sink dangereux. Pour le XSS DOM, préférez textContent à innerHTML pour du texte ; si du HTML riche est nécessaire, utilisez un assainisseur maintenu avec une politique explicite. L’encodage serveur ne remplace pas l’examen des flux source-sink côté client.
Ces catégories peuvent se recouper
Le XSS réfléchi et le XSS stocké décrivent comment l’entrée atteint la page et si elle persiste. DOM-based décrit un flux source-vers-sink côté client. Ces catégories ne s’excluent pas mutuellement : un texte de profil persistant inséré par le code client dans innerHTML peut relever à la fois du XSS stocké et du XSS DOM.
XSS DOM : sink dangereux et rendu en texte brut
const value = new URLSearchParams(location.search).get("q") ?? "";
target.innerHTML = value;
const value = new URLSearchParams(location.search).get("q") ?? "";
target.textContent = value;
Références
- OWASP XSS Prevention Cheat Sheet
- OWASP DOM-based XSS Prevention Cheat Sheet
- flawopen.com — Cross-Site Scripting