Chaque jour, des milliers de sites sont compromis. Dans la grande majorité des cas, le coupable n'est pas une attaque sophistiquée digne d'un film. C'est une extension obsolète ou mal codée. WordPress n'a pas inventé ce risque, mais son architecture en aggrave les conséquences : sur une installation classique, un formulaire de contact défaillant et votre base de données partagent les mêmes clés.
C'est le troisième article de notre série sur EmDash, le CMS open source (système de gestion de contenu) de Cloudflare. Le premier se demandait s'il constituait une alternative crédible à WordPress. Celui-ci s'arrête sur le point qui compte le plus pour une équipe sécurité : ce qui se passe réellement quand une extension est piratée, et pourquoi la réponse d'EmDash, isoler chaque extension au lieu de lui faire confiance, est un vrai changement et pas une formule marketing.
Une précision d'emblée, parce qu'elle conditionne tout le reste : EmDash en est au stade de preview développeur (version 0.1.0). Ce que nous décrivons ici est une architecture, pas un historique de résistance aux attaques. Le modèle est solide. Le recul ne l'est pas encore.
La vulnérabilité monolithique : pourquoi un seul plugin WordPress peut tout posséder
Pour comprendre l'apport d'EmDash, il faut nommer précisément la faiblesse qu'il vise. Ce n'est pas le reproche vague d'un « WordPress pas sûr ». Tout tient à un choix de structure bien précis.
Exécution partagée, privilèges partagés
Sur une installation WordPress standard, le cœur, la base de données et chaque extension s'exécutent dans le même espace, sous le même utilisateur système et avec les mêmes identifiants de base de données. Une extension n'est pas un invité au laissez-passer limité. C'est un occupant à part entière. Le formulaire de contact installé pour une seule page peut, au niveau de l'architecture, lire chaque ligne de votre table d'utilisateurs, parce que rien ne lui dit qu'il ne le peut pas. Le privilège est partagé par défaut.
Ce choix avait du sens au début des années 2000, quand un site tenait en quelques fichiers de confiance. Il vieillit mal dès qu'un site courant embarque vingt ou trente extensions tierces signées par vingt ou trente auteurs différents.
Du formulaire de contact au serveur compromis
Voici l'enchaînement qu'une équipe sécurité a vu se dérouler des centaines de fois. Une extension est livrée avec une faille d'injection SQL (un défaut qui permet à un attaquant de glisser ses propres commandes dans une requête de base de données via un champ de saisie). Comme l'extension détient déjà les identifiants de la base, l'attaquant lit ou réécrit alors n'importe quelle table. Si cette même extension peut aussi écrire des fichiers, cela dégénère souvent en exécution de code à distance (RCE, l'exécution du code de l'attaquant sur le serveur). À ce stade, il hérite de tous les privilèges partagés : exfiltrer la table des utilisateurs, modifier les fichiers du cœur, injecter des scripts malveillants dans les pages servies aux vrais visiteurs, et poser une porte dérobée pour plus tard.
Les extensions abandonnées aggravent le tableau. Du code qui ne reçoit plus de correctif de sécurité, mais qui tourne toujours avec un accès complet, est une invitation permanente.
Le rapport State of WordPress Security 2025 de Patchstack chiffre l'endroit où le danger se loge réellement : sur l'année 2025, 91 % des vulnérabilités WordPress publiées se trouvaient dans des extensions et thèmes tiers plutôt que dans le cœur, après 96 % l'année précédente. Le cœur n'est pas la cible facile. Ce sont les extensions greffées par-dessus.
Sur WordPress, le rayon d'explosion d'une seule extension, c'est le site entier.
Les isolats V8 : comment EmDash met chaque plugin en bac à sable
EmDash exécute chaque extension dans un isolat V8 de Cloudflare, un bac à sable léger qui donne à chaque plugin sa propre tranche de mémoire cloisonnée. Même logique que le monolithe, mais inversée : au lieu d'un seul espace partagé, beaucoup d'espaces scellés.
Ce qu'est vraiment un isolat V8
V8 est le moteur JavaScript que Google a conçu pour Chrome. Un isolat est le mécanisme par lequel V8 empêche un onglet du navigateur de lire la mémoire d'un autre onglet. Cloudflare a réutilisé ce mécanisme sur son réseau : plutôt que d'attribuer à chaque charge de travail son propre conteneur ou sa propre machine virtuelle (lourd, et lent à démarrer), il fait tourner de nombreux isolats dans un même processus, chacun cloisonné des autres. Cloudflare a documenté cette approche dans son article d'ingénierie « Cloud computing without containers ».
Le contraste est net. Un conteneur démarre en centaines de millisecondes et transporte un petit système d'exploitation. Un isolat démarre en quelques millisecondes et ne transporte presque rien. C'est pourquoi il n'y a pas de cold start notable (cette latence de démarrage propre à d'autres plateformes serverless), et c'est ce qui rend l'exécution de chaque extension dans son propre bac à sable abordable plutôt qu'absurde.
Ce que l'isolation empêche, concrètement
Dans EmDash, une extension compromise reste piégée dans son isolat. Elle ne peut pas lire la mémoire du cœur du CMS. Elle ne voit pas l'isolat voisin. Elle n'a aucun accès implicite à la base de données ni au système de fichiers. L'injection SQL qui s'emparerait d'un serveur WordPress se heurte ici à un mur : il n'y a pas d'identifiant de base partagé à détourner, ni de système de fichiers serveur où écrire. La faille existe toujours dans l'extension, mais sa portée s'arrête au bord du bac à sable.
L'isolation ne rend pas une extension exempte de bugs. Elle rend un bug d'extension survivable.
Les manifestes de permissions : la sécurité par capacités, comme une application mobile
Le bac à sable gère ce qu'une extension peut atteindre en mémoire. Une seconde couche gère ce qu'elle a le droit de faire, tout court.
Chaque extension EmDash embarque un manifeste de permissions par capacités : elle doit déclarer en amont exactement les capacités dont elle a besoin, et n'obtient rien au-delà de cette liste. La sécurité par capacités signifie simplement que l'accès est accordé capacité par capacité déclarée, et non hérité de l'environnement alentour.
Déclarer, ou se voir refuser
À la manière d'une application mobile qui doit demander avant de toucher à votre appareil photo ou à vos photos, une extension EmDash énonce ses besoins dans un fichier manifeste. Un exemple simplifié :
{
"name": "Formulaire de contact Pro",
"permissions": {
"content": "read",
"email": "send",
"network": ["api.sendgrid.com"],
"database": false,
"storage": false
}
}Une extension qui demande seulement à lire du contenu, envoyer un e-mail et joindre un unique hôte sortant ne peut pas interroger D1 (la base de données SQL de Cloudflare), ne peut pas toucher R2 (le stockage d'objets de Cloudflare pour les médias) et ne peut ouvrir aucune autre connexion. Tout ce qui n'est pas déclaré est refusé. (Le vocabulaire exact des capacités est défini par EmDash ; considérez les clés ci-dessus comme une illustration du modèle, pas comme une API figée.)
Ce que fait le runtime quand une extension sort du cadre
Le contrôle n'est pas une consigne que l'extension est priée de respecter. Il est appliqué par le runtime Cloudflare Workers, en dessous de l'extension, et non par la bonne volonté de cette dernière. Si une extension dont le manifeste indique "database": false tente malgré tout d'interroger D1, le runtime refuse l'appel. Une extension ne peut pas s'attribuer une capacité qu'elle n'a jamais déclarée, parce que la décision se situe dans la plateforme, là où l'extension ne peut pas l'atteindre. C'est le moindre privilège (chaque composant n'obtient que l'accès dont il a réellement besoin) appliqué par l'architecture, et non par une charte que personne ne relit.
Une permission que vous n'avez jamais accordée est une attaque que vous n'avez jamais à détecter.
Étude de cas : migration WordPress vers Cloudflare EmDash
Nous n'avons pas lu ce modèle quelque part. Nous tournons dessus.
brixio.io a été refait depuis WordPress vers EmDash, Astro et Cloudflare, toutes les anciennes URLs et les positions acquises conservées. Nous avons aussi livré des défenses anti-bots entièrement développées sur Workers pour un client du secteur aérien.
Ce que le sandboxing ne règle pas
L'honnêteté sert mieux le lecteur qu'un récit trop propre.
EmDash est une preview développeur en version 0.1.0. Le modèle de sécurité décrit plus haut est une architecture, pas un historique : il n'a pas été éprouvé par vingt ans d'attaques publiques comme l'a été WordPress, pour le meilleur et pour le pire. Un design solide et un design éprouvé ne sont pas la même chose.
Le sandboxing ne dispense pas non plus du reste d'un programme de sécurité. Un isolat contient une extension compromise, mais il ne vérifie pas ce qu'une extension légitime fait dans son propre périmètre, et il ne remplace ni l'authentification, ni la gestion des secrets, ni la supervision. La disponibilité est encore une autre question : tourner sur le réseau Cloudflare place un site derrière la même bordure (edge) qui absorbe les grosses attaques par déni de service distribué (DDoS), où le trafic est filtré avant d'atteindre votre code, mais défendre la disponibilité sous une charge réelle et soutenue est une discipline à part entière. Nous traitons ce versant dans notre guide de production sur le bot management Cloudflare.
L'architecture réduit la surface d'attaque. Elle ne met pas l'équipe sécurité à la retraite.
Sécuriser le web par l'architecture, pas par la vigilance
La sécurité de WordPress repose sur la confiance et la maintenance : la confiance dans le fait que des milliers de développeurs tiers ont écrit du code sûr, et la discipline quotidienne de patcher quand ce n'était pas le cas. EmDash part de l'hypothèse inverse, qu'une extension peut être hostile, et la confine par conception : un isolat V8 scellé, un jeu de permissions déclarées, un runtime qui refuse par défaut.
La maturité n'y est pas encore. Le modèle, si. Pour une équipe qui démarre aujourd'hui, la sécurité par l'architecture est une fondation plus stable que la sécurité par la vigilance, parce qu'elle continue de fonctionner le jour où tout le monde est trop occupé pour appliquer le correctif. Et quand cette équipe a besoin de fonctionnalités sur mesure construites et exploitées sur la stack, c'est notre développement d'applications sur mesure.
La suite de la série
- Au commencement : pourquoi EmDash se lit comme une alternative moderne et crédible à WordPress, et comment s'imbriquent la stack Cloudflare et Astro. Lire WordPress a-t-il enfin trouvé son successeur ?
- Performance et coût : comment la même architecture vise une facture d'hébergement quasi nulle et des temps de chargement instantanés. Lire Cloudflare Workers vs AWS Lambda : le modèle de coût du serverless. (Article 2)
Questions fréquentes
C'est la faiblesse de structure derrière la plupart des piratages WordPress. Sur une installation standard, le cœur, la base de données et chaque extension s'exécutent dans le même espace avec les mêmes droits d'accès. Une extension détient donc les mêmes privilèges sur la base et le serveur que le site lui-même : un seul plugin compromis ou abandonné peut servir à lire toute la base, altérer les fichiers du cœur ou prendre le contrôle du serveur.
Un isolat V8 est un bac à sable léger issu du moteur JavaScript que Google a conçu pour Chrome, utilisé à l'origine pour empêcher les onglets du navigateur de lire la mémoire les uns des autres. Cloudflare exécute chaque charge de travail Workers dans son propre isolat, cloisonné des autres, qui démarre en quelques millisecondes et évite le cold start du serverless à base de conteneurs. EmDash utilise un isolat par extension.
Chaque extension EmDash déclare dans un manifeste les capacités dont elle a besoin, par exemple lire du contenu ou envoyer un e-mail, et n'obtient rien d'autre. Le runtime Cloudflare Workers fait appliquer ce manifeste : si une extension tente d'utiliser une capacité non déclarée, comme l'accès à la base de données, l'appel est refusé. Le défaut est le refus, donc une extension ne peut pas atteindre des données qu'elle n'a jamais demandées.
Sur le plan de l'architecture, son modèle d'extensions est plus solide, parce que l'isolation et les permissions par capacités confinent une extension compromise au lieu de la laisser atteindre tout le site. En pratique, EmDash est une preview développeur en version 0.1.0 sans le recul de WordPress, donc pour un site critique en production aujourd'hui, la plupart des équipes devraient l'expérimenter plutôt que migrer entièrement.
Non, ce sont deux sujets distincts. Le sandboxing limite ce qu'une extension compromise peut atteindre ; il ne traite pas la disponibilité. La protection DDoS vient du fait de tourner sur le réseau edge de Cloudflare, qui filtre et absorbe le trafic d'attaque avant qu'il n'atteigne votre application. Voir notre guide de production sur le bot management Cloudflare pour ce versant.
