Back to Details

tauri-security

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Tauri security

Tauri安全

Use the official security model as the source of truth. This guidance is scoped to Tauri 2; verify generated schemas and version-sensitive fields against installed docs.
请以官方安全模型为权威依据。本指南仅适用于Tauri 2；请对照本地安装的文档验证生成的schema与版本相关字段。

Workflow

工作流程

  1. Inventory frontend origins, windows/webviews, commands, plugins, remote content, lifecycle transitions, and data crossing IPC.
  2. Define capabilities per window or webview in 
    src-tauri/capabilities/
    . Grant only required permission identifiers and review merged capabilities because permissions combine across matching windows.
  3. Add scopes that constrain resources where supported; enforce validation in Rust as defense in depth. Review asset protocol scopes and prevent path traversal or unintended exposure.
  4. Configure restrictive CSP and HTTP headers appropriate to the frontend. Avoid wildcard sources and do not weaken headers to fix unexplained failures.
  5. Model lifecycle threats: startup, navigation, window creation, suspend/resume, update/relaunch, crash recovery, and shutdown can change authority or expose stale state.
  6. Review runtime authority and the ecosystem: audit plugins, dependencies, release/update paths, signing, and provenance as part of the threat model.
  7. Treat remote API access as a separate trust boundary. Do not enable remote content or remote API access without explicit origin allowlisting, capability minimization, authentication/authorization, transport security, input validation, and a documented threat model.
  8. Test denied access, malformed input, scope escape attempts, navigation, remote content, headers/CSP, update artifacts, and production builds.
  1. 盘点前端源、窗口/webview、命令、插件、远程内容、生命周期转换以及跨IPC数据。
  2. 在
    src-tauri/capabilities/
    目录下按窗口或webview定义capabilities。仅授予所需的权限标识符，并审查合并后的capabilities——因为权限会在匹配的多个窗口间合并生效。
  3. 在支持的场景下添加作用域以限制资源访问；在Rust中强制实施验证作为深度防御措施。审查资产协议的作用域，防止路径遍历或非预期暴露。
  4. 为前端配置严格的CSP和HTTP头。避免使用通配符源，切勿为了修复不明原因的故障而放宽头部配置。
  5. 对生命周期威胁进行建模：启动、导航、窗口创建、挂起/恢复、更新/重启、崩溃恢复和关闭等阶段都可能变更权限或暴露陈旧状态。
  6. 审查运行时权限与生态系统：作为威胁模型的一部分，需审计插件、依赖项、发布/更新路径、签名与制品来源。
  7. 将远程API访问视为独立的信任边界。若未明确配置源白名单、capability最小化、身份认证/授权、传输安全、输入验证以及成文的威胁模型，切勿启用远程内容或远程API访问。
  8. 测试拒绝访问、畸形输入、作用域逃逸尝试、导航、远程内容、头部/CSP、更新制品与生产构建。

Rules

规则

  • Never ship private keys, tokens, or secrets in frontend code or updater artifacts.
  • Use capabilities and permissions together; neither replaces validation.
  • Treat third-party plugins as privileged Rust code and audit their permissions and source.
  • Do not grant filesystem, process, shell, or remote authority merely to make a prototype work.
  • 切勿在前端代码或更新制品中夹带私钥、令牌或密钥。
  • 配合使用capabilities与权限；二者均不能替代验证。
  • 将第三方插件视为特权Rust代码，审计其权限与源码。
  • 切勿仅为让原型正常运行就授予文件系统、进程、Shell或远程权限。