Isolation Pattern & Trusting Remote Content

"The most dangerous thing you can do in Tauri is point a privileged window at someone else's website."

Remote Content Inherits the Window's Powers

A window loads your bundled frontend — code you wrote and trust. The moment you point a window at an external URL (WebviewUrl::External), you're running code you don't control, and by default Tauri treats it with suspicion. The danger is granting a window capabilities and also letting it load remote content: now a remote page (or anything injected into it) can call your native commands. Treat 'window with capabilities' and 'window showing remote content' as a combination to avoid. If you must load remote content, give that window the absolute minimum capabilities — ideally none.

The Remote Context in Capabilities

Capabilities are origin-aware. A capability can specify a remote context listing which external URLs are even allowed to use its permissions. By default, your grants apply to your local app content, not to arbitrary remote origins. If you deliberately need a trusted remote origin to use a command, you opt it in explicitly — and you should scope that to one exact origin, never a wildcard. The default (local-only) is the safe one; widening it is a decision to make consciously.

The Isolation Pattern: Defense in Depth

For high-assurance apps, Tauri offers the isolation pattern: a tiny, separate, sandboxed application that sits between your frontend and the core and sees every IPC message before it reaches Rust. You can use it to validate or sanitize messages — a last checkpoint even if your main frontend is compromised. Enable it in config by setting the security pattern to isolation with its own directory. It's extra setup you won't always need, but for an app handling sensitive data it's a meaningful additional layer.

Code

Enabling the isolation pattern·json

// tauri.conf.json — opt into the isolation pattern (defense in depth).
// Tauri injects a sandboxed app from this dir that intercepts IPC.
{
  "app": {
    "security": {
      "pattern": { "use": "isolation", "options": { "dir": "../isolation-dist" } }
    }
  }
}

Scoping a remote origin to one exact URL·json

// A capability that lets ONE trusted remote origin use a narrow permission.
// Default is local-only; this is an explicit, scoped opt-in — never "*".
{
  "identifier": "trusted-remote",
  "windows": ["embed"],
  "remote": { "urls": ["https://trusted.example.com"] },
  "permissions": ["core:event:default"]
}

Exercise

Reason through a scenario: your app needs to embed a third-party web page. Write down (1) what capabilities that window should have (hint: as few as possible), (2) why you would NOT reuse your main window's capability for it, and (3) one reason you might add the isolation pattern. You're practicing the judgment that keeps remote content from becoming remote compromise.

Hint

The embed window should ideally hold zero native permissions — it's untrusted. Reusing main's capability would hand the third party your native powers. Isolation adds a checkpoint that can sanitize IPC even if something slips through.