Tauri Core

Tauri Core

Shared model for the tauri cluster. The config, IPC, and distribution spokes all depend on these interlocking concepts — keep them consistent here so no spoke contradicts another.

1. The security model (Tauri v2's defining feature)

Access is default-deny. You opt windows into capabilities, which bundle permissions, which may be narrowed by scopes:

Window/Webview ──has──> Capability ──includes──> Permission(s) ──constrained by──> Scope(s)

• Permission — a single allowed command/behavior (often shipped by a plugin, e.g. fs:read-files). Default + custom permissions live in src-tauri/permissions/ and plugin manifests. → configuring-tauri-permissions
• Capability — a JSON file in src-tauri/capabilities/ that grants a set of permissions to specific windows/webviews (by label) and platforms. This is how you wire permissions to surfaces. → configuring-tauri-capabilities
• Scope — allow/deny data that narrows a permission (e.g. which paths fs may touch, which URLs http may reach). Deny scopes win over allow. → configuring-tauri-scopes

Rule: grant the narrowest capability that works; prefer per-window capabilities over global; treat any scope widening (new path, new host) as a security change worth stating.

2. CSP & web boundary

The Content-Security-Policy in tauri.conf.json governs what the webview may load/execute. Keep it strict (no blanket unsafe-inline/*); add only the origins you need. Custom protocol/header needs → configuring-tauri-csp, configuring-tauri-http-headers.

3. IPC trust boundary & command contract

The frontend is untrusted; Rust is the trusted core. Everything crosses one boundary:

• Commands (JS → Rust): #[tauri::command] fns registered in the invoke_handler; called via invoke(). Validate every argument in Rust — never trust the webview. → calling-rust-from-tauri-frontend
• Events (Rust → JS and back): emit/listen for fire-and-forget streams. → calling-frontend-from-tauri-rust, listening-to-tauri-events
• A command is reachable from a window only if a capability grants the matching permission. → understanding-tauri-ipc

4. Process & runtime model

• Core process (Rust) owns the event loop, windows, plugins, and the privileged API; one per app. → understanding-tauri-process-model, understanding-tauri-runtime-authority
• Webview process(es) render UI, sandboxed, reach the core only via IPC.
• Sidecars are external binaries the core spawns under scope control. → embedding-tauri-sidecars, running-nodejs-sidecar-in-tauri
• Lifecycle/security posture → understanding-tauri-lifecycle-security, understanding-tauri-ecosystem-security.

5. Distribution matrix

Cross-cutting: signing-tauri-apps (identities), optimizing-tauri-binary-size, building-tauri-with-github-actions (CI matrix), using-crabnebula-cloud-with-tauri (managed).

6. Version / conventions

• Target Tauri v2 (tauri-v2); the capability/permission system above is v2-specific. Coming from v1 → migrating-tauri-apps. Keep core + plugin versions aligned → updating-tauri-dependencies.
• Frontend is framework-agnostic (any JS, or a Rust frontend) → integrating-tauri-js-frontends, integrating-tauri-rust-frontends.

7. Shared guardrails

• Default-deny: narrowest capability/permission/scope that works; per-window over global.
• Validate all command inputs in Rust; the webview is untrusted.
• Strict CSP; explicit allowlists only.
• State every security-surface change (new permission, scope path, host, capability).
• Confirm signing identity + platform prerequisites before a release build.
• Tauri vs Electron: pick Tauri for small binaries + a hardened Rust core + the capability model; if the team is all-JS with heavy Node-native needs, weigh the electron cluster.