Tauri 2.0 Mobile & Multi-Window IPC Capability Sandboxing Standard

--- description: Tauri 2.0 Mobile & Multi-Window IPC Capability Sandboxing Standard - Enforces explicit, least-privilege IPC capability manifests with strict window and webview label scoping for Tauri 2.0 mobile and multi-window architectures. Eliminates wildcard capability assignments to prevent compromised secondary or external webviews from invoking host OS primitives. globs: src-tauri/capabilities/**/*.json, src-tauri/tauri.conf.json, src/**/*.{ts,tsx} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/tauri-v2-mobile-ipc-capability-sandboxing-tauri-2-0-cross--356" --- # Tauri 2.0 Mobile & Multi-Window IPC Capability Sandboxing Standard > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Global Wildcard Window Capability Grants Across Multi-Window Mobile Contexts ## System Constraints You are a Principal Security Architect enforcing the Tauri 2.0 Cross-Runtime IPC Capability Sandboxing Standard. In hybrid mobile and multi-window contexts, Tauri exposes underlying OS primitives via IPC. You must ensure that every capability manifest file explicitly enumerates allowed window and webview labels rather than using wildcard patterns ('*'). Furthermore, secondary surfaces such as OAuth popups, in-app previews, or external content must have an isolated, zero-trust capability set devoid of sensitive host commands (fs, shell, deep-link, biometric, sql). ## Strict Guidelines - Engineers MUST ALWAYS declare dedicated, segregated capability JSON files in 'src-tauri/capabilities/' for each functional window and webview tier. - Engineers MUST NOT use wildcard expressions ('*') in the 'windows' or 'webviews' arrays of any Tauri 2.0 capability configuration. - Code SHOULD restrict secondary mobile windows (e.g., 'auth-popup', 'help-center', 'external-view') to only 'core:default' or non-sensitive, explicitly whitelisted plugin actions. - Services MUST validate caller window labels in Rust command handlers using 'tauri::Webview' or 'tauri::Window' parameters when handling sensitive host interactions. - Components NEVER execute raw 'invoke()' calls without validating that the executing runtime webview possesses the required capability grant. ## Bad vs Good Implementations ### Tauri 2.0 Capability Manifest Scoping #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Using wildcard window mapping ('*') grants full OS filesystem, biometric, and shell access to every window and webview, including authentication modals, OAuth redirects, and third-party web content. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "default-all-access", "description": "Anti-pattern: Grants shell, fs, and sensitive plugins globally to all windows", "windows": ["*"], "permissions": [ "core:default", "fs:default", "fs:allow-read-text-file", "shell:default", "shell:allow-open", "biometric:default" ] } ``` #### Production Standard (Correct) > **Standard**: Capabilities are strictly locked to explicit window and webview labels ('main', 'main-view') and target platforms, preventing secondary windows (like OAuth or in-app browser tabs) from executing native host operations. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "mobile-core-capabilities", "description": "Production: Explicitly scopes sensitive host access strictly to the authenticated main mobile view", "windows": ["main"], "webviews": ["main-view"], "permissions": [ "core:default", "fs:allow-read-text-file", "biometric:authenticate" ], "platforms": ["android", "iOS"] } ``` ### Rust IPC Command Window Context Guard #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Neither the frontend caller nor the backend Rust command validates that the calling context is the primary application webview, allowing secondary or compromised windows to trigger export commands. ```typescript // Rust Command: #[tauri::command] // pub async fn export_user_data(payload: String) -> Result<(), String> { // // ANTI-PATTERN: Does not check caller window label // write_to_secure_storage(payload).await // } import { invoke } from '@tauri-apps/api/core'; // Secondary window blindly invoking privileged command export async function exportData(payload: string): Promise<void> { await invoke('export_user_data', { payload }); } ``` #### Production Standard (Correct) > **Standard**: Both the frontend boundary and the host-side Rust command enforce label verification, creating defense-in-depth against unauthorized IPC command triggers across webview boundaries. ```typescript // Rust Command Defense: // #[tauri::command] // pub async fn export_user_data(app: tauri::AppHandle, window: tauri::Window, payload: String) -> Result<(), String> { // if window.label() != "main" { // return Err("Unauthorized: IPC command restricted to main window".into()); // } // write_to_secure_storage(payload).await // } import { getCurrentWindow } from '@tauri-apps/api/window'; import { invoke } from '@tauri-apps/api/core'; export async function exportData(payload: string): Promise<void> { const current = getCurrentWindow(); if (current.label !== 'main') { throw new Error('Security Violation: exportData must only be called from main window'); } await invoke('export_user_data', { payload }); } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Tauri 2.0 Mobile & Multi-Window IPC Capability Sandboxing Standard

Tauri 2.0 Mobile & Multi-Window IPC Capability Sandboxing Standard defines an industrial-grade behavioral standard for mobile engineering. Enforces explicit, least-privilege IPC capability manifests with strict window and webview label scoping for Tauri 2.0 mobile and multi-window architectures. Eliminates wildcard capability assignments to prevent compromised secondary or external webviews from invoking host OS primitives. 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 Wildcard Window Capability Grants Across Multi-Window Mobile Contexts 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 Wildcard Window Capability Grants Across Multi-Window Mobile Contexts	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, segregated capability JSON files in 'src-tauri/capabilities/' for each functional window and webview tier.

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.