nextjs-security

Next.js Security

Next.js moves fast and its security model has shifted with every major version. The most common failure mode is reaching for a familiar pattern from a year ago that no longer holds — middleware-only auth, naive Server Actions, NEXT_PUBLIC_ env handling. This skill is the spot-check list.

Tested patterns target App Router on Next.js 14+; most apply to 15/16 too. Pages Router callouts are marked.

When to invoke

• New Next.js app heading to production
• Major version upgrade (13 → 14 → 15 → 16)
• Adding authenticated routes, Server Actions, or new middleware logic
• Investigating an incident or suspicious request pattern
• Code review for an inherited Next.js codebase

1. Middleware is not authoritative auth

Middleware runs on every matched request, but it is a network-edge thing — not a substitute for per-route authorization. Treat middleware as a performance optimization for redirects and headers, not as a security boundary.

The 2025 middleware bypass class (CVE-2025-29927-style) showed that header smuggling can skip middleware entirely on misconfigured setups. Patch your Next.js to the fixed version and assume the bypass is possible — every protected route still re-checks auth server-side.

// app/admin/page.tsx — every protected route does its own check
import { redirect } from 'next/navigation';
import { getSession } from '@/lib/session';

export default async function AdminPage() {
  const session = await getSession();
  if (!session || session.role !== 'admin') redirect('/login');
  // ... render
}

For Server Actions specifically, re-validate inside the action:

'use server';
export async function deletePost(id: string) {
  const session = await getSession();
  if (!session) throw new Error('unauthenticated');
  if (!canDelete(session.userId, id)) throw new Error('forbidden');
  // ... mutate
}

A Server Action is callable from any client that knows the action ID; middleware only sees the request, not the action target.