在 Tauri 中，WebView 默认只加载本地文件——你的前端资源全部打包在应用内部，源地址类似 tauri://localhost。如果你需要加载远程页面（例如嵌入一个第三方后台管理界面，或者让 WebView 指向你的在线服务），就必须面对安全边界的变化。Tauri 为此设计了一套严格但灵活的隔离机制，核心目标是：即使前端来自不受信任的远程源，它也无法绕过 IPC 限制或获取未授权的系统权限。
1. 默认的同源沙箱
Tauri 的 WebView 默认开启严格的同源策略和内容安全策略（CSP）。本地 HTML 文件在 tauri://localhost 域下运行，所有 IPC 命令的调用都受这个域的约束。如果直接 window.location.href = 'https://example.com' 跳转到远程页面，新页面将失去调用 Tauri API 的能力——因为它的源不再是 tauri://localhost，也不再位于被信任的上下文中。
2. 仅允许加载白名单内的远程域名
要安全地加载远程页面，首先需要在 tauri.conf.json 中把目标域名加入允许列表。针对不同的 Tauri 版本，配置字段略有区别：
Tauri v2（推荐）
{
"app": {
"security": {
"dangerousRemoteDomainIpcAccess": [
{
"domain": "app.example.com",
"windows": ["main"],
"enableTauriApi": false
}
]
}
}
}domain：允许的远程域名，可带子域名通配符如*.example.com。windows：限定该规则只对指定标签页生效。enableTauriApi：是否允许该远程页面调用 Tauri IPC 命令。务必保持为false，除非你完全信任该远程内容。 如果设为true，远程页面就能像本地页面一样调用你定义的所有 Rust 命令，风险极高。
对于 Tauri v1，配置位于 tauri > security > dangerousRemoteDomainIpcAccess，结构类似。
3. 隔离远程页面的 IPC 能力
即使允许加载远程页面，Tauri 强烈建议不要让远程页面直接调用 IPC。推荐的做法是：
- 保持
enableTauriApi: false，让远程页面仅用于展示 UI。 - 如果必须让远程页面触发后端逻辑，使用 受控的消息代理：远程页面通过
postMessage与本地主页面通信，主页面（运行在tauri://localhost）收消息后再调用 Tauri IPC。这样所有敏感调用仍处于本地信任域中，远程代码无法直接发起文件读写或系统命令。
示例通信流程：
[远程页面] postMessage({ action: 'save', data: ... })
↓
[本地页面] window.addEventListener('message', handler) → invoke('save_command')
↓
[Rust 后端] 执行文件写入操作4. 安全加固清单
当你决定引入远程页面时，请逐项检查以下措施：
- 永远不将
enableTauriApi设为true，除非远程内容完全由你控制且使用了严格的子资源完整性（SRI）校验。 - 设置 CSP 头，限制远程页面可加载的脚本、样式、图片来源，避免被注入恶意代码。
- 启用 HTTPS，所有远程域名使用 TLS 加密，防止中间人篡改。
- 限制打开的窗口数量，在
windows数组中精确指定标签页，避免其他窗口意外加载远程内容。 - 监控网络异常，在 Rust 端对来自远程触发的 IPC 命令做额外的参数校验和频率限制，哪怕这些命令原本是由本地页面代理转发的。
5. 不是“开了就行”的开关
很多开发者在调试时会顺手设置 dangerousRemoteDomainIpcAccess，然后忘记关闭。这个字段的名字本身就带有“dangerous”，是在提醒：一旦开启，你就把 Tauri 精心构建的沙箱撕开了一个口子。因此，请把它看作临时的开发辅助，而非生产环境的默认配置。如果你需要让应用加载第三方网页，比较安全的替代方案是使用 <iframe> 嵌入，并在 iframe 上设置 sandbox 属性，进一步限制其能力。
Tauri 的远程页面支持本质上是一种“有控制的放行”。只有理解并正确实施上述隔离机制，你才能在享受远程内容灵活性的同时，守住应用的安全底线。