🧬 Cross-Site Scripting XSS — Guide HTML IDEO-Lab

Mécanique

Un navigateur n’exécute pas une page comme un texte linéaire. Il parse successivement du HTML, des attributs, des URL, du CSS, du JavaScript et des événements DOM. Une même chaîne peut être inoffensive dans un texte HTML, dangereuse dans un attribut, catastrophique dans une chaîne JavaScript et ambiguë dans une URL. La sécurité XSS est donc une sécurité de contexte, pas une simple recherche de caractères interdits.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Mini-scène pédagogique

Anti-pattern

Recherche affichée directement : <p>Résultat pour : {{ q|safe }}</p>
La donnée q peut devenir une partie de la page plutôt qu’un simple texte.

Correction attendue

Recherche affichée comme texte : <p>Résultat pour : {{ q }}</p>
Le moteur de template encode la donnée dans le contexte HTML attendu.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Cartographier les zones où les données utilisateur sont réaffichées.
• Identifier les contextes de sortie : HTML, attribut, JS, URL, CSS, DOM.
• Interdire les contournements de template du type safe/raw sans justification.
• Prévoir un test XSS dans chaque revue de fonctionnalité exposée.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

La même valeur traverse souvent plusieurs couches : requête HTTP, serveur, template, JSON, JavaScript client, DOM. Chaque changement de couche peut créer un nouveau contexte. Une donnée encodée correctement pour du HTML peut devenir dangereuse si elle est ensuite réutilisée dans un script ou injectée via innerHTML. Les failles modernes viennent souvent de ces réutilisations invisibles.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Chaîne de confiance simplifiée

Anti-pattern

const name = new URLSearchParams(location.search).get("name");
document.querySelector("#hello").innerHTML = name; // anti-pattern pédagogique

Correction attendue

const name = new URLSearchParams(location.search).get("name");
document.querySelector("#hello").textContent = name; // texte, pas HTML

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Lister les sources de données côté client.
• Lister les sinks DOM dangereux.
• Remplacer innerHTML par textContent lorsque du HTML n’est pas requis.
• Ajouter des tests unitaires sur les composants qui rendent du contenu externe.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Le reflected XSS touche souvent les paramètres de recherche, messages d’erreur ou redirections. Le stored XSS vise commentaires, profils, tickets, noms de fichiers, logs visibles, champs CMS. Le DOM XSS naît dans les scripts front-end : une source comme location.hash ou postMessage alimente un sink comme innerHTML. Le blind XSS se déclenche plus tard, dans une console admin ou un outil support.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Cartographie rapide

Anti-pattern

Champ commentaire enregistré puis rendu avec un filtre raw/safe dans le back-office.

Correction attendue

Champ commentaire rendu comme texte, ou HTML autorisé passé dans un sanitizer avec allowlist stricte.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Classer chaque finding XSS par famille.
• Prioriser stored/blind/admin.
• Tester les zones d’administration, pas seulement le front public.
• Inclure les champs peu visibles : nom fichier, libellé, tag, user-agent, logs.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Les parseurs changent de mode selon les caractères rencontrés. Dans le corps HTML, les caractères critiques sont notamment <, >, &, guillemets selon le contexte. Dans un attribut, les guillemets et espaces modifient la structure. Dans JavaScript, les quotes, backticks, antislashs, fins de ligne et séquences Unicode ont une autre signification. Dans CSS et URL, d’autres règles s’appliquent. Une solution générique unique est donc insuffisante.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Table de décision

Anti-pattern

<a href="{{ user_url }}">Profil</a> sans validation de schéma ni encodage adapté.

Correction attendue

Valider le schéma http/https, normaliser l’URL, encoder l’attribut, refuser javascript:, data: et schémas inattendus.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Identifier le contexte de chaque interpolation.
• Supprimer les attributs événementiels dynamiques.
• Éviter les templates JS inline avec variables non sérialisées.
• Ajouter une revue dédiée aux href, src, srcdoc, style et data-* exploités par JS.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

La donnée peut être proprement validée à l’entrée, puis devenir dangereuse à la sortie si elle est rendue dans le mauvais contexte. Un nom de fichier affiché dans un tableau admin, un user-agent dans un viewer de logs ou le titre d’un ticket dans une notification HTML peuvent devenir des points d’exécution. Le XSS stocké se nourrit des interfaces secondaires que personne ne considère comme publiques.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Ticket support

Anti-pattern

Titre ticket enregistré : contenu utilisateur rendu en HTML dans une console support avec |safe.

Correction attendue

Titre ticket rendu comme texte ; description riche sanitizée côté serveur ; aperçu admin soumis aux mêmes règles que le front.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Auditer admin, support, CRM, reporting, exports HTML.
• Traiter logs et user-agent comme entrées hostiles.
• Désactiver HTML riche si non nécessaire.
• Ajouter une validation sécurité aux composants de rendu communs.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

L’exploitation dépend fréquemment d’un lien transmis à une victime. Le risque réel dépend du contexte d’exécution, des cookies, des droits de la victime, de la CSP et des protections de session. Même lorsqu’il n’y a pas de persistance, l’impact peut être élevé si la victime est authentifiée ou si la page contient des données sensibles.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Recherche

Anti-pattern

<p>Recherche : {{ request.GET.q|safe }}</p>

Correction attendue

<p>Recherche : {{ request.GET.q }}</p> avec auto-escape et aucun HTML attendu.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Tester les paramètres visibles dans l’HTML.
• Vérifier les pages d’erreur personnalisées.
• Refuser les redirections ouvertes dangereuses.
• Contrôler les bannières flash/messages système.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Une page peut sembler sûre côté serveur : aucune charge dangereuse n’apparaît dans la réponse initiale. Pourtant, le code client peut lire location.hash, localStorage, postMessage ou une réponse API et construire ensuite du HTML. Les scans purement serveur ratent souvent cette classe ; il faut analyser le flux source → sink dans le JavaScript exécuté.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Source → sink

Anti-pattern

const html = location.hash.slice(1);
preview.innerHTML = html;

Correction attendue

const text = location.hash.slice(1);
preview.textContent = text;

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Chercher innerHTML et insertAdjacentHTML dans le dépôt.
• Contrôler les handlers postMessage et origines autorisées.
• Encadrer les composants Markdown/WYSIWYG.
• Activer un mode CSP report-only pour repérer les scripts inline.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

L’encodage doit se produire le plus près possible de la sortie, car le contexte final est connu à cet endroit. Encoder trop tôt peut provoquer des doubles encodages ou donner une fausse impression de sécurité. La validation d’entrée reste utile pour la qualité métier, mais ne remplace pas l’encodage de sortie.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Django template

Anti-pattern

{{ comment.body|safe }}  {# dangereux si comment.body vient d’un utilisateur #}

Correction attendue

{{ comment.body }}  {# auto-escape HTML par défaut #}

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Rechercher safe, raw, mark_safe, dangerouslySetInnerHTML.
• Documenter chaque exception.
• Créer un helper unique pour JSON dans script.
• Tester les caractères < > & " '.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Un sanitizer robuste comprend les subtilités de parsing HTML/SVG/MathML, les attributs événementiels, URL dangereuses, namespaces, mutations DOM et cas limites navigateur. Une regex maison est insuffisante. La sanitation doit être appliquée avant l’insertion dans le DOM et configurée selon le besoin exact : tags autorisés, attributs autorisés, protocoles autorisés, liens rel=noopener, images éventuellement proxyfiées.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

HTML riche contrôlé

Anti-pattern

preview.innerHTML = markdownToHtml(userMarkdown); // sans sanitation

Correction attendue

const dirty = markdownToHtml(userMarkdown);
const clean = DOMPurify.sanitize(dirty, { USE_PROFILES: { html: true } });
preview.innerHTML = clean;

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Justifier le besoin de HTML riche.
• Utiliser un sanitizer maintenu.
• Tester SVG, liens, images, tableaux et attributs data.
• Interdire la configuration locale dispersée.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Une CSP efficace évite 'unsafe-inline', utilise des nonces ou hashes pour les scripts autorisés, définit object-src 'none', base-uri 'self', frame-ancestors, connect-src et img-src selon le besoin. Trusted Types force certains sinks à recevoir des objets TrustedHTML/TrustedScript créés par des politiques explicites, ce qui rend les erreurs innerHTML beaucoup plus visibles.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Politique de départ

Anti-pattern

Content-Security-Policy: script-src * 'unsafe-inline' 'unsafe-eval'

Correction attendue

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{RANDOM}'; object-src 'none'; base-uri 'self'; require-trusted-types-for 'script'; trusted-types app-sanitizer;

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Commencer par report-only.
• Supprimer les scripts inline non nécessaires.
• Mettre en place nonces côté serveur.
• Collecter et analyser les rapports CSP.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

HttpOnly empêche JavaScript de lire un cookie, mais n’empêche pas une action authentifiée depuis la page compromise. SameSite réduit certaines attaques intersites, Secure impose HTTPS, et une rotation de session limite la durée d’exploitation. Les tokens stockés dans localStorage restent accessibles au JavaScript injecté et constituent donc un risque important.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Cookie de session durci

Anti-pattern

Set-Cookie: sessionid=abc123

Correction attendue

Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Vérifier flags cookies en production.
• Éviter tokens sensibles dans localStorage.
• Segmenter les sessions admin.
• Ajouter step-up pour actions critiques.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

La règle est simple : rester dans le chemin sûr du framework. Dans Django, l’autoescape protège le rendu HTML standard ; les filtres safe/mark_safe doivent être exceptionnels. Dans React, l’interpolation texte est échappée ; dangerouslySetInnerHTML doit être réservé au HTML sanitizé. Dans Angular, les bypass de sanitizer sont des exceptions de sécurité. Les composants tiers doivent être considérés comme code exécutable importé.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Chemins sûrs et dangereux

Anti-pattern

React : <div dangerouslySetInnerHTML={{ __html: userHtml }} />
Django : {{ user_html|safe }}

Correction attendue

React : <div>{userText}</div>
Django : {{ user_text }}
HTML riche : sanitizer central + revue sécurité.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Scanner les contournements framework.
• Créer une liste d’exceptions approuvées.
• Auditer composants tiers et éditeurs riches.
• Former les équipes front/back sur les contextes.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Un bon plan de test commence par l’inventaire des entrées : formulaires, URL, API, import fichiers, WebSocket, postMessage, Markdown, WYSIWYG, logs, champs admin. Chaque entrée est suivie jusqu’aux sorties. Les tests doivent utiliser des chaînes canaris neutralisées qui révèlent les changements de contexte sans déclencher de charge agressive.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Canari neutralisé

Anti-pattern

Test limité à “le champ est validé en entrée”.

Correction attendue

Injecter une chaîne canari encodée dans chaque champ, puis vérifier tous les rendus : front, admin, email HTML, export, logs, notifications.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Inclure XSS dans la définition de terminé.
• Tester front public et back-office.
• Automatiser recherche safe/raw/innerHTML.
• Documenter chaque correction avec contexte exact.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Les filtres génériques peuvent produire des faux positifs, rater des encodages alternatifs, ignorer le DOM XSS client ou bloquer des usages légitimes. Ils sont utiles comme couche de protection, notamment lors d’une crise ou en attente de patch, mais la correction durable doit se situer dans le rendu applicatif et les composants front-end.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Positionnement correct

Anti-pattern

Finding XSS fermé parce que “le WAF bloque la chaîne de test”.

Correction attendue

WAF utilisé en mitigation temporaire ; ticket de correction maintenu jusqu’à encodage/sanitation côté application.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Marquer les règles WAF temporaires.
• Relier chaque règle à un ticket de correction.
• Analyser les endpoints les plus touchés.
• Ne jamais considérer le WAF comme unique défense XSS.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

La chronologie doit relier point d’entrée, payload neutralisé ou contenu suspect, première apparition, pages touchées, comptes victimes, appels API anormaux, changements de configuration, transferts de données et éventuelles escalades. En cas de stored XSS, la suppression ou neutralisation du contenu stocké est prioritaire avant même la correction complète.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Runbook court

Anti-pattern

Corriger le template puis fermer l’incident sans vérifier les sessions et actions passées.

Correction attendue

Neutraliser le contenu, bloquer exploitation, invalider sessions exposées, analyser logs, corriger, déployer CSP/monitoring, rédiger post-mortem.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Conserver les preuves avant purge si possible.
• Invalider les sessions à risque.
• Vérifier actions sensibles réalisées pendant la fenêtre.
• Ajouter tests et règles de détection après correction.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Le jeu pédagogique peut suivre un format en quatre cartes : source, contexte, sink, correction. L’apprenant reçoit un extrait de code, identifie le contexte de sortie, choisit la bonne API ou le bon encodage, puis vérifie le résultat. Les scores ne récompensent pas l’attaque, mais la correction : suppression du sink dangereux, choix du contexte, test de non-régression et explication claire.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Carte de jeu

Anti-pattern

Niveau 1 : “Le message utilisateur est rendu avec innerHTML. Trouver le problème.”

Correction attendue

Solution : remplacer par textContent, ajouter test, expliquer pourquoi la donnée devait rester du texte.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Créer des exercices par contexte.
• Utiliser des chaînes canaris neutralisées.
• Noter la correction, pas la charge.
• Intégrer les résultats à la formation développeur.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Le modèle cible impose : autoescape actif, composants de rendu communs, helper unique pour HTML riche, sanitizer central, CSP stricte, Trusted Types pour les applications compatibles, cookies durcis, linters anti-sinks, tests CI, revue des exceptions, inventaire des composants tiers et observabilité CSP. Les exceptions existent, mais elles sont documentées, validées et révisées.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Pipeline sécurisé

Anti-pattern

Chaque équipe choisit ses propres helpers, sanitizers et exceptions safe/raw.

Correction attendue

Bibliothèque interne de rendu : Text, SafeLink, RichHtmlSanitized, JsonScript, MarkdownSafe, tous testés et documentés.

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Créer des composants de rendu communs.
• Bloquer les patterns dangereux en CI.
• Standardiser CSP et cookies.
• Revoir régulièrement les exceptions.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.

Mécanique

Le réflexe opérationnel suit cinq questions : quelle est la source ? quel est le contexte de sortie ? quel sink reçoit la donnée ? quelle défense est appliquée ? quel test prouve que le navigateur ne change pas d’interprétation ? Si une seule réponse manque, la zone mérite une revue.

Chaîne source → sink

Source non fiable
  ↓
Transformation / stockage
  ↓
Contexte de sortie
  ↓
Sink de rendu
  ↓
Interprétation navigateur
  ↓
Test + monitoring

Décision express

Anti-pattern

“Le champ est validé, donc il est sûr partout.”

Correction attendue

“La sortie est en contexte HTML texte, donc autoescape suffit ; si le contexte change, la défense change.”

Raison pédagogique

L’exemple illustre le raisonnement de défense, sans fournir de scénario offensif ni de contournement. L’objectif est de reconnaître le mauvais contexte, de choisir l’API sûre et de documenter la correction.

Checklist

• Aucun raw/safe non justifié.
• Aucun innerHTML avec données non fiables.
• HTML riche centralisé et sanitizé.
• CSP active et surveillée.
• Tests XSS intégrés au CI/CD.

Critère de sortie

La zone est considérée maîtrisée lorsque le contexte de rendu est identifié, la défense est contextuelle, les tests confirment l’absence d’interprétation active et les exceptions sont documentées.