用 AI 写 API Route 时的安全清单：比「能跑」更重要的十项检查

为什么 AI 生成的 API 特别需要清单？

AI 擅长把「CRUD 骨架」写得很完整，也擅长漏掉安全边界：默认信任前端传来的 userId、把错误堆栈返回给客户端、用字符串拼接查询。这些在演示环境看不出来，上线后就是事故。

本文给出一份可直接贴进 Code Review 或 Skill 反模式区的检查清单，适用于 Next.js Route Handler、Express 等常见形态。

十项必检

1. 身份认证是否在业务逻辑之前？

未登录请求必须在读库、写库前被拒绝。不要先查数据再判断「有没有权限返回」。

2. 授权是否基于服务端会话，而非客户端声明？

禁止信任请求体里的 role: "admin" 或可伪造的 userId。以会话 / JWT 验签结果为准，再做资源归属校验。

3. 输入是否校验类型与边界？

对 body、query、params 使用 schema 校验（如 Zod）。拒绝未知字段、限制字符串长度、限制数组大小，降低注入与资源耗尽风险。

4. 是否存在注入面？

SQL / NoSQL / 命令行 / 路径拼接都要参数化或白名单。AI 常写出「方便调试」的字符串模板，Review 时重点盯。

5. 错误信息是否过度暴露？

生产环境返回通用错误码与安全文案；详细堆栈只写日志。不要把内部表名、SQL、文件路径回传前端。

6. 敏感数据是否过滤？

列表与详情接口默认排除密码哈希、token、内部备注。需要字段时显式 allowlist，而不是 SELECT * 后再「忘记删」。

7. 速率限制与滥用防护

登录、验证码、搜索、导出类接口应有限流。AI 脚手架几乎不会主动加；由人在网关或中间件补上。

8. CSRF / CORS 配置是否合理？

Cookie 会话接口注意 CSRF；跨域 API 不要用 * 配 credentials。确认预检与允许来源名单。

9. 幂等与重放

支付、发券、状态机推进类操作需要幂等键或状态校验，避免网络重试导致重复副作用。

10. 日志与审计

关键写操作记录谁、何时、改了什么（注意脱敏）。出事时没有审计日志，等于没有事后手段。

如何把清单嵌进 AI 工作流

写成 Skill 的反模式段

在团队 api-route Skill 中单列「禁止」条目，比事后口头提醒有效。写法参考 SKILL.md 格式指南。

PR 模板勾选

要求作者在 PR 描述勾选上述十项。未勾选不合并——比相信「模型应该知道安全」可靠。

自动化兜底

ESLint 自定义规则、依赖扫描、基础 SAST 能挡住一部分问题，但不能替代授权逻辑的人工审。

一个反例模式

「根据前端传来的 orgId 查询该组织全部用户」。若未校验当前用户是否属于该 orgId，就是典型越权。AI 常因「接口描述完整」而直接实现，正确性与安全性不是一回事。

与 RuleHub 内容的配合

安全相关 Skills、安全编码实践可在 RuleHub 搜索 中按 security、auth、zod 等关键词筛选；外部 Skill 仍需本地化到你的鉴权体系。行业动态见 AI 最新消息。

小结

用 AI 写 API 可以快，但安全审查不能快成形式主义。把十项检查固化进 Skill、PR 与发布门禁，才能在 VibeCoding 节奏下守住底线。

下一步：挑一个最近由 AI 生成的 Route，对照本清单走查一遍，把发现的问题写回团队 Rules 的「禁止」区。