The headline is simple: EmDash sandboxes every plugin in a V8 isolate, and the admin panel uses passkey authentication. That much you already know. But the architecture makes several promises it can\u2019t fully keep, and the gaps are where real-world security lives.<\/p>\n
Let\u2019s start with the sandbox. Cloudflare\u2019s dynamic workers run plugin code inside an isolated V8 isolate. The plugin declares its capabilities in a manifest \u2014 read content, send email \u2014 and literally cannot do anything else. No file system access, no database queries, no unrestricted network calls. That\u2019s a structural improvement over WordPress, where every plugin runs in the same process and has full access to But here\u2019s the non-obvious part: the sandbox only applies when the plugin runs on Cloudflare\u2019s paid Workers plan. Self-host EmDash on a Node.js server, and plugins execute in-process \u2014 no isolation at all. The free Cloudflare tier also runs plugins in-process. The feature that defines EmDash\u2019s security model is a paid, vendor-specific add-on. If you deploy on a standard VPS, you get the same risk surface as WordPress, minus the ecosystem.<\/p>\n And even on the paid plan, the sandbox is not a cure-all. A plugin that declares EmDash ships with passkey-first authentication using WebAuthn. No passwords to leak, no brute-force vectors. That\u2019s excellent. But the implementation has a catch that matters for anyone running multiple sites or staging environments.<\/p>\n Passkeys are bound to the origin \u2014 the exact domain and port. On a local development server ( Worse, the passkey is stored in the browser\u2019s credential manager. If you clear browser data or switch machines, you lose access and must use the magic-link fallback. The magic link, in turn, depends on email delivery \u2014 which itself relies on a configured SMTP server. On a fresh playground instance with no email setup, the fallback fails. A user locked out of their admin has no recovery path.<\/p>\n The most subtle security concern isn\u2019t technical \u2014 it\u2019s operational. EmDash\u2019s full security model requires Cloudflare\u2019s proprietary runtime. If you decide to move to another provider, you lose the sandbox. The data is portable (D1 is SQLite, R2 is S3\u2011compatible), but the security architecture is not. That means your migration path is either to accept a downgrade in security or to rebuild.<\/p>\n Compare with WordPress: you can move from a shared host to a VPS to a managed platform, and the security model stays the same \u2014 for better or worse. With EmDash, your security posture is tied to Cloudflare\u2019s infrastructure decisions. If they change pricing, deprecate dynamic workers, or suffer a platform\u2011level breach, you have no equivalent alternative.<\/p>\n Let\u2019s be specific. A plugin that declares wpdb<\/code>code.<\/p>\nread content<\/code>code and send email<\/code>code can still be buggy or malicious within those bounds. It can send spam, exfiltrate content via email (if you grant that capability), or loop indefinitely. The sandbox prevents direct database theft, but it doesn\u2019t prevent abuse of the granted capabilities. The plugin\u2019s behavior is still opaque \u2014 you trust the manifest, not the code.<\/p>\nUser Authentication: Passkeys and the Hidden Dependency<\/h2>\n
localhost:4321<\/code>code), a passkey works fine. But if you spin up a staging site on a different subdomain, or if you run multiple EmDash instances on the same machine, each one requires a separate passkey registration. There\u2019s no shared credential store across instances. For an agency managing 50 client sites, that means 50 separate passkey enrollments. The UX is worse than a password manager that auto\u2011fills.<\/p>\nThe Real Threat: Vendor Lock\u2011In as a Security Risk<\/h2>\n
What the Sandbox Can\u2019t Prevent<\/h2>\n
read content<\/code>code can still read all your posts. If that plugin has a vulnerability in its own logic \u2014 a reflected XSS in the admin interface, for instance \u2014 the sandbox doesn\u2019t protect against that. The plugin\u2019s own code runs inside the isolate, but the output it produces (e.g., rendered content) can still be malicious. The sandbox controls what the plugin can do<\/em>, not what it outputs<\/em>.<\/p>\n