React dangerouslySetInnerHTML : vos composants sont des portes ouvertes au XSS
Le piège du CMS content
Quand votre application React affiche du contenu HTML depuis un CMS ou une API, vous utilisez probablement dangerouslySetInnerHTML. Le nom est un avertissement : mais beaucoup l'ignorent.
Le risque concret
Si le contenu injecté contient du JavaScript malveillant (<script>, onerror=, onload=), il sera exécuté dans le navigateur de l'utilisateur. Vol de cookies, redirection vers un site de phishing, exfiltration de données.
La solution : DOMPurify
Utilisez DOMPurify pour sanitizer le HTML avant de l'injecter : dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(content) }}.
Ce que nous trouvons
Dans les applications React que nous auditons, 40% utilisent dangerouslySetInnerHTML sans sanitization. C'est une faille XSS directe.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
XSS expliqué : reflected, stored, DOM-based, comment se protéger
Les trois types de Cross-Site Scripting décortiqués avec des exemples concrets, les vecteurs d'attaque courants et les défenses à implémenter.
Firebase Firestore : pourquoi 'allow read, write: if request.auth != null' n'est pas une sécurité
La règle d'authentification basique de Firestore ne protège pas vos données. Voici pourquoi et comment corriger.
n8n webhooks : pourquoi vos automations sont vulnérables aux attaques
Les webhooks n8n exposés dans le frontend permettent des attaques non authentifiées. Voici comment sécuriser vos workflows.
Sources
Analyse éditoriale fondée sur la documentation officielle des éditeurs, projets et autorités concernées.
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.