大多数泄露事故的起点都是一句类似的话:"我把一个 JWT 粘贴进某个调试工具想看看内容,24 小时后我们的预发布环境被清空了。"

原理很简单。网页工具的 JavaScript 运行在浏览器里,但当你把一个凭据粘贴进它的输入框,这个值就已经进入了页面的内存。从那一刻起,一个分析埋点、一段复制来的代码里故意埋的窃取逻辑,或者一个"帮你用 AI 处理输入"的功能,都可能以你从未同意的方式把它泄露出去。

这一页是一份简短的检查清单——不是散播焦虑,只是区分"没事"和"第二天早上在 Have I Been Pwned 上见到自己"的那些习惯。

30 秒法则

任何时候,一个工具向你要一个看起来像凭据的值——token、私钥、连接字符串、.env 文件的内容——粘贴之前先问三个问题:

  1. 我信任这个页面吗?打开开发者工具,看网络面板。如果你看到任何请求发往一个不是你手动输入的域名,停下。
  2. 这个值明天还有效吗?如果你反正会轮换这个密钥,最坏情况的爆炸半径会小得多。
  3. 我能脱敏吗?很多工具只需要数据的结构,不需要真实数据。先用假值试一遍。

三个问题里只要有一个答案是"否"或"不确定",就不要粘贴。

为什么"纯浏览器端"是正确的底线

长期来看唯一能站得住的架构,是密钥从不离开设备的架构。这正是 Plobi-kit 和少数几个隐私优先工具站的全部前提:工作发生在你浏览器的 JavaScript 引擎里,结果留在本地内存,除非你主动复制。

评估一个工具时,看这几个信号:

  • 页面加载时网络面板里没有任何第三方脚本。
  • 网站有一页清晰的"工作原理",描述其纯本地架构。
  • 隐私政策很短,并明确写了哪些东西会存在服务端——通常是:什么都不存,除非你主动触发。

如果一个工具答不上这几条,把它当成潜在泄露源,并且事后轮换你粘过的密钥。

能拦住最多事故的两个习惯

分享前先脱敏。大多数工具处理的是真实值的形状,而不是内容。只用公开算法解码 JWT。把签名替换成占位文本后再检查 token 的 claims。调试场景里你几乎从不需要活体密钥。

分享后立即轮换。即使你今天信任某个工具,也把任何粘贴过的凭据视为已泄露。调试结束后花 30 秒轮换密钥毫无成本;一次泄露事故的代价是整整一周。

当工具本身的设计就在鼓励这两个习惯时,遵守它们会容易得多。这也正是我们只对这一类在线工具感兴趣的原因。