Security & trust

Two modes. Two trust models.

DSGo Apps ist keine einheitliche Sandbox-Geschichte. Der Iframe-Modus bietet die stärkste Isolation für nicht vertrauenswürdige Drop-ins. Der Inline-Modus liefert crawlbare, indexierbare Seiten, sollte aber wie vertrauenswürdiger Code behandelt werden, der in deiner WordPress-Website läuft.

Drei Dinge, die immer wahr sind

✓ Von Grund auf isoliert Jede App läuft in einer iframe-Sandbox oder hinter strikter CSP pro Anfrage. Wenn die App abstürzt, bleibt Ihre Website online. Die Sandbox verhindert nicht allen Schaden, aber sie begrenzt den Schadensumfang.
✓ Standardmäßig schreibgeschützt (kostenlos) Die kostenlose Bridge zeigt Beiträge, Seiten und den aktuellen Benutzer an, alle schreibgeschützt. Schreibvorgänge und KI-Aufrufe sind Pro-Funktionen und müssen explizit im Manifest deklariert und bei der Installation genehmigt werden.
✓ Ihre API-Schlüssel verlassen Ihre Website nie KI-Aufrufe erfolgen über den WordPress-Connector, den Ihr Administrator konfiguriert hat. WordPress ruft Ihren Anbieter über diesen Connector auf, und DSGo hält, speichert, sieht oder berechnet Ihre Schlüssel niemals. Wenn Sie den Connector widerrufen, stoppt der KI-Zugriff aller Apps sofort.

If you run a site

In plain English

Two settings. Iframe mode puts an app in a box your other site code cannot reach into; use it for things you did not write yourself, like a Claude or ChatGPT page. Inline mode lets the app behave like a real page on your site (better for Google); use it when the code is something you or your team built and reviewed. The plugin's default for an uploaded HTML file is iframe, which is the safe choice. See real examples →

The short version

Use iframe for untrusted code. Use inline when the app is part of the site.

Strong isolation

Iframe mode

Runs inside an iframe sandbox without allow-same-origin, so the app cannot touch the parent DOM, real cookies, or origin storage. Best for Claude artifacts, third-party bundles, and anything you did not personally audit.

"isolation": "iframe"

Trusted-code mode

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 not the whole 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

✓ Declared bridge permissions are enforced. Methods reject when the manifest did not request the needed capability.
✓ Apps never get a REST token. The host makes the WordPress REST call on the app's behalf.
✓ Iframe apps get a browser sandbox boundary. That is the right mode for untrusted bundles.
✓ Inline apps get CSP + sanitization, not a browser sandbox. That improves safety, but it is still trusted same-origin code.

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.

Install free plugin Read docs See pricing How it works