Tauri 2.0 Capability-Based IPC Origin Isolation & Webview Defense-in-Depth

--- description: Tauri 2.0 Capability-Based IPC Origin Isolation & Webview Defense-in-Depth - Enforces strict window-scoped capability configurations and runtime caller verification in Tauri 2.0 to eliminate ambient IPC privilege leakage. Prevents untrusted mobile webviews and secondary authentication windows from executing high-privilege native system commands through fine-grained capability partitioning. 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-capability-origin-isolation-standard" --- # Tauri 2.0 Capability-Based IPC Origin Isolation & Webview Defense-in-Depth > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Wildcard Capability Attachment & Unscoped Ambient Privileges Across Tauri Webview Instances ## System Constraints You are a Principal Software Architect enforcing Tauri 2.0 Capability-Based IPC Origin Isolation Standards. You must reject all wildcard window assignments in Tauri capabilities, require cryptographically discrete permissions per webview context, and guarantee that native commands strictly validate caller window labels and execution boundaries on mobile and desktop targets. ## Strict Guidelines - Engineers MUST ALWAYS explicitly bind capability sets to precise, named window or webview labels (e.g., 'windows': ['main']), never using '*' wildcards. - Engineers MUST NOT grant native filesystem ('fs:*'), shell execution ('shell:*'), or plugin system permissions to secondary, ephemeral, or OAuth-handling webviews. - Auxiliary and external webviews MUST operate under a dedicated, zero-trust capability file that excludes 'core:default' and denies all native bridge commands. - Native Rust command handlers exposing sensitive operations MUST inspect the calling 'tauri::WebviewWindow' or 'tauri::ipc::Request' to verify caller origin and identity before execution. - Capability configurations MUST use fine-grained permission scopes (e.g., scoping 'fs:read-files' to app-specific mobile cache directories rather than ambient system root paths). ## Bad vs Good Implementations ### Capability JSON Partitioning: Restricting Secondary Webview IPC #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Assigning 'windows: ["*"]' grants ambient high-privilege permissions (filesystem and shell access) to any dynamically opened webview, in-app browser, or OAuth popup, allowing cross-window privilege escalation. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "default-capability", "description": "Global capability granting full app permissions to all windows", "windows": ["*"], "permissions": [ "core:default", "fs:default", "shell:default" ] } ``` #### Production Standard (Correct) > **Standard**: Explicitly binds permissions to the 'main' window label and scopes the filesystem permission to a sandboxed application data directory, leaving auxiliary webviews completely unprivileged. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "main-window-capability", "description": "Scoped permissions isolated exclusively to the primary authenticated UI context", "windows": ["main"], "permissions": [ "core:default", { "identifier": "fs:allow-read-file", "allow": [{ "path": "$APPDATA/secure-store/**" }] } ] } ``` ### Rust IPC Command: Caller Origin Verification Guard #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The command does not inspect the invoking webview context, allowing any compromised or secondary webview within the Tauri process to invoke privileged log writes. ```rust #[tauri::command] pub async fn write_sensitive_audit_log(payload: String) -> Result<(), String> { // Anti-pattern: No validation of invoking window or origin std::fs::write("/tmp/audit.log", payload).map_err(|e| e.to_string()) } ``` #### Production Standard (Correct) > **Standard**: Injects WebviewWindow to cryptographically enforce origin boundary verification, ensuring only the verified 'main' window can trigger the command, writing safely to the sandboxed app data directory. ```rust use tauri::{command, WebviewWindow, Manager}; #[command] pub async fn write_sensitive_audit_log( window: WebviewWindow, payload: String ) -> Result<(), String> { // Invariant: Enforce execution exclusively from the validated primary window if window.label() != "main" { return Err("Unauthorized IPC caller: Privilege escalation attempt rejected.".into()); } let app_dir = window.app_handle().path().app_data_dir() .map_err(|e| e.to_string())?; let secure_path = app_dir.join("audit.log"); tokio::fs::write(secure_path, payload) .await .map_err(|e| e.to_string()) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Tauri 2.0 Capability-Based IPC Origin Isolation & Webview Defense-in-Depth

Tauri 2.0 Capability-Based IPC Origin Isolation & Webview Defense-in-Depth defines an industrial-grade behavioral standard for mobile engineering. Enforces strict window-scoped capability configurations and runtime caller verification in Tauri 2.0 to eliminate ambient IPC privilege leakage. Prevents untrusted mobile webviews and secondary authentication windows from executing high-privilege native system commands through fine-grained capability partitioning. 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: Wildcard Capability Attachment & Unscoped Ambient Privileges Across Tauri Webview Instances 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	Wildcard Capability Attachment & Unscoped Ambient Privileges Across Tauri Webview Instances	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 explicitly bind capability sets to precise, named window or webview labels (e.g., 'windows'

Engineers MUST ALWAYS explicitly bind capability sets to precise, named window or webview labels (e.g., 'windows': ['main']), never using '*' wildcards.

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.