Security & trust

Two modes. Two trust models.

DSGo Apps no es una historia de sandbox uniforme. El modo iframe es la ruta de aislamiento más sólida para elementos externos no confiables. El modo inline te da páginas rastreables e indexables, pero debe tratarse como código de confianza que se ejecuta dentro de tu sitio de WordPress.

Tres cosas que siempre son verdaderas

✓ Aislado por diseño. Cada app se ejecuta dentro de una sandbox de iframe o detrás de una CSP estricta por solicitud. Si la app falla, tu sitio sigue en línea. La sandbox no previene todo daño, pero contiene el radio de impacto.
✓ Solo lectura de forma predeterminada en la versión gratuita. El puente del nivel gratuito expone publicaciones, páginas y el usuario actual, todo de solo lectura. Los métodos de escritura y las llamadas de IA son características de Pro, y cada una debe declararse explícitamente en el manifiesto y aprobarse en la instalación.
✓ Tus claves de API nunca salen de tu sitio. Las llamadas de IA van a través del Connector de WordPress que tu administrador configuró. WordPress llama a tu proveedor a través de ese Connector, y DSGo nunca retiene, almacena, ve o cobra por tus claves. Si revocas el Connector, el acceso de IA de cada app se detiene instantáneamente.

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