EmDash – le successeur spirituel de WordPress qui résout les problèmes de sécurité des plugins

• EmDash, développé par Cloudflare, est un CMS open source entièrement repensé en TypeScript et avec une architecture serverless afin de dépasser les limites structurelles de WordPress
• Chaque plugin s’exécute dans un environnement sandbox isolé, ce qui élimine à la source les vulnérabilités des plugins, à l’origine de 96 % des problèmes de sécurité des sites WordPress
• Le standard de paiement x402 est intégré nativement pour prendre en charge le paiement à la demande (pay-per-use) par contenu, et proposer une structure de monétisation adaptée à l’ère du trafic web piloté par l’IA
• Grâce à une architecture serverless basée sur Cloudflare Workers, le système monte et descend automatiquement en charge à la requête, conciliant réduction des coûts et hautes performances
• En intégrant des fonctions modernes comme la gestion des agents IA, l’authentification par Passkey et une structure de thèmes Astro, il s’agit d’un CMS qui reprend l’esprit de WordPress tout en le réinventant complètement

---

Présentation d’EmDash

• EmDash est un CMS open source conçu pour résoudre les limites structurelles de WordPress, avec une base entièrement en TypeScript et une architecture serverless
  • Compatible avec les fonctions essentielles de WordPress, mais sans réutiliser son code existant, ce qui permet une distribution sous licence MIT
  • Utilise les Dynamic Worker de Cloudflare Workers pour exécuter chaque plugin dans un environnement isolé (isolate) indépendant
  • Repose sur le framework Astro afin d’offrir des performances optimisées pour les sites centrés sur le contenu
• EmDash est publié sur GitHub et peut être déployé directement sur un compte Cloudflare ou sur un serveur Node.js
• Il améliore en profondeur des problèmes que WordPress n’a pas su résoudre, comme la sécurité des plugins, la réduction de la dépendance au marché, la gestion assistée par IA et la prise en charge des paiements x402

Réussites et limites de WordPress

• WordPress propulse plus de 40 % d’Internet et constitue l’un des grands succès de l’open source ayant contribué à la démocratisation de la publication
• Mais 24 ans plus tard, les environnements d’hébergement et les paradigmes de développement ont profondément changé
  • À ses débuts, il fallait louer un VPS, alors qu’aujourd’hui il est possible de déployer en ne téléversant qu’un bundle JavaScript sur un réseau distribué mondial
• EmDash reprend l’esprit de WordPress, mais le recompose pour répondre aux infrastructures web modernes et aux exigences de sécurité actuelles

Résolution des problèmes de sécurité des plugins WordPress

• 96 % des problèmes de sécurité des sites WordPress proviennent des plugins
  • Les plugins, sous forme de scripts PHP, accèdent directement à la base de données et au système de fichiers
  • Lors de l’installation, ils obtiennent presque tous les droits, sans isolation ni restriction de privilèges
• EmDash exécute chaque plugin dans un environnement sandbox basé sur Dynamic Worker
  • Les plugins ne demandent que les capabilities nécessaires via une déclaration explicite (manifest)
  • Exemple : read:content, email:send, etc., avec seulement les permissions requises
  • L’accès réseau est lui aussi limité aux hôtes explicitement déclarés
• Avant l’installation, il est possible de voir clairement quelles permissions un plugin demande, ce qui offre une structure d’autorisation transparente proche d’OAuth
• Les administrateurs peuvent aussi automatiser leurs politiques d’installation selon les permissions demandées

Sécurité des plugins et fin de la dépendance à une marketplace

• En raison des problèmes de sécurité des plugins, WordPress.org applique une procédure de validation manuelle, avec une file d’attente de plus de 800 éléments
  • Les contraintes de la licence GPL limitent la réutilisation du code et la commercialisation
• EmDash supprime le lock-in du marché grâce à deux améliorations structurelles
  1. Assouplissement des licences de plugins : comme il n’y a pas de partage de code avec EmDash, les développeurs peuvent choisir la licence qu’ils souhaitent
  2. Exécution sécurisée en sandbox : le site peut faire confiance au plugin sans avoir besoin de voir directement son code
• Comme les plugins n’exécutent que les capabilities déclarées, il devient possible d’évaluer finement le risque de sécurité
• Cette architecture réduit ainsi la dépendance à une marketplace centralisée
  • Avec un modèle de sécurité fiable, développeurs et utilisateurs peuvent faire évoluer librement l’écosystème

Standard de paiement x402 intégré — monétisation de l’accès au contenu

• EmDash prend en charge nativement le standard x402, rendant possible un paiement à la demande via la réponse HTTP 402 Payment Required
  • Les utilisateurs peuvent payer contenu par contenu (pay-per-use) sans abonnement
  • Les exploitants de sites peuvent monétiser en ne configurant qu’une adresse de portefeuille et un prix
• Cela ouvre un nouveau modèle économique adapté à l’ère du trafic web porté par les agents IA
• Tous les sites EmDash disposent ainsi d’une structure de revenus intégrée pensée pour l’ère de l’IA

Scalabilité serverless et réduction des coûts

• WordPress nécessite du provisionnement serveur, ce qui entraîne des coûts de ressources inutilisées
• EmDash exploite une architecture d’isolation v8 fondée sur Cloudflare workerd
  • Une instance est créée immédiatement à la requête et, en l’absence de trafic, passe automatiquement en scale-to-zero
  • La facturation porte uniquement sur le temps CPU utilisé
• Via Cloudflare for Platforms, il est possible d’étendre automatiquement à plusieurs millions d’instances
• Cette architecture à faible coût et hautes performances est avantageuse pour gérer de gros volumes de trafic et proposer une offre gratuite

Une structure de thèmes moderne basée sur Astro

• Les thèmes EmDash sont structurés comme des projets Astro et comprennent les éléments suivants
  • Pages : routes de rendu du contenu
  • Layouts : structure HTML commune
  • Components : éléments d’interface réutilisables
  • Styles : configuration CSS ou Tailwind
  • Fichiers seed : définition des types de contenu générés par le CMS
• Astro est un framework populaire présent dans les données d’entraînement des LLM, ce qui le rend accueillant pour les développeurs
• Contrairement à la structure des thèmes WordPress fondée sur functions.php, les thèmes EmDash n’ont pas accès à la base de données, ce qui renforce la sécurité

Un CMS nativement pensé pour l’IA — MCP, CLI, Agent Skills

• EmDash a été conçu comme un CMS que des agents IA peuvent administrer directement
  • Il permet d’automatiser des tâches répétitives comme les migrations de contenu ou les transformations de champs

• Agent Skills

  • Les instances EmDash intègrent des Agent Skills qui fournissent à l’IA des informations sur la structure des plugins, les hooks ou les méthodes de portage des thèmes
  • L’IA peut comprendre la codebase d’EmDash et réaliser une personnalisation automatique

• EmDash CLI

  • La CLI permet d’effectuer des tâches d’administration comme la recherche de contenu, l’envoi de médias ou la génération de schémas
  • Elle peut piloter aussi bien des instances locales que distantes

• Serveur MCP intégré

  • Chaque instance fournit son propre serveur Model Context Protocol
  • Il permet d’exécuter à distance toutes les actions possibles depuis l’interface d’administration

Authentification par passkey et gestion des rôles

• EmDash utilise par défaut l’authentification par Passkey
  • Cela protège contre les fuites de mots de passe et les attaques par force brute
• Le système prend en charge nativement le contrôle d’accès basé sur les rôles (RBAC)
  • Il distingue les permissions selon les rôles : administrateur, éditeur, auteur, contributeur, etc.
• L’authentification peut être étendue sous forme de plugin, avec prise en charge du SSO et de l’intégration de métadonnées IdP

Migration de sites WordPress

• Les sites WordPress existants peuvent être migrés via l’export d’un fichier WXR ou le plugin EmDash Exporter
  • Le plugin Exporter crée un endpoint dédié protégé par WordPress Application Password
  • Le contenu et les médias sont automatiquement transférés vers la bibliothèque EmDash
• EmDash prend en charge une structure de contenu fondée sur des schémas
  • Les Custom Post Type de WordPress sont convertis en collections indépendantes dans EmDash
• Le Block Kit Agent Skill permet de générer des blocs personnalisés avec l’IA

Essayer et contribuer

• EmDash est actuellement disponible en version preview v0.1.0, téléchargeable depuis le dépôt GitHub
• Il est possible d’essayer directement l’interface d’administration sur EmDash Playground
• Commande d’installation locale : npm create emdash@latest
• Le déploiement est également possible depuis le tableau de bord Cloudflare
• Les retours et contributions de la communauté WordPress, des plateformes d’hébergement et des développeurs de plugins et thèmes sont les bienvenus

[xguru]

Je fais partie de ceux qui utilisaient WordPress pour leur blog personnel, puis l’ont abandonné à cause de ce problème de sécurité pour passer à du statique.
J’avais laissé mon blog personnel de côté pendant un moment, et des spams vraiment bizarres s’y sont infiltrés pour en faire un véritable champ de spam. Ils utilisaient une méthode étrange consistant à exploiter les tags pour faire indexer sur Google des pages qui n’existaient pas en local. J’en bave encore pour tout supprimer, ouin.

[lunamoth]

Je me souviens aussi avoir trouvé des URL bizarres dans les outils pour webmasters, et ça m'avait intrigué.

« Une étrange méthode qui consiste à enregistrer sur Google des pages qui n'existent pas en local en utilisant des balises » : de quelle méthode s'agit-il exactement ??

Y a-t-il un moyen de bloquer ça ?

[nemorize]

Il y a aussi du spam qui consiste à enregistrer comme backlink, dans les articles d’autres blogs, des URL de résultats de recherche contenant des formulations spammeuses ;
De toute façon, quoi qu’il en soit, il faut finir par les supprimer manuellement...

[xguru]

En général, l’intrusion passe par l’exploitation d’un plugin/thème présentant une faille liée à l’upload de fichiers.
Une fois entrés, ils injectent du contenu dans les tags/catégories, etc., à l’insu du propriétaire initial du blog.
En pratique, cela n’apparaît absolument pas sur les pages du blog, donc on ne s’en rend pas compte, mais ils utilisent une méthode qui fait en sorte que cette URL ne soit rendue visible que pour le bot de Google. ( C’est le cas de BabaYaga, par exemple. )

Une fois l’intrusion réalisée, en réalité, je n’ai pas trouvé d’autre solution que de faire en sorte que tout le trafic arrivant sur ces adresses renvoie vers une 410 Gone. Côté serveur, je configure toutes les adresses inutiles pour qu’elles renvoient 410, puis je dois demander manuellement dans la Search Console, pendant six mois, la suppression de certains formats d’URL. Par exemple, il faut supprimer tout ce qui commence par /tag.

Cela fait un mois que je demande la suppression, et tout n’a toujours pas disparu. Il faut que l’indexation Google fonctionne correctement, mais cela prend du temps.

[lunamoth]

Ah, d'accord. Merci de me l'avoir signalé. Il va falloir y faire attention à plusieurs niveaux.

[GN⁺]

Avis sur Hacker News

• Je travaille avec WordPress depuis plus de 10 ans, et je pense que ce projet a parfaitement résolu deux points : TypeScript et les plugins Worker
  Je réfléchis beaucoup ces derniers temps aux problèmes de sécurité de WP : un plugin malveillant peut accéder à la base de données ou aux variables d’environnement, voire provoquer du XSS. Mais un système de plugins bien conçu peut atténuer cela
  Je développe personnellement HotsauceCMS. Il permet d’utiliser au choix des plugins Worker NodeJS ou Deno : les plugins first-party peuvent s’exécuter rapidement in-process, tandis que les plugins tiers peuvent être isolés dans des workers
  Il n’y a que 4 dépendances et 0 dépendance transitive, car j’en avais assez des alertes Dependabot et des attaques sur la supply chain npm
  Avec une architecture schema-first basée sur Drizzle, on contrôle entièrement la structure de la BD et on définit des fonctionnalités comme l’upload de fichiers via des indications dans le schéma
  C’est indépendant de la base de données, donc ça fonctionne avec Postgres, MySQL, SQLite et toute BD prise en charge par Drizzle
  Le frontend est au choix, et personnellement je préfère JSX sans React
  Les retours sont les bienvenus. Je me demande si j’ai raté quelque chose et si la direction est la bonne. J’attends aussi avec intérêt l’évolution d’EmDash

  • Je serais curieux que tu expliques pourquoi TypeScript te semble si important
  • J’ai beaucoup utilisé WordPress autrefois, et à l’époque ce qui m’attirait, c’était la simplicité d’installation : on envoyait ça directement en FTP et ça tournait. Pas besoin de CLI ni d’outil de build. Mais la sécurité a toujours été un problème, et les piratages étaient constants
  • Je partage un lien vers une discussion précédente

• On présente EmDash comme le successeur spirituel de WordPress, mais je pense que la direction à prendre pour les CMS est exactement l’inverse
  Il faudrait plutôt simplifier et revenir à des sites web basés sur des fichiers statiques. C’est plus facile à mettre en cache, plus rapide et plus simple à gérer
  Bien sûr, du point de vue de Cloudflare, ils ont probablement choisi cette architecture pour vendre leur propre produit Workers. Je ne suis pas encore convaincu que cela règle vraiment le problème de fond de la sécurité

  • J’aime aussi les sites statiques, mais les clients veulent souvent du contenu dynamique. Au départ ils disent vouloir un site simple, puis plus tard ils demandent des formulaires, de la gestion de stock ou des réservations. Donc je comprends l’approche centrée sur les plugins
  • Les clients non développeurs aiment pouvoir modifier les choses eux-mêmes via une UI. WordPress a une UI trop complexe et trop lourde, donc dans la plupart des cas ils finissent par redemander à un développeur. L’idéal serait une UI minimale qui ne permette de modifier que l’essentiel
  • Si tu utilises Astro, c’est fondamentalement un générateur de site statique. Tu peux ajouter des composants React si nécessaire, et les plugins peuvent aussi être optionnels
  • Si tu veux héberger des fichiers statiques dans un endroit facile à mettre en cache, Cloudflare propose déjà ce service
  • Astro produit du HTML statique, donc de ce point de vue il ne semble pas y avoir de problème

• Je pense que Cloudflare aborde le sujet par le mauvais angle
  Si WordPress a réussi, c’est grâce à sa facilité d’installation et à son effet de réseau. Plus que la sécurité, c’est surtout qu’il existe déjà énormément de développeurs familiers de WP
  Pour réussir, EmDash doit être plus simple, plus rapide et plus flexible que Wix ou Squarespace. Sinon, il sera difficile de créer un effet de réseau

  • Il existe déjà beaucoup de professionnels expérimentés sur WordPress, alors qu’EmDash ne fait que commencer. Cela dit, s’il grandit, je serai content de l’encourager

• En tant que développeur WordPress, ma plus grande souffrance a toujours été l’architecture des plugins.
  Dans WP, les plugins vont dans un dossier wp-content au même titre que les images, ce qui transforme le CI/CD en cauchemar. Avec EmDash, les plugins sont des modules TS, c’est bien plus propre

  • WP n’a pas de notion de staging, donc pour déplacer des changements vers la production, il faut tout refaire manuellement

• Le concept du standard de paiement x402 de Cloudflare est intéressant
  L’idée est que des agents envoient automatiquement de micro-paiements pour obtenir l’accès à du contenu ; c’est un peu inquiétant, mais tourné vers l’avenir
  En plaisantant, si on créait un pot de miel HTTP 402 qui demande 10 centimes à chaque visite, ce serait peut-être la renaissance de l’ancienne idée du « 1 pixel à 1 dollar »

  • Si on trompe un agent pour qu’il continue à payer, on pourrait aussi gagner de l’argent avec des redirections infinies ou du contenu poubelle
  • Voir la documentation HTTP 402
  • Ça donne l’impression que le piratage par micro-détournement du film Office Space a été légalisé

• La valeur de WordPress n’est pas dans son code, mais dans son écosystème et son système de support
  La qualité du code laisse à désirer, mais tous les SaaS proposent un connecteur WP.
  Pour réussir, EmDash devra permettre même aux non-développeurs de faire personnaliser facilement leur site sur Fiverr. Ce n’est pas un problème technique, c’est un problème de marché du travail

  • Cloudflare ne fait pas de blagues du 1er avril. 1.1.1.1 a aussi été lancé un 1er avril et c’est maintenant un service DNS majeur
  • J’ai vérifié, c’est un vrai projet
  • On peut aussi se référer à la controverse .com vs .org autour de l’« open source » de WordPress
  • Il existe aussi une ancienne alternative : Textpattern

• Le fait que ce soit un successeur de WordPress créé par Cloudflare est séduisant, mais l’isolation des plugins basée sur Dynamic Workers ne fonctionne que sur le runtime Cloudflare
  Sur d’autres hébergeurs, ce n’est qu’un CMS en TS, donc la dépendance architecturale pose problème

  • Au final, le fait que ce soit un OSS dépendant de l’infrastructure Cloudflare complique son adoption
  • Cela dit, Workerd est open source, donc l’auto-hébergement reste possible
  • D’autres runtimes pourraient aussi reproduire cette fonctionnalité
  • Cloudflare semble suivre une stratégie qui consiste à transformer des OSS populaires en alternatives réservées à sa propre infrastructure

• Je me demande toujours pourquoi on continue à faire des projets IA en JavaScript
  Aujourd’hui, on peut aussi créer rapidement des applis avec un langage compilé comme Go. C’est plus petit, plus rapide et plus simple à déployer
  JS est interprété, donc lent et complexe. Avant, l’exécution immédiate était un avantage, mais aujourd’hui la compilation est aussi rapide

  • Dire que « JS n’est pas un vrai langage » est exagéré. Il y a encore beaucoup de bonnes raisons d’utiliser des langages interprétés
  • JS est le seul à pouvoir couvrir à la fois le frontend web, le backend, le mobile et le desktop. Avec des outils comme tRPC, on peut aussi obtenir une sûreté de typage de bout en bout
  • La plupart des développeurs connaissent JS/TS, et la communauté est la plus grande. L’écosystème est gigantesque, donc il n’y a pas vraiment de raison de changer
  • Go est peu pratique pour le traitement JSON ou le travail sur les templates. Son système de types est moins flexible, donc il y a beaucoup plus de contraintes côté frontend
  • Les LLM utilisent bien TS, et TS a corrigé beaucoup de défauts de JS. Entre des runtimes rapides et un déploiement simple, cela reste très attractif

• Il est intéressant qu’EmDash soit distribué sous licence MIT parce qu’il n’utilise pas le code de WordPress
  Mais cela fait penser à Malus, récemment apparu comme Cleanroom as a Service. Le timing est curieusement proche

  • Malus est en fait un projet satirique