Tauri 2.0 Multi-Window Plugin Capability Scope Isolation

--- description: Tauri 2.0 Multi-Window Plugin Capability Scope Isolation - Enforces strict per-window capability manifest partitioning in Tauri 2.0 multi-window architectures to prevent cross-webview privilege escalation. Webview instances must bind exclusively to least-privilege capability sets keyed directly to explicit window labels and origins. Global plugin permissions or wildcard window bindings that expose OS-level hardware, file systems, or biometric APIs across window boundaries are strictly prohibited. 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/tauri2-multiwindow-plugin-capability-isolation" --- # Tauri 2.0 Multi-Window Plugin Capability Scope Isolation > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Global Plugin Permission Bleed via Wildcard Window Capability Mappings ## System Constraints You are a Principal Security Architect enforcing Tauri 2.0 capability isolation invariants. Every webview window in a Tauri 2.0 multi-window architecture must be cryptographically and architecturally sandboxed using deterministic capability manifests. You must reject wildcard window selectors, prohibit shared execution contexts between trusted core windows and untrusted child webviews, and guarantee that native OS plugin permissions (e.g., Biometrics, Deep Linking, File System, Keystore) are restricted exclusively to explicit, non-overlapping window identifiers. ## Strict Guidelines - Engineers MUST ALWAYS declare dedicated, granular capability files under `src-tauri/capabilities/` targeting specific window labels (e.g., `"windows": ["auth-window"]`). - Engineers MUST NOT use wildcard selectors (`"*"`) in capability manifest `windows` arrays for any plugin accessing native OS facilities, keystores, or platform APIs. - Engineers MUST configure explicit cryptographic scopes within capability definitions when permitting file system or network commands, disallowing blanket default allows. - Code SHOULD spawn secondary webviews using `WebviewWindowBuilder` with explicitly designated labels matching defined security capability manifests. - Services MUST validate caller window labels in custom Rust IPC command handlers using `tauri::WebviewWindow` or `tauri::ipc::Request` before executing sensitive host routines. - Components NEVER execute administrative IPC commands from auxiliary or dynamically spawned webviews without verified capability attestation. ## Bad vs Good Implementations ### Tauri 2.0 Capability Manifest Window Scoping #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Using a wildcard window selector (`"*"`) grants every child window, modal, and secondary webview full access to sensitive file system and biometric APIs, exposing the app to privilege escalation if a secondary window loads external or compromised content. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "default-capability", "description": "Shared capabilities for all app windows", "windows": ["*"], "permissions": [ "core:default", "fs:default", "fs:allow-read-text-file", "biometric:authenticate" ] } ``` #### Production Standard (Correct) > **Standard**: Binds sensitive biometric and filesystem capabilities exclusively to the `main-auth-window` label with precise path-level scoping, preventing secondary webviews from invoking host capabilities. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "auth-isolated-capability", "description": "Strictly scoped capabilities for the primary authentication window", "windows": ["main-auth-window"], "permissions": [ "core:default", "biometric:authenticate", { "identifier": "fs:allow-read-text-file", "allow": [{ "path": "$APP_DATA_DIR/secure_tokens/*" }] } ] } ``` ### Rust IPC Caller Window Attestation #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Omits caller identity verification, allowing any webview in the multi-window architecture to trigger host-level disk I/O outside the capability boundary. ```rust // Rust IPC command without window identity verification #[tauri::command] async fn read_secure_vault(app_handle: tauri::AppHandle) -> Result<String, String> { // Vulnerable: Any window that can invoke this command will read the vault std::fs::read_to_string("/vault/secrets.json").map_err(|e| e.to_string()) } ``` #### Production Standard (Correct) > **Standard**: Verifies that the calling webview matches the authorized `main-auth-window` context before dispatching privileged file operations, complementing Tauri's capability security layer. ```rust // Rust IPC command enforcing strict window context isolation #[tauri::command] async fn read_secure_vault(window: tauri::WebviewWindow) -> Result<String, String> { if window.label() != "main-auth-window" { return Err("AccessDenied: Window context lacks vault privileges".into()); } // Invariant: Only explicit webview contexts can trigger sensitive execution std::fs::read_to_string("/vault/secrets.json").map_err(|e| e.to_string()) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Tauri 2.0 Multi-Window Plugin Capability Scope Isolation

Tauri 2.0 Multi-Window Plugin Capability Scope Isolation defines an industrial-grade behavioral standard for mobile engineering. Enforces strict per-window capability manifest partitioning in Tauri 2.0 multi-window architectures to prevent cross-webview privilege escalation. Webview instances must bind exclusively to least-privilege capability sets keyed directly to explicit window labels and origins. Global plugin permissions or wildcard window bindings that expose OS-level hardware, file systems, or biometric APIs across window boundaries are strictly prohibited. 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: Global Plugin Permission Bleed via Wildcard Window Capability Mappings 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	Global Plugin Permission Bleed via Wildcard Window Capability Mappings	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 declare dedicated, granular capability files under `src-tauri/capabilities/` targeting specific window labels (e.g., `"windows"

Engineers MUST ALWAYS declare dedicated, granular capability files under `src-tauri/capabilities/` targeting specific window labels (e.g., `"windows": ["auth-window"]`).

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.