Tauri 2.0 Multi-Window Webview IPC Capability Scoping Fence

--- description: Tauri 2.0 Multi-Window Webview IPC Capability Scoping Fence - Enforces strict window-level capability isolation and explicit IPC permission schemas across Tauri 2.0 mobile and desktop targets. Disallows wildcard permissions and global plugin exposure, ensuring secondary, untrusted, or external webview windows cannot access sensitive native plugins or escalate OS privileges. 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-webview-capability-scoping-fence" --- # Tauri 2.0 Multi-Window Webview IPC Capability Scoping Fence > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Global Plugin IPC Exposure Across Untrusted Secondary Webview Windows ## System Constraints You are a Principal Security Architect enforcing Tauri 2.0 Multi-Window Webview IPC Capability Scoping Fences. In Tauri 2.0, capabilities are window-bound and permission-scoped. You must prohibit default capability inheritance across windows, disallow wildcard plugin access (e.g., 'core:default', 'fs:default') on non-main windows, and prevent remote or third-party webview instances from invoking privileged IPC commands. ## Strict Guidelines - Engineers MUST ALWAYS isolate capabilities per window label inside `src-tauri/capabilities/*.json` rather than attaching broad permissions to all windows. - Engineers MUST NOT map sensitive plugins (such as `fs`, `shell`, `biometric`, or `os`) to wildcard window selectors (`"windows": ["*"]`) or secondary webview instances. - Engineers MUST configure explicit remote URL access boundaries (`remote: { url: ... }`) when embedding external origins or OAuth flows, ensuring IPC execution is strictly denied or limited to an air-gapped IPC fence. - Rust plugin initialization MUST declare granular sub-permissions instead of default bundles (e.g., use `fs:allow-read-text-file` scoped to a specific directory instead of `fs:default`). - Dynamic window creations via `WebviewWindowBuilder` or TypeScript API MUST assign unique window labels matching exact capability boundaries defined in configuration schemas. ## Bad vs Good Implementations ### Tauri 2.0 Capability Schema Scoping #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Assigning wildcard permissions across `*` windows allows untrusted secondary or remote webviews (e.g., OAuth popups or external previews) full access to local filesystem, shell execution, and dialog manipulation. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "default-capability", "description": "Global capability applied blindly to every window", "windows": ["*"], "permissions": [ "core:default", "fs:default", "shell:default", "dialog:all" ] } ``` #### Production Standard (Correct) > **Standard**: Explicitly binds the capability schema to dedicated window labels (`auth-popup`, `external-viewer`), completely excluding filesystem and shell plugins and enforcing strict URL allowances. ```json { "$schema": "../gen/schemas/desktop-schema.json", "identifier": "untrusted-external-window", "description": "Strictly confined sandbox for external webviews and OAuth flows", "windows": ["auth-popup", "external-viewer"], "permissions": [ "core:webview:allow-close", { "identifier": "http:default", "allow": [{ "url": "https://auth.company.internal/*" }] } ] } ``` ### Programmatic Webview Construction with Strict Window Labeling #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Reusing the 'main' window label or generating arbitrary un-scoped window labels causes the webview to inherit the main window's elevated native capabilities. ```typescript import { WebviewWindow } from '@tauri-apps/api/webviewWindow'; // Creating a secondary window using the default identifier space export function openExternalUrl(targetUrl: string) { const webview = new WebviewWindow('main', { url: targetUrl }); webview.once('tauri://error', (e) => console.error(e)); } ``` #### Production Standard (Correct) > **Standard**: Validates the URL protocol and uses the explicit `RESTRICTED_WINDOW_LABEL`, matching the fenced capability schema where native OS capabilities are completely inaccessible. ```typescript import { WebviewWindow } from '@tauri-apps/api/webviewWindow'; const RESTRICTED_WINDOW_LABEL = 'external-viewer'; export async function openExternalViewer(targetUrl: string): Promise<WebviewWindow> { const parsed = new URL(targetUrl); if (parsed.protocol !== 'https:') { throw new Error('Only secure HTTPS origins are permitted in isolated frames'); } const webview = new WebviewWindow(RESTRICTED_WINDOW_LABEL, { url: targetUrl, title: 'External Resource', dangerouslyDisableJSErrorConsole: false }); await webview.once('tauri://created', () => { // Window successfully created under untrusted-external-window capability fence }); return webview; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Tauri 2.0 Multi-Window Webview IPC Capability Scoping Fence

Tauri 2.0 Multi-Window Webview IPC Capability Scoping Fence defines an industrial-grade behavioral standard for mobile engineering. Enforces strict window-level capability isolation and explicit IPC permission schemas across Tauri 2.0 mobile and desktop targets. Disallows wildcard permissions and global plugin exposure, ensuring secondary, untrusted, or external webview windows cannot access sensitive native plugins or escalate OS privileges. 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 IPC Exposure Across Untrusted Secondary Webview Windows 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 IPC Exposure Across Untrusted Secondary Webview Windows	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 capabilities per window label inside `src-tauri/capabilities/*.json` rather than attaching broad permissions to all 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.