Views render in a sandboxed iframe under a strict Content Security Policy: it blocks every cross-origin request the view hasn’t declared. Your server’s own origin is allowed automatically, so a view that only talks to its server needs no configuration. For anything else, list the origin on the tool’s config view.csp.
Each field maps to one kind of request the iframe would otherwise block. The sections below cover the four you’ll reach for, what’s allowed without any config, and how the policy differs per host.
The carousel checks live stock from api.myshop.com, so that origin is listed.
Your server’s origin is already in connectDomains, so same-origin requests need no entry. In development, the dev server’s WebSocket origin is added too, for hot reload.
resourceDomains covers the static assets the browser loads from another origin: images, fonts, scripts, and stylesheets, whether from a CDN, a fonts provider, or any other host.
frameDomains lists the origins the view may embed in a nested iframe, like a map or a video player. Third-party iframes opt your app into stricter review when you submit it to a directory.
To check your CSP, run your app in a real host through the tunnel, or let the Audit verify it before you submit.
DevTools runs a loose policy, so CSP violations don’t surface locally: a view that loads in the emulator can still have its requests blocked in production.