Security & Isolation
OpenGPEX enforces a layered security model to protect users from malicious or buggy plugins while preserving the flexibility of the plugin system.
Trust Levels (sourceType)
| Level | Meaning | Capabilities |
|---|---|---|
base |
Official core plugins | Full access, cannot be disabled |
community |
Verified third-party | Full access, user can disable |
user |
User-installed | Sandboxed, user can remove |
Cloud Mode Restrictions
When the editor runs in GPEX-Cloud SaaS mode:
- ❌ User plugins are completely disabled
- ❌ Dynamic plugin upload is blocked
- ✅ Only
baseandcommunityplugins are active - ✅ This prevents malicious code from accessing cloud credentials
Namespace Protection
- Each plugin operates within its own UID namespace
- Plugins cannot read or write another plugin's config
- Cross-plugin communication is only possible via:
- Command Bus (explicit, auditable)
- Public signals (read-only for consumers)
Error Boundaries
Each plugin component is wrapped in a React Error Boundary:
- If a plugin throws during render, only that plugin crashes
- The rest of the editor continues functioning normally
- A fallback UI shows the error with a "Disable Plugin" button
Metadata Sandboxing
Plugin metadata is validated on install:
| Check | Rule |
|---|---|
| ID format | Must match category.name pattern |
| Version | Must be valid semver |
| Engine compatibility | Must satisfy engine range |
| File size | Maximum 10 MB per ZIP |
| Entry point | Must be a valid ESM module |
Runtime Isolation
Plugins run in the same JavaScript context (no iframe/Worker isolation) but are constrained by:
- No direct DOM access outside their slot
- No direct store access (only via provided hooks)
- No filesystem or network access (browser sandboxed)
- Rate-limited command execution (prevent infinite loops)
Next Steps
- Plugin System Overview — Trust model architecture
- Plugin Packaging — Distribution requirements
- Cloud Integration — Cloud mode details
Last updated: 2026-06-14