Emdash CMS Plugin Runtime and Security Model
Understand how EmDash separates trusted and sandboxed plugin execution, and why Dynamic Workers matters for security boundaries.
Why this model exists
Most CMS plugin ecosystems fail at the same boundary: extensions run with too much privilege.
EmDash addresses this by separating plugin execution modes and making capability boundaries explicit.
Two execution classes
Trusted plugins
- loaded as part of your application runtime
- suitable for code you own or fully trust
- operationally simple, but security depends on your review discipline
Sandboxed plugins
- executed in isolated worker environments
- designed for untrusted or semi-trusted extension logic
- constrained by explicit capabilities, runtime limits, and network rules
The security posture depends less on plugin intent and more on runtime isolation guarantees.
Dynamic Workers in the architecture
Dynamic Workers is the isolation primitive used for sandboxed execution on Cloudflare.
Without it, sandbox mode is unavailable, and you should operate only with trusted plugin assumptions.
In practical terms:
- Free plan: core CMS works, sandboxed plugin mode does not
- Paid plan with Dynamic Workers: sandbox model becomes available
Capability model: least privilege by default
A plugin should declare only what it needs:
- read content
- write specific content domains
- call outbound network endpoints
- trigger selected workflow hooks
If a capability is not granted, the operation should fail deterministically. This is a design requirement, not a best-effort courtesy.
// Example: keep capability scope explicit
export default definePlugin({
id: "notify-on-publish",
capabilities: ["read:content", "email:send"]
});Runtime guardrails that matter
Security and reliability both depend on hard limits:
- CPU and wall-time limits prevent runaway handlers
- memory ceilings constrain abuse and accidental leaks
- network policies block arbitrary exfiltration attempts
These controls convert plugin failures into bounded incidents instead of platform outages.
Threat model in one page
Assume any third-party plugin can contain:
- malicious behavior
- stale dependencies
- logic bugs under uncommon event timing
The plugin runtime should therefore guarantee:
- containment of blast radius
- denied-by-default privileged operations
- auditable execution outcomes
Trust should be earned by policy, not granted by installation.
Free plan operating model
If you are running without sandbox support:
- keep plugin set minimal
- prefer first-party or internally reviewed plugins
- perform dependency and permission review at release gates
- isolate risky integrations into external services where possible
This is a viable model for many teams, but it requires stronger governance discipline.
Decision criteria: when to require sandbox mode
Treat sandbox mode as mandatory when:
- you install plugins from external authors at scale
- compliance requires stronger isolation evidence
- business risk from plugin compromise is material
Treat sandbox mode as optional when:
- plugin surface is small and fully audited
- team controls release pipeline end to end
Practical governance checklist
Before enabling any plugin in production:
- document plugin owner and purpose
- review required capabilities and outbound endpoints
- set rollback owner and rollback procedure
- validate behavior in staging with failure injection
Plugin security is not a one-time architecture decision. It is an operational process backed by runtime boundaries.