BoundariesDeveloper guide
Security And Permissions
What app code can access, which APIs require permissions, and where secrets should live.
Sandbox Model
| Boundary | Rule |
|---|---|
| Browser APIs | Apps cannot call chrome.* directly. All privileged work routes through airglow.*. |
| App identity | SDK messages include app id; the handler validates sender URL or userScript world id. |
| Storage | App data is namespaced by app id. Apps cannot list another app's storage keys. |
| Userscripts | Run in USER_SCRIPT world with DOM access and isolated JS globals. |
| UI/startup | Run in sandbox iframes with no direct extension API access. |
Permissioned Capabilities
| Capability | Permission source | Risk |
|---|---|---|
| Cookie fetch | host_permissions in manifest | Can act as the logged-in user on matching origins. |
| OAuth | Extension identity redirect URL | Must validate returned state and exchange codes server-side. |
| Iframe allow | airglow.platform.allowIframes | Relaxes framing protections for selected domains. |
| Redirects | airglow.platform.registerRedirects | Can change user navigation for matching domains. |
| RPC | App server endpoint | Can hit paid APIs or process sensitive payloads. |
Use server-side controls
If an RPC endpoint can spend money or process sensitive data, route it through server-side identity and rate limits. Do not put provider keys paid by Airglow in client settings.
Secret Placement
- Use
CLIENT_settings only for values that may be visible to the extension/browser runtime. - Provider keys paid by Airglow belong on the server, never in
CLIENT_values. - Browser OAuth codes should be exchanged in server RPC functions.
- Log redaction protects common sensitive keys, but app code should still avoid logging secret-bearing payloads.