Security
GJS Builder treats security as a first-class concern across saving, rendering, and the extension supply chain.
Output sanitization
Front-end HTML is sanitized with an extended kses allow-list. Iframe hosts are restricted to trusted video providers (YouTube, Vimeo). Only one inline <style> block is emitted per page.
Scripts are opt-in
Page scripts run only if both are true: a user with the unfiltered_html capability saved them, and the "allow page scripts" setting is enabled. By default, pages are script-free.
Capability gating
Every action maps to a real WordPress capability:
| Action | Capability |
|---|---|
| Edit a page | edit_post |
| Publish | publish_post |
| Manage media | upload_files |
| Manage extensions / settings | manage_options |
An optional allowed_roles gate can further restrict who may use the builder.
Request limits
The REST layer is nonce-protected, per-post capability checked, and caps request bodies (10 MB) to prevent abuse.
The extension supply chain
- The plugin talks only to GJS Market and its build service — never directly to npm or GitHub.
- Marketplace bundles are sha512-verified against the catalog checksum before they run.
- Manual uploads are capability-gated and, like WordPress's own Upload Plugin, trusted to the admin who uploads them.
- Marketplace endpoints are fixed in code, so a copied plugin can't be silently re-pointed.
Content Security Policy
For production, configure a CSP that allows your own origin and the trusted asset hosts your extensions use. A per-request nonce for any inline scripts is recommended over 'unsafe-inline'.