前端代码里直接写上 Authorization: 'Bearer sk-xxx'，然后 build 一下扔到 Vercel 或者某个 CDN 上——这大概是很多开发者做个人 AI 小工具时的标准操作。方便是真方便，但要说安全性，基本等于零。

API Key 暴露：不是“可能”，是“必然”

打开浏览器开发者工具，切到 Network 面板，随便发一条消息，请求头里那串 sk- 开头的字符串就明晃晃地躺在那里。更致命的是，如果你把代码打包成纯前端静态资源，任何人打开 Sources 面板搜一下 Bearer，你的 Key 就毫无保留地展示在眼前。

说白了，前端没有秘密。所有在前端代码里硬编码的密钥，本质上都是公开信息。有人觉得“反正我就自己用，不公开链接就没事”——这是一个典型的错觉。搜索引擎爬虫、浏览器插件、甚至是公共 WiFi 的中间人攻击，都可能让这个“私密”链接变得不再私密。

被盗用之后，账单有多难看

OpenAI 的 API 是按 token 计费的。一旦 Key 泄露，攻击者可以拿你的 Key 去跑自己的应用，甚至挂到某些“免费 GPT 聚合站”后端薅羊毛。有开发者在 V2EX 上分享过经历：凌晨三点收到 OpenAI 的账单邮件，发现 Key 被人用来批量生成成人内容，一晚上跑掉了将近 200 美元。

更恶心的是，OpenAI 的计费有延迟。你可能几天后才发现异常，而那时候账单已经累积到一个让人血压飙升的数字。对于绑定了信用卡自动扣款的账号，这简直就是一场灾难。

风险不只是钱的问题

即使暂时没人盗用，把 Key 写在前端还有一个隐患：合规性。如果你的应用被分享到公开场合，别人用你的 Key 生成违规内容，责任归属会变得非常模糊。OpenAI 的使用政策明确禁止生成仇恨言论、暴力内容等，一旦触发风控，封的是你的账号和 Key，而不是那个滥用的人。

那点“前端校验”纯属心理安慰

原文里提到做了一个简单的密码验证来防止误用 GPT-4，密码直接写在前端代码里。这种做法在安全领域有个专门的称呼——安全剧场。它制造了一种“有保护”的错觉，但实际上任何稍微懂点技术的人，翻一下源码就能绕过。

前端校验的唯一作用是挡住完全不懂技术的普通用户。对于有恶意的人来说，这连门槛都算不上。

真正该怎么做

如果只是本地跑着玩，localhost 环境下 Key 写死问题不大——毕竟没有对外暴露。但一旦涉及部署到公网，哪怕只是分享给两个朋友试用，也应该加一层后端代理。

最简单的方案：用 Cloudflare Workers 或者 Vercel Serverless Functions 写一个转发接口，Key 存在环境变量里，前端请求自己的 API，后端再带上 Key 去调 OpenAI。几十行代码就能搞定，却能把 Key 从攻击面里完全摘出去。

还有一点容易被忽略：限制调用来源。OpenAI 后台可以为每个 Key 设置 Usage Limits，设定月度硬上限和软上限。即使 Key 真的泄露，损失也是可控的。这不算安全措施，但算得上一条救命的安全带。

说到底，前端直连 API 这件事，本质上是用便利性换安全性。对于随手写的小玩具来说无可厚非，但如果这个工具有一天突然有了几百个用户，那时候再补救，成本就高多了。