Use both. A Content Security Policy limits what the Tauri frontend can load and run. The isolation pattern sits between the frontend and the Rust core and lets you inspect every IPC message. They address different failures, so one does not replace the other.
Content Security Policy
The Tauri docs say CSP protection is only on when you set it in the Tauri configuration file. You provide directives such as default-src and connect-src. At compile time, Tauri adds nonces and hashes for bundled scripts and styles, so you only list what is unique to your app.
Advice from the docs and sensible practice:
- Make the policy as restrictive as you can.
- Avoid remote content such as scripts from a CDN.
- Add only hosts you trust, preferably your own.
- If you use WebAssembly, add the wasm unsafe eval source to script-src.
- Treat any
unsafe-inlineentry as something to justify. The docs' example includes one for styles without explaining it.
The isolation pattern
Isolation routes frontend IPC calls through a sandboxed iframe that runs a small isolation application. A hook there can inspect or change each message. The message is then encrypted with AES-GCM, with a key generated at runtime and renewed on every start, and passed on to the core.
The docs say its main target is development time threats: frontends pull in many nested dependencies that end up bundled. Because every message passes through the hook, you can reject file paths outside expected places or check that web requests carry the origin you expect. It also covers always on APIs such as events.
Costs and limits
- Encryption adds overhead, usually unnoticeable because messages are small.
- Key generation needs system entropy, which can matter in headless test environments.
- On Windows, external files do not load inside sandboxed iframes, so Tauri inlines scripts at build time.
- ES modules do not load in the isolation application.
The docs recommend keeping the isolation application small, with few dependencies, so it does not add its own supply chain risk.
How they fit together
Think of CSP as limiting what the page can pull in, and isolation as checking what the page can ask for. Capabilities and scopes then limit what the core will do. That makes three independent layers. See capabilities and scopes for the third.
Quick check
If my hook validates every message, do I still need scopes?
Yes. Keep validation in more than one place. Scopes are enforced by the commands, and a bug in your hook should not leave the core unprotected.
Sources
Last reviewed: 19 October 2026.