Tauri security

Workflow

1. Inventory frontend origins, windows/webviews, commands, plugins, remote content, lifecycle transitions, and data crossing IPC.
2. Define capabilities per window or webview in

   src-tauri/capabilities/

   . Grant only required permission identifiers and review merged capabilities because permissions combine across matching windows.
3. Add scopes that constrain resources where supported; enforce validation in Rust as defense in depth. Review asset protocol scopes and prevent path traversal or unintended exposure.
4. Configure restrictive CSP and HTTP headers appropriate to the frontend. Avoid wildcard sources and do not weaken headers to fix unexplained failures.
5. Model lifecycle threats: startup, navigation, window creation, suspend/resume, update/relaunch, crash recovery, and shutdown can change authority or expose stale state.
6. Review runtime authority and the ecosystem: audit plugins, dependencies, release/update paths, signing, and provenance as part of the threat model.
7. Treat remote API access as a separate trust boundary. Do not enable remote content or remote API access without explicit origin allowlisting, capability minimization, authentication/authorization, transport security, input validation, and a documented threat model.
8. Test denied access, malformed input, scope escape attempts, navigation, remote content, headers/CSP, update artifacts, and production builds.

Rules

• Never ship private keys, tokens, or secrets in frontend code or updater artifacts.
• Use capabilities and permissions together; neither replaces validation.
• Treat third-party plugins as privileged Rust code and audit their permissions and source.
• Do not grant filesystem, process, shell, or remote authority merely to make a prototype work.