Isolation Pattern（隔离模式）在前端与 Core 之间加一道“加密网关”，拦截与校验所有 IPC

一、Isolation Pattern 是什么

Isolation Pattern 的核心目标是：用 JavaScript 在 WebView 内部实现一层安全拦截器，把前端到 Core 的 IPC 通道变成"必须先过隔离层"的受控通道。

在这个模式下，前端应用并不是直接把消息交给 Core，而是：

先交给隔离应用（Isolation application）
隔离应用运行 hook，对消息做检查/改写
隔离应用将消息用 AES-GCM 加密（密钥每次启动动态生成）
加密后的消息再被转交给 Core 解密并处理

隔离应用本质上就是一段 被注入的安全 JS，它是 Isolation Pattern 的"执行载体"。

二、为什么要 Isolation：解决"前端不可信内容"的威胁模型

Isolation Pattern 诞生的动机非常现实：现代前端项目往往依赖庞大且深层嵌套的依赖树，风险来源包括但不限于：

构建期工具链（几十到上百个依赖）
运行时代码（打包进产物的依赖同样可能很多）
外部内容或第三方脚本（如果你加载了外部资源，风险更高）

这些都可能导致"前端执行环境不完全可信"。Isolation 的价值就在于：即使前端被污染，仍然能在进入 Core（拥有完整系统权限）之前做集中拦截与约束。

三、什么时候用：官方强烈建议"能用就用"

Isolation Pattern 的一个特点是：它拦截的是"所有 IPC 消息"，因此几乎在任何应用里都能启用。

更进一步，官方建议当你使用外部 Tauri API（比如文件系统、HTTP、shell、窗口管理等）时，最好同时做更严格的"锁定（lockdown）"策略，并利用隔离应用进行输入验证，例如：

文件读写：限制路径必须落在应用允许的目录内，禁止越权访问
HTTP 请求：限制 Origin、URL 白名单、Header 约束等
事件（Events）：即使是"常开 API"，也能在隔离层拦截与验证，因为事件触发可能导致 Rust 执行敏感动作

四、怎么工作：sandbox iframe + AES-GCM 加密通道

Isolation Pattern 的机制可以概括为"三件事"：

隔离运行环境
利用 <iframe sandbox> 的沙箱能力，让隔离应用在更受限、更可控的环境中运行，减少被主前端影响的概率。
强制消息经由隔离层
Tauri 在页面加载时强制所有 IPC 调用先路由到隔离应用。
加密与动态密钥
隔离应用使用浏览器 SubtleCrypto 对消息进行 AES-GCM 加密，再传回主前端并转交给 Core；Core 解密后像正常 IPC 一样处理。密钥每次应用启动都会重新生成，避免攻击者复用旧密钥对消息做离线篡改。

IPC 消息的大致流程（按步骤理解）

IPC handler 收到前端消息
IPC handler → 隔离应用
隔离应用 hook 执行（可修改/校验 payload）
隔离应用使用运行时生成密钥 AES-GCM 加密
隔离应用 → IPC handler（传回加密消息）
IPC handler → Tauri Core（Core 解密并处理）

五、性能影响：有开销，但通常可忽略

Isolation 相比默认模式会增加：

每条 IPC 的加解密开销（AES-GCM）
启动时生成一次安全随机密钥（依赖系统熵池）

大多数应用不会明显感知这点开销，因为 AES-GCM 很快；真正需要关注的是"极致性能敏感应用"，它们往往依赖更少、攻击面更小，也更容易接受其它模式。

如果你在无头环境做 WebDriver 集成测试，可能会遇到熵不足导致启动慢的问题；这时候需要在系统层补足熵源（例如 Linux 环境的相关服务/机制）。

六、限制与坑点：Windows 的 sandbox iframe 外部文件加载限制

一个最重要的限制来自平台不一致：Windows 上 sandbox iframe 对外部文件加载存在问题。因此 Tauri 在构建时做了"脚本内联（script inlining）"步骤：

传统 <script src="index.js"></script> 这种相对路径脚本会被内联处理，从而正常工作
但较新的机制例如 ES Modules （type="module" / import ...）在隔离应用里可能无法正常加载

结论是：隔离应用尽量用"老实的、最简单的脚本加载方式"，别追求花哨打包玩法。

七、官方建议：隔离应用要极简、低依赖

Isolation 的目标是抵御"开发期/供应链威胁"，所以隔离应用本身也要避免成为新的供应链入口。

推荐做法：

逻辑尽量少：只做校验、白名单、简单转换
依赖尽量少：最好零依赖或极少依赖
构建步骤尽量少：减少额外工具链带来的风险

八、手把手示例：创建最小 Isolation Application

假设你主前端的 frontendDist 是 ../dist，隔离应用输出到 ../dist-isolation。

1）隔离应用：../dist-isolation/index.html

xml 复制代码

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Isolation Secure Script</title>
  </head>
  <body>
    <script src="index.js"></script>
  </body>
</html>

2）隔离应用：../dist-isolation/index.js

javascript 复制代码

window.__TAURI_ISOLATION_HOOK__ = (payload) => {
  // 不做校验，仅打印并原样返回
  console.log('hook', payload);
  return payload;
};

这个 hook 是你真正写安全逻辑的地方：你可以在这里做参数校验、路径约束、Origin 校验、命令白名单等。

九、启用 Isolation Pattern：tauri.conf.json 配置

json 复制代码

{
  "build": {
    "frontendDist": "../dist"
  },
  "app": {
    "security": {
      "pattern": {
        "use": "isolation",
        "options": {
          "dir": "../dist-isolation"
        }
      }
    }
  }
}

含义非常直观：

主前端资源在 ../dist
security pattern 使用 isolation
隔离应用目录在 ../dist-isolation