用 AI 写 Next.js 代码最可怕的地方在于
有个安全研究员分享过一个 67 行的 Demo App，AI 给出的代码里居然同时包含了硬编码的 JWT 密钥、过时的 MD5 密码哈希、永不过期的 Token，甚至还有 XSS 漏洞和完全缺失的频率限制。最阴险的是，这个 App 运行起来非常流畅，没有任何报错，如果你不是安全专家，根本看不出它是个“筛子”。
这其实揭露了 AI 编程的一个底层逻辑：它学习的是“最常见”的模式，而不是“最安全”的模式。在 Stack Overflow 或各种快速上手教程里，为了方便演示，开发者往往会把 Token 存 localStorage，或者只在中间件做一次简单的 session 检查。AI 吸收了这些习惯，当你让它“加个登录功能”时，它给你的是一个“能跑通且最流行”的方案，而不是一个“工业级安全”的方案。
尤其在 Next.js 这种服务端和客户端代码混在一起的框架里，一个细小的错误就可能把敏感密钥直接发给浏览器。我总结了一套针对 AI 生成代码的审查清单，大家在 Review 时可以对着过一遍。
一、 别把中间件当成安全防火墙
这是目前最容易踩的坑。AI 特别喜欢在 middleware.ts 里写鉴权逻辑，因为这样写最快，而且在大多数教程里都是这么教的。但实际上，中间件更像是一个 UX 层的路由分发，而不是真正的安全边界。
在 2026 年的一系列 CVE 漏洞中（比如 CVE-2025-29927 和 CVE-2026-44574），攻击者可以通过构造特殊的 x-middleware-subrequest 请求头或者利用动态路由参数注入，直接绕过中间件。甚至 Next.js 16 已经把 middleware.ts 重命名为 proxy.ts，就是为了在语义上提醒开发者：这只是个代理层，别把它当成唯一的安全门。
❌ 典型的 AI 错误模式（仅在中间件拦截）：
// proxy.ts (或 middleware.ts)
export function proxy(request: NextRequest) {
// AI 习惯在这里做唯一的拦截
const token = request.cookies.get('session')?.value
if (!token) return NextResponse.redirect(new URL('/login', request.url))
return NextResponse.next()
}
// 潜在风险：如果攻击者绕过了 proxy 层，下面的 Route Handler 毫无防备✅ 正确的实践（在数据层强制校验）：
中间件可以做快速的 UX 跳转，但每一个 Route Handler 和 Server Action 必须在数据访问层独立验证身份。
// app/api/orders/route.ts
import { verifySession } from '@/lib/auth'
export async function GET() {
// 必须在这里进行加密校验，不能依赖上层 proxy
const session = await verifySession()
if (!session) return new Response('Unauthorized', { status: 401 })
// 此时使用 session.userId 才是安全的
const orders = await getOrdersForUser(session.userId)
return Response.json(orders)
}验证方法： 检查每一个受保护的路由，问自己一个问题：“如果有人绕过了 proxy 直接访问这个接口，他还能进去吗？”如果答案是肯定的，那就得赶紧改。
二、 警惕 "use server" 带来的公共接口风险
AI 经常把 Server Actions 当成普通的内部函数来调用，但事实上，每一个标注了 "use server" 的函数在部署后，本质上都是一个公开的 POST 接口。
很多 AI 生成的代码在 Server Action 内部直接操作数据库，却忘记了验证当前请求的用户是否有权操作该资源。比如 AI 可能会写一个 updateOrder(orderId, data) 的函数，它只检查了用户是否登录，但没检查这个 orderId 到底是不是属于这个用户。这意味着任何登录用户只要猜到 orderId，就能修改别人的订单。
建议审查点：
- 权限校验： 每一个 Server Action 内部是否都包含了
where: { id: orderId, userId: currentUser.id }这样的所有权检查？ - 输入验证： AI 是否对传入的参数做了 Zod 校验？不要直接把
formData扔进数据库。 - 频率限制： 关键操作（如发送邮件、扣款）是否加了 Rate Limit？AI 几乎永远不会主动为你添加频率限制。
对于习惯了 AI 编程的人来说，最关键的转变应该是：不要把 AI 给你的代码当成“最终方案”，而要把它当成一个“需要被审计的草稿”。 只要代码能跑通，就意味着它已经通过了功能测试，但它离通过安全测试还差得很远。
