Security & trust
Two modes. Two different trust models.
DSGo Apps is not one blanket sandbox story. Iframe mode is the strongest isolation path for untrusted drop-ins. Inline mode gives you crawlable, indexable pages, but it should be treated like trusted code running inside your WordPress site.
The short version
Use iframe for untrusted code. Use inline when the app is part of the site.
Iframe mode
Runs inside <iframe sandbox="allow-scripts"> with an opaque origin. The app cannot touch the parent DOM, cookies, or local storage. Best for Claude artifacts, third-party bundles, and anything you did not personally audit.
"isolation": "iframe" Inline mode
Renders as a real WordPress page with CSP, sanitization, routing, and sitemap support. That gives you SEO and native URLs, but the bundle is same-origin code. Treat it like any other trusted plugin or theme code you install.
"isolation": "inline" What the bridge does
Permissions are real, but they are not the whole security story.
The bridge enforces manifest permissions and keeps REST/auth logic in one place. Apps never receive a REST token. That matters in both modes, but it matters most in iframe mode because the browser boundary is also enforcing separation.
What v1 guarantees
Decision rule
Choose the mode by the source of the code.
Unknown source
Downloaded artifact, generated bundle, outside contractor handoff, experimental prototype. Use iframe mode.
Known, reviewed code
Your team built it, reviewed it, and needs crawlable routes or root-mount behavior. Inline mode is appropriate.
Need both
Prototype in iframe first, then promote to inline once the app is stable and you want native SEO and site ownership.
See the exact contract in the docs.
The website summary is high-level. The manifest, bridge methods, and additive v1.x features live in the repo specs.