Markdown protège-t-il contre les XSS ?

Guide de référence

Réponse courte

Traitez le HTML produit à partir de Markdown comme un contenu non fiable. Un parseur peut conserver le HTML brut, car la syntaxe l'autorise ; convertir Markdown ne nettoie pas le résultat. Le parseur traduit le balisage, il ne joue pas le rôle d'un filtre de sécurité.

Où se situe la frontière de confiance

La spécification CommonMark prévoit que le HTML brut ressemblant à une balise est rendu sans échappement. Le comportement dépend du parseur, de ses options, des extensions et du framework. Marked précise par exemple qu'il ne nettoie pas le HTML produit. La syntaxe Markdown ne prouve pas que l'entrée est sûre ; le nettoyage doit protéger la destination HTML finale.

Une chaîne de rendu sûre

NON SÛR — insérer une sortie non fiable

const html = marked.parse(userMarkdown);
container.innerHTML = html; // sortie non nettoyée

RENFORCÉ — nettoyer juste avant le puits HTML

import DOMPurify from "dompurify";

const html = marked.parse(userMarkdown);
container.innerHTML = DOMPurify.sanitize(html, {
  USE_PROFILES: { html: true }
});

L'exemple utilise le profil HTML seul de DOMPurify, car cette vue n'a pas besoin de SVG ni de MathML. Limitez les fonctionnalités à celles nécessaires. Ne modifiez pas le balisage nettoyé et ne le transmettez pas à une autre bibliothèque qui transforme le HTML avant l'insertion : cela peut annuler les garanties. Préférez le rendu texte sûr du framework si le HTML enrichi est inutile. Content Security Policy et Trusted Types sont des défenses supplémentaires, pas des substituts au nettoyage.

Contrôles avant production

✓Fixez la version du parseur Markdown et vérifiez ses options HTML, extensions et URL.
✓Nettoyez le HTML final avec un assainisseur à liste d'autorisation maintenu, juste avant le puits HTML.
✓Limitez les éléments, attributs et protocoles URL aux fonctions nécessaires.
✓Ne modifiez ni ne reparséz le balisage après nettoyage ; nettoyez à nouveau après toute transformation requise.
✓Testez la configuration exacte du parseur et le puits de rendu, et maintenez l'assainisseur à jour.

FAQ

Désactiver le HTML brut rend-il Markdown sûr ?

Cela supprime une fonctionnalité d'entrée, mais ne suffit pas à établir la sécurité. Vérifiez liens, images, extensions, HTML généré et contexte d'insertion ; nettoyez la sortie destinée à un puits HTML.

Puis-je modifier le HTML après son nettoyage ?

Évitez-le. Des changements ultérieurs peuvent ajouter un balisage dangereux ou invalider les décisions du nettoyeur. Faites les transformations avant, puis nettoyez en dernier.

DOMPurify rend-il toute sortie sûre dans tous les contextes ?

Non. Utilisez-le pour des fragments HTML conformément à son modèle de menace, gardez-le à jour, appliquez une politique étroite et ne réutilisez pas le résultat dans une chaîne JavaScript ou CSS.

Références

À voir aussi Cross-Site Scripting (XSS, CWE-79) : fonctionnement et prévention dans chaque langage — flawopen.com Svelte protège-t-il du XSS par défaut ? Un téléversement SVG présente-t-il un risque XSS ? Risque XSS de Vue v-html WKWebView : HTML non fiable, sûr ? XSS réfléchi, stocké et DOM : quelles différences ? Risques de sécurité de addJavascriptInterface sur Android