我在 Next.js 16 中犯了三个代价高昂的身份验证错误
我在三个不同的项目中搞砸了 proxy.ts 的 matcher。
最糟糕的是？没有任何错误，没有警告，也没有日志。在安全漏洞出现之前，一切看起来都非常完美。
Next.js 16 将 middleware.ts 改为了 proxy.ts。这不仅仅是名称的变更，更是处理请求方式的根本转变。
为了避免破坏你的身份验证机制，以下是你必须了解的内容。
新规则 Middleware（中间件）曾让人困惑。开发者常将其用于数据库调用和繁重的逻辑处理，但这并不是它的职责。
Proxy（代理）位于网络边界。它在请求到达你的路由之前对其进行拦截。
- 默认运行在 Node.js 上，而非 Edge runtime。
- 你可以获得完整的加密（crypto）支持。
- 你可以使用任何标准的 JWT 库，无需任何变通方案。
静默失败
如果你在升级 Next.js 时没有使用 codemod，旧的 middleware.ts 文件可能会留在你的项目中。它能通过 TypeScript 检查，也能正常编译。
但它将毫无作用。
你的重定向不会触发，身份验证也不会运行。你的应用会直接静默地绕过安全层。
请手动检查以下三项：
- 确保
proxy.ts位于项目根目录。 - 确保导出的函数名为
proxy，而不是middleware。 - 完全删除旧的
middleware.ts文件。
Matcher 陷阱 大多数身份验证配置都会在 matcher 配置中出错。如果你没有排除静态文件，proxy 会在每个 CSS 和 JS 文件上运行。这会导致资源文件出现无限重定向循环。
使用负向先行断言（negative lookahead）来排除：
_next/static_next/image- favicon 和 sitemaps
- 图片扩展名 (png, jpg, svg)
警告：不要仅信任 Header 这就是我栽跟头的地方。
Proxy 会在请求上设置类似 x-user-id 的 header。你的 Server Components 通过 headers() 读取这些内容。
如果你的 matcher 存在漏洞，用户可以发送自己的 x-user-id header。Server Component 无法区分 proxy 设置的 header 和客户端发送的 header。
攻击者可以在未匹配的路由上伪造用户 ID。他们可能看不到数据，但可能会获得他们不应拥有的权限。
解决方案： Proxy 是你的快速关卡。它在边缘端处理繁重的工作。
但你必须在 Server Components 内部再次验证 JWT。
- 代理服务器可以快速拦截大多数恶意攻击者。
- 如果匹配器失效，服务端组件检查可以弥补这一漏洞。
冗余即安全。