Many Next.js apps rely on middleware to protect routes - and quietly leave themselves exposed. Here's why middleware alone isn't enough (including a real 2026 CVE) and how to actually secure your app.
There's a security assumption baked into a huge number of Next.js apps, and it's a dangerous one: "I check auth in middleware, so my app is protected." It feels right - middleware runs before your pages, so surely it's the gatekeeper. But middleware alone is not a security boundary, and in 2026 there's a very public reason to take this seriously.
I'll show you exactly why relying on middleware leaves gaps, walk through a real vulnerability that let attackers skip it entirely, and lay out the layered approach that actually keeps your app secure.
Why middleware feels secure (but isn't)
Next.js middleware runs at the edge, before requests reach your pages, so it's a great place to redirect a logged-out user to the login screen. The problem is that this is a user-experience convenience, not a guarantee. Two things break the illusion:
- A cookie existing is not the same as a valid session. If your middleware just checks "is there a session cookie?", anyone can set a fake cookie in their browser and walk right past it. Presence is not proof.
- Middleware can be bypassed. That's not theoretical - see below.
The 2026 wake-up call: CVE-2025-29927
A critical vulnerability (CVE-2025-29927, CVSS 9.1) showed that attackers could completely bypass Next.js middleware authorization simply by adding a specially crafted x-middleware-subrequest header to their request. In other words, the exact layer many apps relied on for protection could be skipped with a single header.
It was patched (update to Next.js 14.2.25, 15.2.3, or later - do this if you haven't), but the lesson outlives the fix: if middleware is your only line of defense, a single bug in that layer exposes everything behind it. Never let one layer be the whole wall.
The two other places people get it wrong
Hiding UI on the client is cosmetic, not secure
Conditionally hiding an admin button based on the user's role is fine for UX, but it provides zero security. Anyone can read or modify client-side JavaScript, so a hidden button is still a reachable action. Client-side checks are polish, never protection.
Server Actions are public endpoints
It's easy to forget that a Server Action can be invoked directly, not just from the button you wired it to. That means every Server Action should authorize its own caller, exactly like a public API route would. Middleware won't save you here - it may not even run for that request.
The approach that actually works: defense in depth
The rule the Next.js team and security researchers keep repeating: put your authorization checks as close as possible to where the data is accessed. Use each layer for what it's good at.
1. Middleware - for UX, not security
Use it to redirect obviously logged-out users so they don't see protected pages flash. Treat it as convenience only.
export function middleware(req) {
const hasSession = req.cookies.get("session");
if (!hasSession) {
return NextResponse.redirect(new URL("/login", req.url));
}
return NextResponse.next();
}
2. A Data Access Layer - the real guarantee
Centralize a function that verifies the session on the server (not just its presence) and reuse it everywhere you touch sensitive data. Cache it per request so it's cheap to call repeatedly.
import { cache } from "react";
export const getCurrentUser = cache(async () => {
const session = await verifySession(); // validates the token server-side
if (!session) return null;
return getUserById(session.userId);
});
3. Server Components - re-verify before fetching sensitive data
const user = await getCurrentUser();
if (!user || user.role !== "admin") {
redirect("/login");
}
// only now fetch admin data
4. Server Actions & Route Handlers - authorize independently
export async function deleteUser(id) {
const user = await getCurrentUser();
if (user?.role !== "admin") throw new Error("Unauthorized");
// ...proceed
}
Each layer assumes the others might fail. That's the whole point - if middleware is bypassed, the Data Access Layer still refuses to hand over the data.
A quick security checklist for your Next.js app
- Update Next.js to a version patched against CVE-2025-29927.
- Validate the session on the server - never trust cookie presence alone.
- Re-check authorization in Server Components before fetching sensitive data.
- Authorize every Server Action and Route Handler independently.
- Treat client-side role checks as UX only.
Frequently asked questions
Is Next.js middleware secure for authentication?
Middleware is a useful first guard for user experience, but it is not a security boundary on its own. You must also verify authentication and authorization on the server, close to where data is accessed.
What was CVE-2025-29927?
A critical Next.js vulnerability that let attackers bypass middleware-based authorization using a crafted x-middleware-subrequest header. It's patched in recent versions, but it highlights why middleware shouldn't be your only defense.
Where should I put authorization checks in Next.js?
As close to the data as possible - in a Data Access Layer used by your Server Components, and inside each Server Action and Route Handler. Middleware handles redirects; these layers provide the actual guarantee.
Are client-side role checks safe?
No. Client-side checks only control what the UI shows and can be bypassed by anyone. Use them for convenience, never for security.
Not sure whether your Next.js app is actually secure or just looks it? Security gaps like these are exactly what I check and fix when building or auditing apps. Tell me about your project (https://osamahabib.com/contact) and I'll help you lock it down properly.
Osama Habib
Multan, Pakistan
Full Stack Developer specialising in Next.js, Node.js, and the MERN stack. I write about modern web development, system design, and practical engineering.
