Cometi Três Erros de Autenticação Caros com Next.js 16
Eu errei o matcher do proxy.ts em três projetos diferentes.
A pior parte? Não houve erros. Nem avisos. Nem logs. Tudo parecia perfeito até que surgiram brechas de segurança.
O Next.js 16 mudou o middleware.ts para proxy.ts. Isso não é apenas uma mudança de nome. É uma mudança fundamental na forma como você lida com as requisições.
Aqui está o que você precisa saber para evitar quebrar sua autenticação.
As Novas Regras O middleware era confuso. Desenvolvedores o utilizavam para chamadas de banco de dados e lógicas pesadas. Esse não é o papel dele.
O proxy fica na fronteira da rede. Ele intercepta as requisições antes que elas cheguem às suas rotas.
- Ele roda no Node.js por padrão, não no Edge runtime.
- Você tem suporte total a crypto.
- Você pode usar qualquer biblioteca JWT padrão sem gambiarras.
A Falha Silenciosa Se você atualizar o Next.js sem usar um codemod, seu antigo arquivo middleware.ts pode permanecer no seu projeto. Ele passará nas verificações do TypeScript. Ele compilará normalmente.
Mas ele não fará nada.
Seus redirecionamentos não serão acionados. Sua autenticação não será executada. Seu app simplesmente ignorará a camada de segurança silenciosamente.
Verifique estas três coisas manualmente:
- Certifique-se de que o proxy.ts está na raiz do seu projeto.
- Certifique-se de que a função exportada se chama proxy, não middleware.
- Exclua o antigo arquivo middleware.ts completamente.
A Armadilha do Matcher A maioria das configurações de autenticação quebra na configuração do matcher. Se você não excluir os arquivos estáticos, o proxy rodará em cada arquivo CSS e JS. Isso cria loops infinitos de redirecionamento nos assets.
Use um negative lookahead para excluir:
- _next/static
- _next/image
- favicons e sitemaps
- extensões de imagem (png, jpg, svg)
Aviso: Não confie apenas nos Headers Foi aqui que eu me queimei.
O proxy define headers como x-user-id na requisição. Seus Server Components leem esses valores via headers().
Se o seu matcher tiver uma brecha, um usuário pode enviar seu próprio header x-user-id. O Server Component não consegue distinguir entre um header definido pelo proxy e um header enviado pelo cliente.
Um invasor poderia falsificar um ID de usuário em uma rota não correspondente. Eles podem não conseguir ver dados, mas poderiam ganhar permissões que não deveriam ter.
A Solução: O proxy é o seu portão rápido. Ele cuida do trabalho pesado no edge.
Mas você deve verificar o JWT novamente dentro dos seus Server Components.
- O proxy bloqueia a maioria dos agentes maliciosos rapidamente.
- A verificação do Server Component fecha a lacuna caso o matcher falhe.
Redundância é segurança.