API安全前端开发后端代理密钥保护

前端直调 AI API 会泄露 Key 吗？安全后端代理改造指南

2026-09-13 · 约 9 分钟阅读

为了快速做出聊天页面，很多项目会在 React、Vue 或小程序里直接请求 AI API。功能确实能跑，但只要长期凭证进入浏览器，就不能再把它当作秘密：构建产物、网络请求、源码映射、浏览器扩展和错误日志都可能暴露它。把变量命名为 NEXT_PUBLIC_API_KEY、混淆 JavaScript，或者将字符串拆成几段，都不能改变这个安全边界。

正确方案不是“把 Key 藏得更深”，而是让浏览器只持有用户会话，真正的 AI API Key 只存在于受控服务端。本文是一套不依赖具体模型版本与价格的常青改造方法。

安全调用链应该长什么样

推荐链路是：浏览器登录业务系统，携带短期会话访问你的 /api/chat；服务端验证身份、配额与输入后，再使用保存在服务端密钥系统中的凭证请求官方 API 或 AI API 中转站。

浏览器不需要知道上游 Key，也不应该允许用户自由指定任意 baseURL。服务端应控制可用模型、最大输出、超时和工具权限。这样即使用户检查网络请求，也只能看到自己的业务令牌。

Next.js 后端代理最小示例

下面示例强调安全边界，模型名和中转地址都由服务端配置：

// app/api/chat/route.ts
export async function POST(req: Request) {
  const user = await requireUser(req);
  await assertQuota(user.id);

  const body = await req.json();
  const messages = validateMessages(body.messages);

  const upstream = await fetch(`${process.env.AI_BASE_URL}/chat/completions`, {
    method: "POST",
    headers: {
      "content-type": "application/json",
      authorization: `Bearer ${process.env.AI_API_KEY}`,
    },
    body: JSON.stringify({
      model: process.env.AI_MODEL,
      messages,
      stream: true,
      max_tokens: 1200,
    }),
    signal: AbortSignal.timeout(60_000),
  });

  if (!upstream.ok || !upstream.body) {
    return Response.json({ error: "upstream_failed" }, { status: 502 });
  }

  return new Response(upstream.body, {
    headers: { "content-type": "text/event-stream" },
  });
}

生产环境还要检查上游响应类型，过滤不必要的响应头，并在客户端断开时取消上游请求。不要把上游错误原文全部回传，因为其中可能包含请求摘要、供应商标识或内部地址。

代理层必须补上的五道门

1. 用户鉴权

“Key 在后端”不等于接口安全。若 /api/chat 对公网匿名开放，攻击者仍能借你的服务器消耗余额。至少验证登录会话；开放产品还应加入验证码、设备风控或匿名额度。

2. 用户级配额

限流维度不能只有 IP。公司网络、移动出口和恶意代理都会让 IP 失真。建议同时按用户、租户、接口与模型建立分钟级并发限制和日预算。超过预算时返回稳定的业务错误码，而不是继续透支。

3. 输入与参数白名单

不要直接透传前端提交的 model、max_tokens、tools 和 base_url。前端可以传业务场景，例如 summary；服务端再将它映射到经过批准的模型策略。工具调用尤其要采用明确白名单，避免模型获得未授权能力。

4. 日志脱敏

日志保留 request ID、用户 ID 哈希、路由、耗时、状态与用量即可。不要记录 Authorization 头；Prompt 和响应也不应默认全文落盘。若排障确需采样，应设置访问权限、保留期限和删除机制。

5. 来源与跨站请求保护

Cookie 会话需要 CSRF 防护，并校验 Origin。CORS 不是鉴权机制，只是浏览器策略；服务端仍须验证请求身份。不要用通配符来源同时允许携带凭证。

已经泄露后怎么处理

发现 Key 曾经进入 Git、前端包或截图时，不要只删除文件。正确顺序是：立即撤销旧 Key、创建权限更小的新 Key、检查异常用量与调用日志、清理 CI 和托管平台变量、更新服务端配置，最后再复盘泄露路径。Git 历史中的秘密不会因为最新提交删掉一行就自动消失。

上线验收清单

浏览器构建产物与网络面板中没有上游长期凭证
未登录、越权和超额请求都会被拒绝
模型、输出长度、工具和上游地址由服务端白名单控制
客户端取消能够传递到上游
日志、告警和错误响应不包含密钥或完整敏感内容
Key 可独立轮换，且无需重新发布前端

总结

前端直调 AI API 的核心问题不是框架，而是浏览器属于不可信执行环境。将长期 Key 移到后端只是第一步，用户鉴权、配额、参数白名单、脱敏和取消传播必须一起完成。上线后还应定期演练密钥轮换与异常用量告警，确认应急流程真正可执行。准备选择支持流式转发、配额管理和稳定线路的平台时，可前往 openairouter.net 查看 AI API 中转站对比与排行榜，再用本文清单完成接入验收。