可靠的网页把服务密钥留在浏览器之外

交给浏览器的长期密钥就不再是秘密

你做了一个聊天网页，用户输入问题，页面调用模型并展示答案。为了尽快跑通流程，你可能想把接口密钥直接放进前端。功能确实能用，但这也意味着：每位访问者都可能拿到这把钥匙。

接口密钥类似一张能够记账的通行证。别人拿到它，可能以你的身份发起请求，消耗你的余额；具体还能访问哪些资源，取决于密钥权限。页面上没有显示密钥，不等于访问者无法找到密钥。

浏览器必须下载并执行前端资源，用户也能检查网络请求。代码压缩、变量改名、字符串拆分，都不能把已经交给浏览器的秘密重新藏起来。使用加密连接可以保护传输过程，却不能阻止浏览器的使用者查看自己收到的数据。

前端环境变量不能代替服务端的秘密存储

环境变量这个名字容易让新手产生误解。某些前端构建工具会把指定变量的值直接写进生成的页面脚本。如果密钥通过这种方式进入前端产物，它依然可以被读取。关键不是变量叫什么，而是它最终在哪里被使用。

真正的边界是：只有你控制的服务端持有长期服务密钥。浏览器向你的服务端提交问题，服务端完成检查，再携带密钥请求模型，最后把需要展示的结果返回页面。没有传统服务器也没关系，服务端函数同样可以承担这一层，但必须确认秘密不会被打包发送给浏览器。

服务端转发必须同时限制调用者与调用范围

增加一个转发接口只是开始。如果任何人都能无限调用它，即使看不到上游密钥，也能借你的服务持续产生费用。登录、权限检查和用量限制，应当与转发功能一起设计，而不是等账单异常后再补。

• 确认调用者身份，并检查他是否有权使用相关功能；允许匿名体验时，也应设置严格额度。
• 由服务端限定可用模型、输入大小和输出上限，不让浏览器任意指定转发目标。
• 按用户限制请求频率、并发数量和累计用量，并设置整体费用告警与必要的停用阈值。
• 返回结果时只保留必要内容，避免把上游认证信息或内部错误详情发给浏览器。

只检查请求来自哪个网页并不充分，跨域限制也不能替代身份验证。攻击者不必通过你的网页，就可能直接请求公开接口。反过来，用户登录所需的会话凭据也要妥善保护；把上游密钥移到服务端，不代表前端从此没有安全风险。

接入模型服务时应当保持同一条安全边界

本文由重视质量的模型接口中转服务 BestRelay 发布。它按请求中指定的官方模型转发，不替换模型，覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen 和 Grok 等系列。无论直接连接模型提供商，还是使用中转服务，网页都不应持有你的长期服务密钥。

BestRelay 可配合 Claude Code、Codex、Gemini CLI 以及任意 OpenAI SDK 使用，但工具兼容性不会改变密钥的保管责任。开发工具里的凭据也不应被复制到网页中。准备接入时，可以创建一个 BestRelay 账户。

费用管理同样属于安全设计。BestRelay 按提供商报告的词元数量按量计费，缓存读取与写入分别定价，因此不能只凭页面请求次数估算开销。成员邀请他人充值可获得推荐佣金，但推荐奖励不应影响密钥权限、用户额度或费用监控的设置。

发现密钥暴露之后必须先撤销再清理

如果密钥曾进入公开仓库、前端产物或可访问的日志，应把它视为已经泄露。先撤销旧密钥或完成安全轮换，再检查调用记录与费用。只删除当前文件不够，因为历史记录、缓存和别人保存的副本可能仍然存在。

日常维护时，把开发环境和生产环境的密钥分开，使用可用的最小权限，并避免在日志、报错和分析事件中记录完整凭据。定期检查发布产物与依赖设置，确认密钥没有意外进入浏览器。可靠的保护不是把钥匙藏得更巧，而是不把它交到不该持有它的地方。