Tauri 2.0 Scoped Capability Multi-Webview IPC Sandboxing Standard

--- description: Tauri 2.0 Scoped Capability Multi-Webview IPC Sandboxing Standard - Enforces deterministic, window-specific capability isolation across Tauri 2.0 multi-webview architectures to eliminate cross-webview privilege escalation and unauthorized native plugin execution. Prevents shared IPC bridge exposure by requiring fine-grained capability definitions scoped strictly to verified webview and window labels. Guarantees that untrusted or secondary webviews cannot invoke privileged core APIs or native mobile plugins. globs: src-tauri/capabilities/**/*.json, src-tauri/tauri.conf.json, src-tauri/src/**/*.rs, src/**/*.ts, src/**/*.tsx alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/tauri-2-scoped-capability-webview-sandboxing" --- # Tauri 2.0 Scoped Capability Multi-Webview IPC Sandboxing Standard > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Wildcard Window Scoping and Monolithic Capability Binding Across Heterogeneous Webviews ## System Constraints You are a Principal Security Architect enforcing the Tauri 2.0 Scoped Capability Multi-Webview IPC Sandboxing Standard. Mandate strict window and webview label isolation across all Tauri capability manifests and IPC endpoints. Reject any configuration assigning global wildcard permissions or exposing high-privilege native mobile plugins (e.g., filesystem, biometrics, secure storage) to secondary or untrusted webviews. Verify that all IPC invocations validate caller identity and ensure capability scopes strictly delineate permissions per window boundary. ## Strict Guidelines - Engineers MUST ALWAYS isolate permissions across distinct JSON capability files in `src-tauri/capabilities/`, mapping specific window labels explicitly in the `windows` property. - Engineers MUST NOT use wildcard syntax (`*`) in the `windows` array of capability files containing sensitive native plugins (e.g., `fs`, `sql`, `biometric`, `http`). - Engineers MUST explicitly restrict webview execution context by assigning unique `window` and `webview` labels upon creation in multi-webview mobile layouts. - Code SHOULD enforce runtime label verification via `tauri::ipc::Request` or `tauri::WebviewWindow` checks in custom Rust commands handling privileged state transformations. - Services MUST NEVER invoke un-namespaced or unrestricted invoke commands (`core:default` or global wildcard permissions) from untrusted child or authentication webviews. - Components NEVER expose global window Tauri internals (`window.__TAURI_INTERNALS__`) into webviews rendering external or remote URLs. ## Bad vs Good Implementations ### Tauri 2.0 Capability Manifest Scoping #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Using wildcard 'windows': ['*'] grants every webview, including secondary, iframe-bearing, or auth popup windows, unrestricted access to the filesystem and biometric authentication. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "default-capability", "description": "Monolithic capability exposed to all windows", "windows": ["*"], "permissions": [ "core:default", "fs:default", "fs:allow-read-text-file", "biometric:authenticate" ] } ``` #### Production Standard (Correct) > **Standard**: Explicitly restricts high-privilege native plugins and commands to the verified 'main' window label and scopes filesystem access to specific application-defined paths. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "main-window-privileged-capability", "description": "Strictly scoped capability for authenticated main webview", "windows": ["main"], "permissions": [ "core:default", { "identifier": "fs:allow-read-text-file", "allow": [{ "path": "$APPDATA/documents/*" }] }, "biometric:authenticate" ] } ``` ### Rust IPC Command Window Identity Invariant #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Omitting window context parameters in privileged custom commands allows any compromised webview or untrusted popup capable of sending IPC messages to execute the command. ```rust #[tauri::command] pub async fn read_secure_vault(key: String) -> Result<String, String> { // Anti-pattern: Accepts invoke request from any webview caller without window verification let secret = fetch_vault_secret(&key).await; Ok(secret) } ``` #### Production Standard (Correct) > **Standard**: Injects WebviewWindow to extract and assert the caller's label identity, blocking unauthorized cross-webview command execution even if capability constraints are breached. ```rust use tauri::{command, Runtime, WebviewWindow}; #[command] pub async fn read_secure_vault<R: Runtime>( window: WebviewWindow<R>, key: String ) -> Result<String, String> { // Invariant: Verify IPC origin strictly belongs to the authoritative main window if window.label() != "main" { return Err("Unauthorized: Webview label forbidden from accessing secure vault".into()); } let secret = fetch_vault_secret(&key).await; Ok(secret) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Tauri 2.0 Scoped Capability Multi-Webview IPC Sandboxing Standard

Tauri 2.0 Scoped Capability Multi-Webview IPC Sandboxing Standard defines an industrial-grade behavioral standard for mobile engineering. Enforces deterministic, window-specific capability isolation across Tauri 2.0 multi-webview architectures to eliminate cross-webview privilege escalation and unauthorized native plugin execution. Prevents shared IPC bridge exposure by requiring fine-grained capability definitions scoped strictly to verified webview and window labels. Guarantees that untrusted or secondary webviews cannot invoke privileged core APIs or native mobile plugins. 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 Window Scoping and Monolithic Capability Binding Across Heterogeneous Webviews 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 Window Scoping and Monolithic Capability Binding Across Heterogeneous Webviews	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 isolate permissions across distinct JSON capability files in `src-tauri/capabilities/`, mapping specific window labels explicitly in the `windows` property.

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.