洋芋头的站

虽然我们目前的项目大多不涉及海量的敏感隐私数据，但别忘了，几乎所有接入大模型（AI）的项目，后端调用的第三方 API 都是真金白银的支出。如果你的接口被恶意刷取，损失的是课题组的经费，抑或是你自己的钱包。为了这“三分两毛钱”的积少成多，我们也必须构建起稳固的防御体系。

简单来说，网络安全的核心需求只有一点：确保你的接口是被“正确的人”在“正确的时间”以“正确的频率”调用。

一个典型的 AI 转发逻辑通常如下：

接收前端发来的用户消息。
解析 JSON 字符串，映射拼接进 Prompt（提示词）。
后端将 Prompt 发送给第三方 API（如 OpenAI, Claude 等）。
处理返回内容并推送到用户端。

下面我将按照安全等级，从低到高为大家科普我们应该如何保护我们的应用。

零级安全：裸奔时代（⭐）

行为： 将 API Key 直接硬编码在前端代码中。 代价： 任何用户只需“右键 -> 检查 -> 网络/源代码”就能拿走你的 Key。他可以绕过你的界面，直接盗用你的额度去跑他自己的任务。 结论： 绝对禁止将任何敏感 Key 放在前端。Key 必须存储在后端环境变量或配置文件中。

基础安全：后端的护城河（⭐⭐）

行为： API Key 移至后端。用户通过“用户名+密码”登录，前端获取 Token 后，后续请求带上 Token。 现状： 虽然 Key 安全了，但如果仅止于此，风险依然巨大：

Token 永不过期： 如果用户 Token 被截获，对方可以永久调用你的接口。
登录即无敌： 只要登录了，用户可以一秒钟调用一千次接口。

改进方案：

Cookie 自动过期与 Token 刷新： 必须给会话设置有效期。即便 Token 被盗取，其危害时间也有限。
防止 Token 盗取： 关键信息不要存在 LocalStorage（易受 XSS 攻击），尽量使用 HttpOnly 的 Cookie。

中级安全：行为风控（⭐⭐⭐）

即使对方是合法用户，我们也需要防止其“非正常使用”。

请求频率限制（Rate Limiting）：
- 痛点： 某个同学写了个脚本，一秒钟给你的后端发 100 个请求，你的 API 额度瞬间归零。
- 对策： 在后端加入限流逻辑（如每分钟只允许请求 10 次）。
IP 验证与设备验证：
- 痛点： 账号泄露给校外人员。
- 对策： 记录用户常用的 IP 段和设备指纹。如果用户突然从异地登录，或同一账号在 10 台设备登录，应强制重新验证身份。

高级安全：防微杜渐（⭐⭐⭐⭐）

针对一些可能改变系统状态或耗费大量额度的关键操作，我们需要更精细的处理。

重要操作二次密码验证：
- 比如修改个人资料、清空对话历史，或者调用昂贵的 O1/Claude-3.5-Opus 模型时，可以要求用户再次输入密码或验证码。
防重放攻击（Anti-Replay）：
- 原理： 黑客截获了你的一次合法请求包，即使他不知道你的 Token，也可以原封不动地把这个包反复发给服务器。
- 对策： 在请求中加入时间戳（Timestamp）和随机字符串（Nonce）。服务器校验该请求是否在合理时间内，且该随机串是否已使用过。

终极安全：业务逻辑闭环（⭐⭐⭐⭐⭐）

安全不仅是技术问题，更是业务逻辑设计问题。

用户额度配置（Quota Management）：
- 不要提供“无限量”服务。给每个用户设置每日/每月额度上限。
- 根据用户角色（比如老师、研究生、本科生）分配不同的 API 调用权重。
敏感词过滤：
- 防止用户利用你的 API 产生违规内容，导致你的 API 账号被官方封禁。

总结：我们该怎么做？

网络安全不是一蹴而就的，而是一个不断博弈的过程。对于我们课题组内部的项目，我建议大家遵循以下底线：

Key 绝不下前端： 这是底线。
必须有登录态： 拒绝一切匿名调用。
必须有限流： 宁可让用户报错等待，也不能让钱包一夜清空。
分级授权： 昂贵的模型（如 GPT-4）和便宜的模型（如 GPT-4o-mini）要分开配置额度。

安全开发不仅仅是为了保护数据，更是为了保护我们有限的科研经费。希望大家在提交代码前，都能多想一步：如果我是黑客，我能绕过这个逻辑吗？

（完）