flawopen.com/XSS en JavaScript/dangerouslySetInnerHTML

dangerouslySetInnerHTML est-il sûr dans React ?

Page de référence

Réponse courte

Imaginez le JSX ordinaire comme une imprimante d’étiquettes : le texte reste du texte. dangerouslySetInnerHTML devient une presse qui interprète la chaîne comme du HTML. Si elle contient du contenu contrôlé par un attaquant, le navigateur peut le traiter comme du balisage actif. N’utilisez ce point que pour du HTML explicitement fiable ou assaini pour le contexte HTML précis.

Pourquoi le JSX ordinaire n’en a pas besoin

RISQUÉ — injection de HTML brut

function Comment({ html }) {
  return <p dangerouslySetInnerHTML=
    {{ __html: html }} />;
}

SÛR — interpolation JSX ordinaire

function Comment({ text }) {
  return <p>{text}</p>;
}

Quand utiliser dangerouslySetInnerHTML ?

Utilisez-le uniquement si le produit doit préserver un format de texte enrichi limité qui ne peut pas être représenté par des enfants React ordinaires. Un CMS, un éditeur ou un moteur Markdown n’est pas automatiquement fiable : le contenu stocké et la sortie du moteur peuvent contenir du balisage non fiable. Définissez les éléments et attributs autorisés, assainissez avec une bibliothèque maintenue comme DOMPurify, puis transmettez directement le résultat assaini à ce point.

Bien l’utiliser

Assainir à la frontière de rendu

Assainissez juste avant d’affecter la valeur à dangerouslySetInnerHTML avec une bibliothèque maintenue telle que DOMPurify. N’utilisez pas d’expressions régulières comme assainisseur HTML. Évitez de modifier la chaîne après l’assainissement : une transformation ultérieure peut invalider ses garanties. Maintenez à jour l’assainisseur et son environnement d’analyse.

Limiter le balisage autorisé

Une liste noire de balises connues est incomplète : le risque peut aussi venir des attributs, des champs contenant des URL, des espaces de noms et du comportement de l’analyseur. Choisissez une courte liste d’éléments et d’attributs nécessaires à la fonctionnalité et configurez l’assainisseur en conséquence. Examinez séparément les liens et autres attributs d’URL selon les destinations permises par le produit.

Vérifier votre code

grep -rn "dangerouslySetInnerHTML" --include="*.jsx" --include="*.tsx" .

Pour chaque occurrence, remontez de la source de la valeur à toutes ses transformations. Considérez les entrées utilisateur, les contenus importés et le texte enrichi stocké comme non fiables ; vérifiez que la politique d’assainissement convient au contexte de sortie et qu’aucune étape ultérieure ne modifie le résultat.

Questions fréquentes

Le rendu Markdown est-il automatiquement sûr ?

Cela dépend du moteur et de sa configuration. Vérifiez s’il accepte le HTML brut et s’il assainit sa sortie ; la conversion Markdown ne rend pas automatiquement le HTML sûr.

Cela concerne-t-il aussi v-html dans Vue ?

Oui. v-html transmet également du HTML au navigateur sans l’interpolation de texte ordinaire du framework. Traitez cette valeur comme un point d’injection HTML et assainissez les contenus non fiables selon une politique adaptée.

Références

À voir aussi Cross-Site Scripting (XSS, CWE-79) : fonctionnement et prévention dans chaque langage — flawopen.com DOMPurify suffit-il pour sécuriser innerHTML ? Markdown protège-t-il contre les XSS ? 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 ?