Tauri 2.0 Multi-Webview IPC Sandboxing and Origin-Bound Capability Isolation

--- description: Tauri 2.0 Multi-Webview IPC Sandboxing and Origin-Bound Capability Isolation - Enforces least-privilege IPC access control across Tauri 2.0 desktop and mobile architectures by isolating multi-webview windows with origin-bound capability sets. Disallows universal access wildcards and default platform permissions for auxiliary webviews, enforcing explicit permission manifests and IPC payload validation for both local and mobile-target webview contexts. globs: src-tauri/capabilities/**/*.json, src-tauri/tauri.conf.json, src-tauri/src/**/*.rs, src/**/*.{ts,tsx} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/tauri-v2-ipc-origin-capability-sandboxing" --- # Tauri 2.0 Multi-Webview IPC Sandboxing and Origin-Bound Capability Isolation > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Assigning global capability scopes or wildcard window bindings to untrusted or secondary webviews, permitting arbitrary native plugin execution. ## System Constraints You are a Principal Security Architect enforcing Tauri 2.0 IPC sandboxing and Access Control List (ACL) capabilities. Mandate that multi-webview windows (desktop and mobile webview overlays) are strictly partitioned using discrete capability manifests. Auxiliary, OAuth, or remote webviews must never receive core platform plugin access (e.g., fs, shell, process). Every IPC command exposed to the webview must enforce origin check assertions, input validation via Serde, and scoped capability definitions. ## Strict Guidelines - Engineers MUST ALWAYS split capability declarations into dedicated JSON/TOML files under `src-tauri/capabilities/` targeting specific webview labels instead of wildcard `"windows": ["*"]`. - Engineers MUST NOT grant `core:default`, `fs:default`, or `shell:default` permissions to auxiliary, secondary, or remote-loaded webview windows. - Code SHOULD validate origin boundaries at the IPC command layer using Tauri's `ipc::Request` and `AppHandle::get_webview_window` before executing state mutations. - Services MUST declare granular scope rules (e.g., `path: [{ "allow": "$APPDATA/cache/**" }]`) for file and platform access rather than granting unbounded plugin-level access. - Components NEVER invoke raw, unsanitized Tauri IPC strings without client-side schema validation via libraries like Zod and explicit typing from `@tauri-apps/api/core`. ## Bad vs Good Implementations ### Tauri 2.0 Capability Manifest for Auxiliary Webview #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Using wildcard '*' for window bindings grants high-privilege native capabilities (fs, shell) to all webviews, including OAuth popups, embedded external content, and secondary mobile webviews. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "global-capability", "description": "Shared capabilities across all windows", "windows": ["*"], "permissions": [ "core:default", "fs:default", "shell:default" ] } ``` #### Production Standard (Correct) > **Standard**: Explicitly targets only designated webview labels ('auth-popup', 'mobile-modal') and provides minimal required permissions with tightly scoped URL access rules. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "auxiliary-webview-capability", "description": "Sandboxed capability set for secondary webviews", "windows": ["auth-popup", "mobile-modal"], "permissions": [ "core:event:allow-listen", "core:event:allow-emit", { "identifier": "http:default", "allow": [{ "url": "https://auth.company.internal/api/**" }] } ] } ``` ### Rust IPC Command with Webview Origin and Window Label Assertion #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Lacks origin validation, webview caller inspection, and relies on unbounded std::fs rather than Tauri's scoped file access or explicit window validation. ```rust #[tauri::command] pub async fn read_secure_vault(file_path: String) -> Result<String, String> { // Anti-pattern: No validation of which webview called this command std::fs::read_to_string(file_path).map_err(|e| e.to_string()) } ``` #### Production Standard (Correct) > **Standard**: Validates the calling WebviewWindow label, confines reads to the validated application data directory, and prevents path traversal. ```rust #[tauri::command] pub async fn read_secure_vault( app: tauri::AppHandle, window: tauri::WebviewWindow, file_path: String ) -> Result<String, String> { // Enforce origin verification: only main window can read the secure vault if window.label() != "main" { return Err("Unauthorized: IPC command restricted to primary window".into()); } // Validate canonical path containment within safe sandboxed app dir let app_dir = app.path().app_data_dir().map_err(|e| e.to_string())?; let target = app_dir.join(&file_path).canonicalize().map_err(|e| e.to_string())?; if !target.starts_with(&app_dir) { return Err("Path traversal detected".into()); } tokio::fs::read_to_string(target).await.map_err(|e| e.to_string()) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Tauri 2.0 Multi-Webview IPC Sandboxing and Origin-Bound Capability Isolation

Tauri 2.0 Multi-Webview IPC Sandboxing and Origin-Bound Capability Isolation defines an industrial-grade behavioral standard for mobile engineering. Enforces least-privilege IPC access control across Tauri 2.0 desktop and mobile architectures by isolating multi-webview windows with origin-bound capability sets. Disallows universal access wildcards and default platform permissions for auxiliary webviews, enforcing explicit permission manifests and IPC payload validation for both local and mobile-target webview contexts. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Assigning global capability scopes or wildcard window bindings to untrusted or secondary webviews, permitting arbitrary native plugin execution. Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Assigning global capability scopes or wildcard window bindings to untrusted or secondary webviews, permitting arbitrary native plugin execution.	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS split capability declarations into dedicated JSON/TOML files under `src-tauri/capabilities/` targeting specific webview labels instead of wildcard `"windows"

Engineers MUST ALWAYS split capability declarations into dedicated JSON/TOML files under `src-tauri/capabilities/` targeting specific webview labels instead of wildcard `"windows": ["*"]`.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.