Tauri 的安全模型不是一套后知后觉的补丁，而是从内核设计之初就奠定的铁律：默认关闭一切，显式开启所需。 这意味着，哪怕你的前端代码被完全劫持，攻击者也几乎什么都做不了——除非你事先明确授予了某项权限。
为什么需要“默认关闭”？
传统的桌面应用（包括一些 Web 嵌入式方案）往往内置了大量开放的系统调用，前端脚本可以随意读写文件、发起网络请求、甚至执行本地命令。一旦前端存在 XSS 或依赖链被投毒，这些能力立刻变成攻击者的武器。Tauri 反其道而行之：它将所有潜在危险的操作都封装成“能力（Capability）”，启动时默认全部禁用。你的应用不声明，它就不存在。
如何工作？
在 Tauri 项目中，权限声明集中在一个名为 capabilities 的配置里（通常是 src-tauri/capabilities/default.json），你以白名单的方式列出允许前端调用的命令、网络域名、文件路径等。例如：
{
"$schema": "../gen/schemas/desktop-schema.json",
"identifier": "default",
"description": "默认能力集",
"windows": ["main"],
"permissions": [
"core:default",
"fs:allow-read-text-file",
"http:default",
{
"identifier": "http:default",
"allow": [{ "url": "https://api.example.com/**" }]
}
]
}这里：
core:default启用了最基本的窗口管理、事件监听等安全无害的能力。fs:allow-read-text-file显式授权读取文本文件，未授权的写操作或二进制读取则无法进行。http:default允许发起 HTTP 请求，但通过allow字段进一步限制只能访问api.example.com下的接口，其他域名则被阻断。
如果前端试图调用一个未声明的命令（例如 fs:write-text-file），Rust 层会直接拒绝该 IPC 请求，并抛出错误，根本不触及文件系统。
真实场景举例
假设你正在开发一个本地的 Markdown 编辑器：
- 需要读取用户选择的文件 → 开启
fs:allow-read-file或更细粒度的dialog:allow-open。 - 需要保存文件到磁盘 → 额外开启
fs:allow-write-file。 - 需要在线检查更新 → 仅允许访问
https://yourapi.com/update。 - 其他任何需求（如访问摄像头、读取系统剪贴板）都保持禁用。
如果某天你的某个前端依赖库被恶意篡改，注入了读取密码文件的代码，由于你没有授予对 /etc/passwd 或 C:\Windows\System32 的访问权，攻击代码会直接被 Rust 层拦截。
对开发者的好处
- 安全审计清晰：一目了然地看到你的应用到底拥有哪些权力，符合零信任设计。
- 防止误操作：即使你或团队成员误写了调用剪贴板的代码，只要没在配置中开启，应用编译后也无法执行，提前暴露问题。
- 企业分发合规：很多企业的安全审查要求“应用不能做未声明的事情”，Tauri 的这种强制白名单模式天然满足。
一句话总结：Tauri 把“最小权限原则”变成了可执行的配置，而不是纸面建议。你只给你需要的能力，其余一切皆拒之门外。这种“零信任”理念让每个 Tauri 应用都自带坚实的安全基础。