À chaque fois qu’un utilisateur saisit du contenu dans un éditeur WYSIWYG, une question silencieuse mais déterminante se pose : peut-on faire confiance à ce qui est enregistré ? Derrière l’apparente simplicité d’un champ de texte enrichi se cache une problématique centrale du web moderne : La sécurité du HTML généré. TinyMCE, largement adopté dans les CMS et les applications métiers, agit comme une interface entre l’humain et le code. Pourtant, sans une configuration rigoureuse, il peut devenir un point d’entrée pour des failles de sécurité, notamment les attaques XSS. Comprendre comment TinyMCE gère le nettoyage du HTML, la sanitisation des contenus, les balises autorisées et les rôles utilisateurs est donc indispensable pour garantir la fiabilité d’un site ou d’une application web.

Quels sont les risques de sécurité liés au html dans un éditeur wysiwyg ?

TinyMCE permet à un utilisateur de produire du HTML sans en avoir conscience. Cette abstraction est précieuse pour l’ergonomie, car elle supprime la barrière technique liée à l’écriture du code. Toutefois, elle introduit un décalage dangereux entre ce que l’utilisateur pense saisir (du texte mis en forme) et ce qui est réellement généré (du code HTML interprété par le navigateur). Dès lors que ce contenu est stocké, affiché ou réutilisé sans contrôle strict, il devient un vecteur potentiel de failles de sécurité. Le danger principal reste l’injection de code malveillant, en particulier les attaques XSS (Cross-Site Scripting). Ces attaques exploitent le fait que le navigateur fait confiance au HTML reçu depuis le serveur. Si un script malveillant est injecté dans le contenu, il sera exécuté avec les mêmes privilèges que le site lui-même, ce qui peut avoir des conséquences lourdes pour les utilisateurs comme pour l’infrastructure.

Une attaque XSS consiste à injecter du JavaScript dans un champ de contenu afin qu’il soit exécuté dans le navigateur d’un autre utilisateur. Dans un éditeur comme TinyMCE, cela peut passer par des balises <script>, mais aussi par des méthodes plus subtiles. Des attributs HTML détournés comme onload, onclick ou onerror peuvent être utilisés pour déclencher du code sans balise script explicite. De même, des URLs piégées dans des liens ou des images, utilisant des schémas comme javascript: ou data:, peuvent servir de point d’entrée à une attaque. Les risques ne se limitent pas à l’exécution de scripts visibles. Un code injecté peut rester discret, enregistrer les frappes clavier, voler des cookies de session, rediriger l’utilisateur vers un site frauduleux ou modifier dynamiquement le contenu affiché. Dans un back-office, ces attaques sont parfois encore plus dangereuses, car elles ciblent des comptes à privilèges élevés. Il existe plusieurs formes de XSS, chacune correspondant à un mode d’exploitation différent :

• XSS stockée : Le code malveillant est enregistré en base de données et exécuté à chaque affichage du contenu concerné. C’est la forme la plus dangereuse dans un CMS ou un outil collaboratif ;
• XSS réfléchie : Le script est renvoyé immédiatement via une requête, souvent à travers une URL ou un formulaire, et s’exécute sans être stocké durablement ;
• XSS DOM-based : L’attaque repose sur une manipulation du DOM côté client, sans nécessairement impliquer le serveur, en exploitant du JavaScript déjà présent sur la page.

Dans le cas de TinyMCE, le scénario le plus fréquent concerne la XSS stockée. Un utilisateur injecte du code dans un contenu éditorial, volontairement ou non, et ce contenu est ensuite affiché à d’autres visiteurs, contributeurs ou administrateurs. Même dans un environnement restreint au back-office, ce type de faille peut permettre une élévation de privilèges, le vol de sessions administrateur ou la prise de contrôle partielle du site. Au-delà des XSS, d’autres risques existent également. Un HTML mal contrôlé peut casser la mise en page globale d’un site, injecter des iframes non désirées, charger des ressources externes compromises ou introduire des dépendances vers des scripts tiers non maîtrisés. Ces problèmes sont souvent sous-estimés, car ils ne relèvent pas directement d’une attaque visible, mais ils fragilisent l’ensemble de l’écosystème technique.

Il est donc essentiel de comprendre que TinyMCE n’est pas un pare-feu. L’éditeur propose des mécanismes de filtrage et de validation du HTML, mais la sécurité finale dépend toujours de la configuration mise en place, du traitement côté serveur et du CMS hôte. L’erreur fréquente consiste à croire que l’éditeur suffit à lui seul à bloquer toute forme d’attaque, alors qu’il ne représente qu’une première ligne de défense dans une stratégie de sécurité globale.

La sanitisation du contenu html dans TinyMCE : Mécanismes et configuration

TinyMCE intègre nativement un système de nettoyage du HTML basé sur une liste blanche de balises et d’attributs autorisés. Ce principe de whitelist est fondamental en matière de sécurité : tout ce qui n’est pas explicitement défini comme acceptable est supprimé, corrigé ou neutralisé. Contrairement à une approche par liste noire, souvent contournable, cette logique réduit considérablement la surface d’attaque, à condition d’être appliquée avec rigueur et cohérence. Lorsqu’un utilisateur saisit ou colle du contenu, TinyMCE analyse la structure HTML générée avant de l’enregistrer dans l’éditeur. Les balises non reconnues, mal formées ou jugées dangereuses sont automatiquement retirées. Ce processus contribue à produire un code plus propre, plus prévisible et plus facile à sécuriser côté serveur et lors de l’affichage. Le cœur du mécanisme de sanitisation repose sur plusieurs options de configuration clés, qui permettent d’adapter précisément le comportement de l’éditeur au contexte du projet :

• valid_elements : définit précisément les balises HTML autorisées et leurs attributs. Cette option constitue la base de la politique de sécurité du contenu éditorial ;
• extended_valid_elements : permet d’ajouter des exceptions maîtrisées, par exemple pour autoriser un attribut spécifique sur une balise donnée sans ouvrir l’ensemble du HTML ;
• invalid_elements : supprime explicitement certaines balises, même si elles pourraient être autorisées par ailleurs, comme script, iframe ou object ;
• verify_html : force la validation du HTML généré et corrige automatiquement les structures incorrectes ou incomplètes.

Par défaut, TinyMCE adopte une configuration relativement permissive afin de répondre aux besoins génériques des CMS et offrir une expérience utilisateur fluide. Cette souplesse est appréciable pour des usages simples, mais elle devient rapidement problématique dans un contexte professionnel, collaboratif ou exposé à des utilisateurs non maîtrisés. Il est alors recommandé de restreindre volontairement les possibilités de mise en forme.

Dans la majorité des cas éditoriaux, autoriser un ensemble limité de balises HTML comme <strong>, <em>, <p>, <ul>, <li> et <img> est largement suffisant. Cette approche favorise un HTML sémantique, lisible et cohérent avec les feuilles de style du site, tout en limitant les risques liés à des balises plus complexes ou détournables. Les attributs HTML doivent faire l’objet d’une vigilance particulière. Autoriser href sur les balises <a> implique également de contrôler strictement les protocoles acceptés, comme http, https ou mailto. TinyMCE intègre des mécanismes de filtrage des URLs dangereuses telles que javascript: ou vbscript:, mais ces protections ne doivent jamais être considérées comme suffisantes à elles seules.

La gestion des images constitue un autre point sensible. Les attributs src, alt ou title doivent être encadrés pour éviter le chargement de ressources externes non fiables ou l’injection de contenus indésirables. Dans certains contextes, il est préférable de forcer l’utilisation d’une médiathèque interne plutôt que d’autoriser des URLs libres. TinyMCE propose également des outils spécifiques pour le nettoyage du contenu collé depuis des sources externes. L’option paste_as_text ou les plugins dédiés au collage permettent de supprimer les styles inline, les balises superflues et les structures complexes issues de Word ou Google Docs. Ces contenus importés sont souvent surchargés de balises inutiles, ce qui complique la maintenance et augmente les risques de comportements inattendus.

Un point souvent négligé concerne le fait que TinyMCE agit exclusivement côté client. Cela signifie que le HTML généré peut être modifié avant l’envoi, intercepté ou totalement contourné via des requêtes HTTP manuelles. Un utilisateur malveillant n’est pas obligé d’utiliser l’éditeur tel qu’il est prévu pour soumettre du contenu. C’est pourquoi toute stratégie de sanitisation mise en place dans TinyMCE doit impérativement être complétée par un filtrage côté serveur. Des bibliothèques spécialisées comme HTML Purifier, ou les fonctions natives de WordPress telles que wp_kses, permettent de valider et nettoyer le HTML avant son stockage ou son affichage. Cette double couche de protection garantit que même un contenu manipulé en dehors de l’éditeur ne pourra pas compromettre la sécurité globale de l’application.

Pour aller plus loin avec sécurité et nettoyage du html dans tinymce

La gestion des rôles utilisateurs joue un rôle central dans la sécurisation de TinyMCE. Tous les utilisateurs ne devraient pas bénéficier des mêmes capacités d’édition, car le risque n’est pas le même selon le niveau de confiance, l’exposition du contenu et l’impact potentiel d’une injection. Dans WordPress, par exemple, un administrateur peut avoir accès à un éditeur plus permissif qu’un contributeur ou un auteur. Cette différenciation limite considérablement les risques, en particulier sur les sites collaboratifs, les intranets, les plateformes multi-auteurs ou les back-offices d’applications métiers.

L’objectif est simple : appliquer le principe du moindre privilège. Un utilisateur ne doit pouvoir produire que le HTML strictement nécessaire à sa mission. Plus la surface d’édition est large (balises avancées, styles inline, iframes, scripts, attributs personnalisés), plus le champ d’attaque s’agrandit. Dans la pratique, cela implique de configurer TinyMCE par profil et de coupler cette configuration à un filtrage côté serveur, lui aussi adapté aux capacités réelles de chaque rôle. Il est recommandé d’adapter la configuration de TinyMCE selon les profils :

• Un contributeur peut disposer d’un éditeur limité aux balises de base (paragraphes, emphases, listes, liens simples), avec une politique de collage restrictive.
• Un éditeur peut gérer les images, les tableaux, les liens, les citations, et quelques options de mise en forme supplémentaires, dans un cadre défini.
• Un administrateur peut accéder à des options avancées, mais idéalement sous surveillance, avec des garde-fous et des audits.

Concrètement, cette segmentation peut se traduire par des barres d’outils TinyMCE différentes, des listes de balises autorisées distinctes, des plugins activés/désactivés selon le rôle, et des règles de sanitisation côté serveur qui ne traitent pas tous les contenus de la même façon. Dans WordPress, cette logique est d’autant plus importante que la plateforme applique des règles différentes selon les capacités de l’utilisateur. Les comptes dotés de privilèges élevés peuvent parfois publier des contenus plus permissifs, tandis que les profils moins privilégiés subissent un nettoyage renforcé. Sur un site multi-auteurs, il est généralement préférable de ne pas chercher à “débrider” l’édition pour tout le monde, même si cela semble pratique, car cela revient souvent à abaisser le niveau de sécurité global. Au-delà des rôles, la sécurisation d’un éditeur comme TinyMCE repose sur une approche de défense en profondeur. Chaque couche participe à la protection globale :

• L’éditeur applique un premier niveau de nettoyage (whitelist, suppression de balises, contrôle du collage).
• Le serveur effectue une sanitisation finale et non contournable avant stockage ou rendu.
• Le CMS gère les permissions, la séparation des capacités et les règles de publication.
• Le navigateur applique des politiques comme la CSP (si configurée) et les restrictions modernes sur certains comportements.

Pour renforcer encore ce dispositif, plusieurs bonnes pratiques peuvent être mises en place dans un contexte TinyMCE, notamment lorsque l’application est exposée à des utilisateurs externes :

• Limiter ou interdire les styles inline : Autoriser style partout revient souvent à laisser entrer des comportements imprévus (mise en page cassée, masquage de contenu, contournements). Privilégier des classes contrôlées ou des formats prédéfinis ;
• Encadrer strictement les liens : Forcer des protocoles autorisés, éviter les schémas exotiques, vérifier les redirections et appliquer des attributs pertinents selon le contexte (par exemple rel) ;
• Maîtriser l’insertion de médias : Éviter les images externes si possible, privilégier une médiathèque interne, valider les URLs, contrôler les types MIME et les métadonnées lors de l’upload ;
• Éviter l’autorisation d’iframes : Si l’intégration d’embed est nécessaire (vidéos, cartes), passer par une liste de domaines autorisés et un mécanisme d’intégration encadré plutôt que de laisser l’utilisateur coller du code ;
• Réduire les plugins activés : Chaque plugin TinyMCE (tableaux avancés, import, code view, etc.) augmente les possibilités HTML et doit être justifié par un besoin réel ;
• Nettoyer le collage : Imposer le collage en texte brut ou appliquer un filtrage robuste des balises et attributs importés depuis des outils bureautiques.

Un aspect souvent sous-estimé concerne la traçabilité : si l’éditeur est utilisé dans un environnement à plusieurs auteurs, il est utile de savoir “qui a publié quoi”, et surtout “qui a introduit quel code”. Mettre en place des logs, conserver l’historique des révisions, et permettre un retour arrière rapide améliore la résilience en cas de contenu problématique. Cela ne remplace pas la sanitisation, mais cela accélère la remédiation. Enfin, il est essentiel de tester régulièrement le comportement de TinyMCE face à des contenus volontairement malformés. Ces tests ne doivent pas seulement viser les balises <script>, mais aussi les contournements courants :

• attributs événementiels (onerror, onload, onclick) sur des balises courantes
• URLs dangereuses dans href ou src (schémas inattendus, encodages, variantes)
• HTML cassé ou volontairement ambigu (balises non fermées, imbrications atypiques)
• collages depuis Word/Docs générant un HTML très verbeux et difficile à filtrer
• tentatives de contournement via une requête HTTP manuelle, sans passer par l’interface TinyMCE

Simuler des injections XSS, analyser le HTML final enregistré, vérifier le rendu réel côté front, et contrôler le filtrage serveur permet d’anticiper les failles avant qu’elles ne soient exploitées. La sécurité n’est pas un état figé, mais un processus continu : mises à jour de TinyMCE, évolution des navigateurs, ajout de plugins, modifications de rôles ou d’autorisations… chaque changement peut modifier l’équilibre.

En maîtrisant les mécanismes de sanitisation, les balises autorisées et la gestion des rôles utilisateurs, TinyMCE devient un outil fiable et maîtrisé, capable de concilier confort éditorial et exigences de sécurité. Dans un écosystème web où le contenu est omniprésent, cette maîtrise constitue un socle indispensable pour toute application ou CMS moderne reposant sur l’édition HTML.