Auth in middleware that skips API routes

Protecting pages in middleware or proxy is not the same as protecting /api Route Handlers or Server Functions. Next.js documents that a Proxy matcher which excludes a path also skips Server Function calls on that path, and that authentication and authorization have to be verified inside each Server Function. A login redirect on /dashboard does not run for a request the matcher never selected.

Current Next.js docs call this file proxy.ts and the exported function proxy. The proxy reference says the middleware file convention is deprecated and has been renamed to proxy. Apps that have not migrated still use middleware.ts. The matcher behavior below is the same either way. The backend-for-frontend guide says third-party libraries may still refer to proxy as middleware. Supabase's Next.js server guide splits the filename by version: Next.js renamed the file in version 16. On Next.js 15 and earlier a proxy.ts file is never called, so the session never refreshes and users get signed out. Before that rename the file is middleware.ts and the function is middleware.

The proxy reference's negative-matching example skips API routes, static files, and metadata:

'/((?!api|_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)'

The comment on that example says the pattern matches every path except ones starting with api, _next/static, _next/image, and the named metadata files. Copying that snippet into an auth proxy is how an app "protects the app" and leaves /api/* with no proxy at all. A matcher that only lists page paths, such as ['/dashboard/:path*', '/app/:path*'], does the same thing to every route that is not on the list. The docs also say that without a matcher, proxy runs on every request, including static files, and that excluding _next/static and images keeps an auth redirect from blocking CSS and JavaScript. That is a reason to skip assets. It is not a reason to skip the API when the proxy is your only gate.

Server Functions are not their own routes. Next.js handles them as POST requests to the route where they are used. If the matcher excludes that page path, Proxy does not see the POST. The proxy reference says a matcher change, or a refactor that moves a Server Function to a different route, can silently remove Proxy coverage, and that you should always verify authentication and authorization inside each Server Function rather than relying on Proxy alone. The data security guide says a page-level authentication check does not extend to the Server Actions defined within it, and that you re-verify inside the action. The same guide's audit list calls out proxy.ts and route.ts as files with a lot of power.

The backend-for-frontend guide shows the other matcher shape when the proxy is meant to gate the API: matcher: '/api/:function*', returning 401 when the request is not authenticated. That guide's access section says to always verify credentials before granting access, and not to rely on proxy alone for authentication and authorization.

OWASP's authorization cheat sheet says permission has to be validated on every request, including one that did not come from your UI, and that a client-side check is not the decisive one. A matcher that never selects /api is a request the proxy does not validate.

This is a different bug from CVE-2025-29927. The Next.js advisory GHSA-f82v-jwr5-mffw describes an authorization bypass when the check lives in middleware, and the advisory page identifies it as CVE-2025-29927. The patched releases it lists are 12.3.5, 13.5.9, 14.2.25, and 15.2.3. For Next.js 11.x the advisory points at the workaround instead of a patched release. It says deployments hosted on Vercel are automatically protected, and that if you cannot upgrade yet you should stop external requests carrying the x-middleware-subrequest header from reaching the app. Upgrade a self-hosted app that is still on an affected version. After that upgrade, a matcher that never included /api is still open, because the proxy was never asked to run there.

export async function GET() {
  const session = await auth();
  if (!session) {
    return Response.json({ error: "Unauthorized" }, { status: 401 });
  }
  // scope the query to session.user.id
}

You are closing a middleware or proxy matcher gap. Do not add features.

1. Open middleware.ts or proxy.ts and read config.matcher. List every path the matcher does not cover, especially /api and any page path that uses a Server Function.
2. Open every app/api/**/route.ts file. If the handler reads or writes data and does not load the session itself, add that check and return 401 before the query. Ignore userId, role, and isAdmin from the request.
3. Open every "use server" export. Load the session inside the function. Do not treat a layout redirect or a matcher as the check.
4. If a matcher is the only gate for an API path, either include that path in the matcher or add the in-handler check. Keep the in-handler check either way.
5. If this app uses Supabase, create the user-scoped client from the request cookies inside the handler. Do not switch those calls to the secret key.

Do not add a login page, a new role system, or a referral link. List each handler and the check you added.