Capabilities, Permissions, And Scopes

Tauri 2 security is built from three pieces:

Minimal Capability

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "default",
  "description": "Main window permissions",
  "windows": ["main"],
  "permissions": ["core:default"]
}

Add permissions as features require them. Do not start from a broad production app config.

Scoped Permission Example

{
  "identifier": "fs:allow-write-text-file",
  "allow": [
    { "path": "$HOME/test.txt" }
  ]
}

This is the pattern to prefer: the permission names the operation, the scope narrows the target.

Review Merged Boundaries

A window or webview can match more than one capability. That effectively merges authority. Review the final permission set per window, not just each file in isolation.

main window = default capability + file-import capability + updater capability
logs window = logs capability only
system monitor window = monitor capability only

CSP And Asset Protocol

CSP and the asset protocol are part of the same security review. If the app allows local files, loopback URLs, custom protocols, unsafe-eval, or broad HTTPS, write down why.

Questions to ask:

Does release CSP still contain dev-only localhost origins?
Does `assetProtocol.scope` expose more files than the app needs?
Can remote content load assets or call Tauri APIs?
Does the command still validate inputs even when a scope exists?

Remote API Caution

Remote access to Tauri APIs is an advanced feature. Avoid it by default. The official docs warn that some platforms cannot distinguish iframe requests from the top-level window for remote API access, which can weaken your mental model.

Jan Case Study

Jan’s default capability includes shell spawn/open, updater permissions, HTTP permissions, multiple custom plugin permissions, and remote URL allowances. That may be justified for a production AI desktop app. It is not a safe starter baseline.