Next.js security checklist

Next.js is the most popular React framework, powering App Router pages, Server Components, Server Actions, route handlers, and edge/Node middleware from one codebase. It blurs the client/server line on purpose — which is exactly what makes it fast to build with and easy to get wrong. Most AI-generated ‘full-stack’ apps you see today are Next.js under the hood.

Why Next.js apps get shipped insecure

The same file can run on the server or ship to the browser, so a single misplaced variable or missing auth check turns into a real exposure. AI coding tools happily add NEXT_PUBLIC_ to make a value ‘just work’ in a client component, and they scaffold Server Actions and route handlers without the auth checks the docs insist you add yourself. The framework’s power surface — middleware, actions, handlers — is also its attack surface.

The Next.js-specific footguns

• Secrets inlined into the browser bundle: any var prefixed NEXT_PUBLIC_ is baked into _next/static chunks at build time, so a NEXT_PUBLIC_STRIPE_SECRET or API key ends up publicly readable in the JS.
• Middleware auth bypass (CVE-2025-29927): before 15.2.3 / 14.2.25, an attacker sending the internal x-middleware-subrequest header skips your middleware entirely — including the auth/redirect gate you relied on.
• Server Actions treated as ‘internal’ functions: every ‘use server’ function is a public POST endpoint anyone can call with any payload, and AI-scaffolded actions routinely check auth on the page but not inside the action.
• Route handlers (app/api/*) with IDOR: handlers read an id from params or the body and query the DB with no ownership check, so /api/orders/123 returns someone else’s order.
• Server-only secrets pulled into client bundles: a shared util that reads process.env.DATABASE_URL gets imported by a ‘use client’ component, dragging the secret (or server logic) into the browser.

Next.js security checklist

1. Grep every NEXT_PUBLIC_ var and confirm none are secrets — anything sensitive must drop the prefix and stay server-side; rotate any key that was ever public.
2. Upgrade Next.js past the CVE-2025-29927 patch (15.2.3 / 14.2.25+) and strip the x-middleware-subrequest header at your proxy/edge as defense in depth.
3. Re-check auth and authorization inside every ‘use server’ action and every app/api route handler — never rely on the page or middleware alone.
4. Enforce object-level ownership on any handler that takes an id (params, query, or body) so users can’t read or mutate records they don’t own.
5. Add the ‘server-only’ package to modules holding secrets/server logic so a client import fails the build instead of leaking silently.
6. Run a free Trust scan — its Next.js route-extractor reaches your actual App Router pages, actions, and API handlers, plus a repo scan for leaked NEXT_PUBLIC_ keys and vulnerable deps.

Bottom line

Next.js gives you a server and a browser in one file, and AI tools blur that line to make things ‘work’. The wins are quick: keep secrets off NEXT_PUBLIC_, patch the middleware CVE, and put a real auth check inside every action and route handler. Trust’s Next.js-aware scan finds the leaks and unguarded routes before someone else does — free, no signup for the URL scan.