Nextjs Security

Next.js Security

When to use

This skill is the Next.js-specific layer on top of secure-coding and api-security. Next.js has gone through several architectural shifts in recent years (Pages Router, App Router, Server Actions, middleware evolution), and the security implications shift with them. It is also used by teams that do not have a sharp line between front-end and back-end — and that is exactly where bugs live.

Triggers on:

• A question like "review our Next.js app", "CVE-2025-29927 impact", "make Server Actions safe", "auth.js/NextAuth config review", "middleware auth", "SSR is leaking data into the client bundle", "image optimization SSRF".
• Presence of next.config.js/.mjs/.ts, middleware.ts in the project root, an app/ directory with page.tsx and layout.tsx, pages/ (older router), "use server" or "use client" directives, NextAuth/auth.js config.
• A PR that touches middleware, adds Server Actions, converts API routes to Server Actions, or changes auth.js config.
• Next.js version bumps, especially around security releases.
• Handoff from security-review or api-security when Next.js is in the stack.

When NOT (handoff)

• General JS/TS secure-coding → secure-coding.
• OWASP API Top 10 as a conceptual framework → api-security. Here for the Next.js implementation.
• SAST tooling (eslint-plugin-security, Semgrep p/javascript) → sast-orchestrator.
• Dep vulns in package.json / package-lock.json → cve-triage.
• Vercel/Netlify deploy config and edge-network policies → iac-security where possible, otherwise platform-specific docs.
• Secrets in .env.local or Vercel env vars → secrets-scanner.

Approach

Seven phases. Phase 1 (middleware and auth-bypass) is the heart — that is where the CVE-2025-29927-class bug sat and where architectural misconceptions cause problems most often.

1. Middleware and auth-bypass

Next.js middleware runs before every matching request and is often used for authentication gates and redirects. That is precisely why it is an attack surface.

• CVE-2025-29927 ([verify against https://nextjs.org/blog] and https://github.com/vercel/next.js/security/advisories): An internal header that Next.js used for infinite-loop detection could be set externally, causing middleware to be skipped. Effect: middleware-based auth could be bypassed. Patched in 14.2.25, 15.2.3. Reviewer impact questions:

  • Are you running a version ≥ fix?
  • Was middleware your only auth layer for affected paths? If yes: anyone who could have gained access during the exposure window is an audit target.
  • Are there defense-in-depth auth checks at page or Server-Action level? If "no", this is a pattern-level fix, not just a version bump.

• More general middleware pattern: middleware is not a safe place for only auth. Defense-in-depth: also check auth in the page/route-handler/Server-Action. Middleware for redirects and header enforcement, not as the sole gate.

• Open redirects via middleware: return NextResponse.redirect(new URL(request.nextUrl.searchParams.get('next') ?? '/', request.url)) — if next is not validated, this is an open redirect. Allowlist destinations.

• Matchers: export const config = { matcher: '/admin/:path*' } — a too-narrow matcher does not protect what you thought it protected. Verify all sensitive paths are matched.

2. Server Actions: auth and CSRF

Server Actions ("use server") are RPC endpoints called from a Client Component but executing as server code. They share security concerns with API routes, plus a few of their own.

• Authentication in the Action itself, not only in the caller. An attacker can call your action hard-coded, bypassing your UI guard.

  'use server';
  export async function deletePost(id: string) {
    const session = await auth();         // do not skip
    if (!session) throw new Error('unauth');
    const post = await db.post.findUnique({ where: { id } });
    if (post.authorId !== session.user.id) throw new Error('forbidden'); // IDOR fix
    await db.post.delete({ where: { id } });
  }
  

• Input validation: Server Actions receive a FormData or directly-called args. Validate with zod/valibot/yup. Trust nothing that comes from the client.
• CSRF: Next.js protects Server Actions by default via same-origin checks and an action ID issued only by the server. Cross-origin POST to an action fails. But: that protection leans on the Origin and Host headers. Custom proxy setups can break this; verify Next.js' CSRF guard is still active behind your proxy.
• Rate-limiting: Next.js has no built-in rate limiter. Use Upstash/Redis/edge-config on the action path, or place auth-sensitive Actions behind a gateway that does rate-limiting.

3. Server/Client Component boundary and SSR data leaks

The App Router introduced Server Components and Client Components. The boundary is meaningful at runtime: what is in a Server Component does not end up in the client bundle, what is in a Client Component does.

• "use client" boundary: data passed as props into a Client Component lands in the client bundle or in the hydration payload. So: no secrets, no internal IDs, no password_hash, no other user's data that happened to come along in your query, no feature flags that competitors should not see.
• process.env in Client Components: only NEXT_PUBLIC_* vars are available. Anything else reads as undefined. That is the right default; but an accidentally renamed NEXT_PUBLIC_API_KEY leaks into the production bundle. Grep for NEXT_PUBLIC_ and confirm everything explicitly belongs in public.
• Hydration mismatch as a leak source: if server and client see different data (e.g. an admin flag), the hydrating client can show data in dev tools that it should not. Server-rendered state contains what you send.
• Route handler (app/api/.../route.ts) for Pages Router's API routes: treat as any other API endpoint (see api-security). Auth in the handler, not only in the UI.

4. auth.js (NextAuth) and session model

auth.js (rebranded from NextAuth v5) is the de facto auth library for Next.js.

• Session strategy: database or jwt. JWT strategy stuffs all session data into an encrypted JWT cookie — fast reads, no server-side invalidation. Database strategy has invalidation but requires a DB hit per request. The choice is a trade-off; the JWT default is reasonable for small apps, database for anything where logout really must invalidate.
• AUTH_SECRET must be cryptographically random (openssl rand -base64 32), in vault or env var, different per environment. See secrets-scanner.
• Providers: OAuth providers (Google, GitHub, etc.) use PKCE by default in auth.js v5. OK. Watch out for the Custom Credentials provider: you write the authorize function yourself, all credential validation is your responsibility. Verify password hashing (argon2id via the argon2 package or bcrypt), and timing-safe comparison.
• Callback-URL allowlist: pages.signIn etc. explicit. No dynamic redirect URL from a callbackUrl query param without an allowlist check.
• Session-cookie flags: auth.js sets HttpOnly, Secure (in prod), SameSite=Lax by default. Do not override unless necessary.

5. Image Optimization, file uploads, other SSRF vectors

• next/image with external sources: remotePatterns in next.config.js is the allowlist for where Next.js may fetch images. A wildcard hostname is effectively an image-proxy SSRF: someone loads /_next/image?url=<internal-URL> and uses your server to reach internal endpoints. Scope remotePatterns to your exact CDN/bucket domain. Canonical example of this class: [verify against CVE database and Next.js advisories — multiple image-proxy related CVEs have appeared].
• File uploads via Server Actions: FormData with File — validate server-side on content type, size, magic bytes. Client File.type is spoofable. Store outside public/ to prevent path traversal.
• Fetch in Server Components to user URLs: classic SSRF (see api-security phase 5). Block private IP ranges, DNS-rebinding protection.
• next/headers cookies/headers access: only in Server Components and Server Actions, not in Client Components. Well-guarded by default.

6. Security headers via middleware or next.config

Headers are configured in next.config.js headers() or in middleware.

// next.config.mjs
const securityHeaders = [
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
  { key: 'Content-Security-Policy', value: "default-src 'self'; script-src 'self' 'nonce-<nonce>'; ..." },
];

export default {
  async headers() {
    return [{ source: '/:path*', headers: securityHeaders }];
  },
};

• CSP with a nonce is recommended; Next.js documents the nonce pattern via middleware. Avoid 'unsafe-inline' and 'unsafe-eval' where possible — they largely null out CSP's XSS protection.
• HSTS with preload only if you are on the HSTS preload list or want to be. max-age at least 1 year for preload eligibility.
• Headers via middleware are more dynamic (per route) but heavier.

7. Misc and verification-loop

• dangerouslySetInnerHTML — React equivalent of |safe. Only on sanitized content, never directly on user input. Use DOMPurify or sanitize-html for user-generated HTML.
• eval, new Function, dynamic import(userString) — RCE vectors, never on user input.
• revalidatePath / revalidateTag from Server Actions — if the path parameter comes from user input, someone can manipulate your cache. Allowlist the paths.
• noindex on non-production via middleware or robots.txt, to keep staging out of Google by accident.

Verification-loop: Layer 1 (next.config, middleware, layout/page auth checks, Server Actions all walked through?), assumptions ("auth.js works by default" only if you have seen the actual config). Layer 2 (CVE-2025-29927 with fix versions checked against nextjs.org advisories, auth.js v5 API names correct, no invented Next.js version ranges in fix claims).

Output

Next.js security review — <app>
Next.js: <x.y.z> | Router: <App | Pages | mixed>
auth.js / NextAuth: <version, provider list>

Middleware:
  Present:               <yes/no>
  Auth via middleware:   <only layer | part of defense-in-depth>
  Matchers:              <scope>
  CVE-2025-29927 patched:<yes/no>
  Open redirects:        <list>

Server Actions (App Router):
  Number of actions:     N
  Auth check per action: <yes for all | gaps on ...>
  Input validation:      <zod/valibot/... | none>
  Rate-limited:          <yes/no>

Server/Client boundary:
  NEXT_PUBLIC_* exposure: <list, review>
  Secrets in Client props:<grep for password/token/key>
  Hydration leaks:        <visible in dev tools?>

auth.js:
  AUTH_SECRET source:    <vault/env>
  Session strategy:      <jwt | database>
  Providers:             <OAuth + PKCE | credentials + hashing scheme>
  Callback-URL allowlist:<yes/no>

next/image:
  remotePatterns scope:  <specific | wildcard — FINDING>

Security headers:
  HSTS:                  <on + preload>
  CSP:                   <nonce/hash | unsafe-inline — FINDING>
  Frame-Options:         <DENY/SAMEORIGIN>

Version check:
  Latest security release: <date>
  cve-triage handoff:      <N deps with vulns>

Findings (severity-sorted, follow security-review format)
Verification-loop: ...

References

• Next.js Security — https://nextjs.org/docs/app/building-your-application/configuring/content-security-policy and broader https://nextjs.org/docs.
• Next.js Security Advisories — https://github.com/vercel/next.js/security/advisories. Primary CVE source.
• Server Actions docs — https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations.
• auth.js (NextAuth v5) — https://authjs.dev/.
• React Security — https://react.dev/reference/react-dom/components/common#dangerously-setting-the-inner-html for dangerouslySetInnerHTML.
• OWASP Top 10 2021 — https://owasp.org/Top10/.
• CSP Reference — https://content-security-policy.com/. Useful CSP builder plus per-directive explanation.
• MDN Headers (HSTS, X-Frame-Options, etc.) — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers. Primary header reference.

Categories

• appsec