22.5 企业级应用安全加固方案

在企业环境中部署桌面应用，安全不是可选项，而是必须通过的合规门槛。Tauri 的安全模型虽然已经比传统方案更严格，但仍需要针对企业场景进行主动加固。以下方案覆盖了从配置到运行时的关键环节，都是实际可落地的措施。

1. 最小权限的 CSP 与权限白名单

目标：即使前端被注入恶意代码，也无法加载外部资源或调用未授权的后端命令。

在 tauri.conf.json 中，必须显式限制 Content Security Policy（CSP），并只开放前端真正需要调用的 API。

{
  "tauri": {
    "allowlist": {
      "all": false,                 // 全部默认关闭
      "shell": {
        "all": false,               // 禁止执行系统命令
        "open": true                // 只允许用默认程序打开链接
      },
      "fs": {
        "scope": ["$APPDATA/*"],    // 仅允许访问应用专属目录
        "readFile": true,
        "writeFile": true
      },
      "http": {
        "scope": ["https://api.your-company.com/*"], // 仅允许访问企业 API
        "request": true
      }
    },
    "security": {
      "csp": "default-src 'self'; connect-src https://api.your-company.com; img-src 'self' data:; style-src 'self' 'unsafe-inline'"
    }
  }
}

重要提醒：切勿为了方便而将 allowlist.all 设为 true，这等于把房子钥匙交给了入侵者。

2. 自定义协议深度防御

CSP 可以阻止外部脚本加载，但企业内还需要防止通过自定义协议（如 tauri://）进行特权提升。

禁止前端直接访问文件协议：确保所有页面资源都由 Tauri 的资产协议加载，而不是 file://。Tauri 默认使用自定义的 asset:// 或 https://tauri.localhost，CSP 中应限制为 'self'。
过滤 IPC 命令调用：即使命令已白名单，也应当在 Rust 端对参数做强类型校验，避免路径遍历、命令注入等二次注入。

#[tauri::command]
fn read_file(file_name: String) -> Result<String, String> {
    // 禁止路径包含 ".." 或绝对路径
    if file_name.contains("..") || std::path::Path::new(&file_name).is_absolute() {
        return Err("Access denied".into());
    }
    let path = std::path::PathBuf::from(sanitized_base_dir()).join(file_name);
    std::fs::read_to_string(path).map_err(|e| e.to_string())
}

3. 强制的上下文隔离与进程沙箱

Tauri 2.0 默认开启上下文隔离，但需确认并强化：

在 tauri.conf.json 中检查 tauri > security > contextIsolation，确保为 true（通常默认）。
如果使用 <webview> 嵌入外部页面，也要设置 sandbox 属性。
对于敏感页面（如登录、支付嵌入），建议单独创建受限窗口，关闭文件访问权限，开启额外的 sandbox 模式（Windows 上对应 --no-sandbox 的反向操作，Tauri 默认已启用沙箱）。

4. 签名、完整性校验与分发控制

企业分发最怕被篡改或中间人攻击，以下措施缺一不可：

代码签名：Windows 上必须使用 EV 代码签名证书对 .exe 和 .msi 进行数字签名；macOS 需要公证（Notarization）。在 CI 流程中加入自动签名，防止未签名构件流出。
应用更新签名：Tauri 的 updater 插件支持签名验证。必须生成公私钥对，将公钥内置在应用中，更新包在发布时用私钥签名，应用在下载后先验签再安装。
企业私有分发渠道：如果是内部系统，可以将更新服务器部署在内网，并要求 HTTPS 双向证书验证，只允许受控的设备获取更新。

// updater 配置示例
"updater": {
  "active": true,
  "endpoints": ["https://internal.example.com/update"],
  "pubkey": "你的公钥字符串",
  "dialog": false  // 静默更新，避免用户中断
}

5. 敏感数据存储与传输加密

本地存储：不要明文存 token 或密码。使用 tauri-plugin-store 并配合应用的加密 key（如从操作系统凭据管理器获取的随机密钥）进行 AES 加密。或者直接调用系统的凭据 API（Windows Credential Manager、macOS Keychain）。
网络通信：所有后端 API 强制 HTTPS，且在 allowlist.http.scope 中只允许企业域名。可启用证书固定（certificate pinning），在 Rust 端配置自定义的 TLS 验证器，防止中间人代理破解。
内存安全：对于极敏感数据（如解密后的密钥），用完后使用 Rust 的内存清零 crate（如 zeroize）擦除，避免被内存转储。

6. 日志脱敏与异常上报

生产环境关闭 devtools：务必检查并移除调试入口，在 tauri.conf.json 中将 "withGlobalTauri": false 或前端内移除 window.TAURI 的调试调用。禁止通过命令行参数打开开发者工具。
日志过滤：在 Rust 后端中对所有 IPC 请求参数脱敏处理，确保日志中不会出现明文密码、token 或个人信息，再发送到企业日志系统。
自动异常隔离：如果应用崩溃，只上传脱敏后的堆栈，不上传内存镜像。

7. 运行时自我保护

防调试：在启动时检测调试器，如果发现即退出（可参考 Rust crate anti-debug），但注意在某些合规环境下需允许远程调试，应做成可配置开关。
完整性自检：定期哈希校验本身的二进制和重要资源文件，防止被篡改。
浏览器环境强化：禁用 WebView 的远程调试端口，通过环境变量或配置阻止 --remote-debugging-port 启动参数。

这七项措施构成了企业级 Tauri 应用的安全基准。核心思路不变：最小化开启功能、对每次调用做强制校验、签名和加密覆盖整个生命周期、默认禁止不安全行为。每一条都是在真实攻防场景中验证过的，落地成本不高，但能让你在安全审计时胸有成竹。