--- title: "WordPress Security vs EmDash: How Sandboxing Changes Everything" description: "How EmDash's sandboxed plugin architecture eliminates the class of security vulnerabilities that plague WordPress. A deep dive into the security model." article_type: child canonical: https://dashstro.com/learn/emdash-security-model --- :::bluf 96% of WordPress security issues originate from plugins because PHP plugins get ambient access to your entire database, filesystem, and server. EmDash plugins run in sandboxed Worker isolates with capability manifests — a plugin can only access what it explicitly declares. Combined with passkey authentication (no password to steal) and no filesystem at all, entire attack classes become structurally impossible. ::: I built dashstro.com on EmDash specifically because I was tired of thinking about WordPress security. Not patching plugins. Not monitoring for vulnerabilities. Not wondering whether the SEO plugin I installed three years ago had been compromised. EmDash's architecture makes an entire class of security problems structurally impossible. Here's how. ## The WordPress plugin security model When you install a WordPress plugin, it runs as PHP on your server with the same permissions as WordPress itself. That means it has direct read and write access to your entire database. It can read every post, every user record, every password hash, every private setting. It can write to any table. It can execute arbitrary SQL queries. It can read and write files on your filesystem. It can make outbound HTTP requests. All of this is available by default, with no permission granted, because PHP has no capability model. This is ambient access. Every plugin gets everything. The only thing preventing a malicious or compromised plugin from stealing your data or defacing your site is the assumption that the plugin developer is trustworthy and the plugin hasn't been hijacked. That assumption fails regularly. ## The numbers are not good 96% of WordPress security vulnerabilities originate from plugins, not WordPress core. Security researchers find over 333 new WordPress plugin vulnerabilities per week on average. Of those, a substantial number — often over 200 per week — are disclosed without a patch available at time of disclosure. Site owners are left running software with known vulnerabilities while waiting for a developer to respond. The attack vectors are predictable: SQL injection through unparameterized queries, arbitrary file upload through poorly validated form handlers, cross-site scripting through unescaped output, and remote code execution through unvalidated PHP includes. These vulnerabilities are so common they have industrial-scale exploit markets built around them. ## EmDash's Worker isolate sandbox EmDash plugins run in Cloudflare Worker isolates — the same V8 isolate technology that powers Cloudflare's own edge network. Each plugin runs in its own isolated execution context. It cannot access memory from other plugins or from the host process. There is no shared global state to corrupt. More importantly, plugins use a capability manifest system. When you install an EmDash plugin, it declares what it can do. "I need to read content entries in the posts collection." "I need to send outbound HTTP requests to api.sendgrid.com." "I need to write to my own plugin storage." These declarations are explicit and enforced at runtime. A plugin that doesn't declare a capability cannot exercise it — not because there's a policy against it, but because the capability doesn't exist in the plugin's execution context. :::pullquote A malicious EmDash plugin literally cannot read data it wasn't granted access to. This isn't a policy — it's enforced by the runtime. ::: ## What no ambient access means in practice Consider a plugin that adds a custom contact form. In WordPress, that plugin has implicit access to your entire user database — emails, passwords, everything. In EmDash, that plugin has only what it declared: the ability to send an outbound email and write to its own isolated storage. It cannot read your user table. It cannot read other collections. It cannot access the filesystem. The capability manifest is a hard wall, not a best-practices guideline. Even if a plugin developer made a mistake, or if a plugin's npm dependencies contained malicious code, the damage is contained. An exploited EmDash plugin can do no more than its declared capabilities allow. In WordPress, an exploited plugin can compromise your entire database and all the sites on the same server. ## Passkey authentication EmDash's admin panel uses passkey authentication — no passwords. Passkeys are cryptographic credentials tied to your device and biometric authentication. There are no passwords to leak in a database breach. There are no passwords to guess in a brute force attack. There are no password reset flows to exploit through email interception. The entire credential theft attack surface is eliminated. WordPress's authentication model relies on password hashes in a database. Even with a strong hashing algorithm, a database dump exposes those hashes to offline cracking. The most common WordPress compromise vector is credential theft through a separate plugin vulnerability — steal the database, crack the hash, take the admin. That chain is broken with passkeys. ## Security model comparison | Plugin access model | Ambient — full DB + filesystem by default | Capability manifest — only declared access | | --- | --- | --- | | Authentication | Password hash in database | Passkey (device-bound, no password) | | Database access | Any plugin can run arbitrary SQL | Scoped by capability, no raw SQL access | | File system access | Full server filesystem readable/writable | No filesystem — Worker isolate has no FS | | Attack surface | 333+ new plugin vulns per week | Isolated by runtime, no ambient exposure | | Compromise blast radius | Full site + server + co-hosted sites | Contained to plugin's declared capabilities | ## Real-world implications For a site owner who isn't a security expert — which is most site owners — the EmDash model means you don't need to be. You don't need to audit the plugins you install. You don't need to monitor CVE feeds for WordPress plugin vulnerabilities. You don't need to apply emergency patches on a Friday night because a popular plugin was compromised. The runtime enforces the boundaries. The Cloudflare infrastructure underneath adds another layer. There's no server to compromise at the OS or network level. There's no server to take offline with a DDoS. Worker isolates are short-lived — they spin up for a request and terminate. There's no persistent process to inject into or long-running session to hijack. To be honest about EmDash v0.1: the plugin ecosystem is new and small. You're unlikely to run into a compromised plugin today because there are barely any plugins yet. The security model matters most when the ecosystem grows — when you're choosing from hundreds of plugins and can't personally audit every one. That's when the capability manifest sandbox becomes critically valuable rather than a theoretical benefit. The architecture is right. This is how plugin systems should have been designed from the start. EmDash built it correctly at v0.1, while WordPress is still trying to retrofit security onto a 20-year-old ambient access model. If you care about security and you're building something new, start with the right foundation. ## Frequently asked questions ::::faq :::q Are EmDash plugins really impossible to misuse? ::: :::a Not impossible — but structurally constrained. A plugin can still misuse its declared capabilities (leak data it's authorized to read). What it can't do is access anything beyond its manifest. Whole classes of attacks — SQL injection, arbitrary file reads, credential theft — become impossible rather than "best-practices discouraged." ::: :::q What happens if a plugin's own npm dependencies are compromised? ::: :::a The damage is contained to the plugin's declared capabilities. A supply chain attack in an EmDash plugin can do what the plugin could do — not what the host site could do. In WordPress, the same attack compromises your entire database and filesystem. ::: :::q Is passkey authentication really more secure than 2FA passwords? ::: :::a Yes, structurally. 2FA adds a factor on top of a password; passkeys eliminate the password entirely. No password means no credential theft, no phishing, no database-leak offline cracking. Passkeys are also bound to the specific domain they were created on, which defeats phishing at the protocol level. ::: :::q Is EmDash's security model useful if there aren't any plugins to run yet? ::: :::a It matters most when the ecosystem grows. At v0.1 you're unlikely to hit a compromised plugin because there aren't many plugins. The architecture becomes critically valuable when you're choosing from hundreds and can't audit each one — which is exactly the situation WordPress is in today. ::: :::: [Full EmDash vs WordPress comparison](/learn/emdash-vs-wordpress)