Auth.js

Applies when the project uses Next.js. In March 2025, Next.js disclosed that a single request header could make a self-hosted app skip its middleware entirely. Any sign-in check that lived only in middleware was skipped with it. Apps run with next start or output: 'standalone' were affected. Vercel, Netlify and Cloudflare Workers were not. Clerk first said on X that no Clerk app was affected, and retracted that in a post on 23 March: apps were exposed if middleware was their only check on a route, or if they ran @clerk/nextjs older than 5.2.

The lesson outlived the patch. Vercel’s post-mortem says it does not recommend middleware as the sole method of protecting routes. Auth.js’s documentation says not to rely on it exclusively, and to verify the session as close to the data as possible. Since Next.js 16 the file is called proxy.ts; the advice is the same.

• Check the session in the page, route handler or server action that reads the data, not only in middleware or proxy.ts. With Clerk that means calling auth(), currentUser() or protect() there; with Auth.js, auth().
• Treat middleware as an early redirect, not as the check itself. A route that is safe only because middleware ran is not safe.
• Keep next on a supported, patched release. The fixes were 15.2.3, 14.2.25, 13.5.9 and 12.3.5.

• Set the auth secret in production and never change it casually. Changing it invalidates every session and signs everybody out.
• Behind a proxy or a platform host, set the trusted host and canonical URL explicitly. A wrong callback URL breaks sign-in only in production.
• Choose session strategy deliberately. A JWT session cannot be revoked on the server before it expires; a database session can.