Next.js: common security mistakes in Server Components applications

Next.js App Router: powerful but treacherous

Since the massive adoption of Next.js App Router and Server Components in 2025-2026, we observe a new category of vulnerabilities specific to this architecture. The server/client boundary in the same file creates an attack surface that many developers underestimate.

Mistake 1: Server Actions exposed without validation

Server Actions are server functions callable directly from the client. The problem: they are automatically exposed as POST endpoints. If you don't validate inputs and permissions server-side, any user can call the action with arbitrary parameters.

We regularly find Server Actions that modify sensitive data without verifying the connected user has the right to perform that operation. The fact that the action lives in a UI-protected component changes nothing — the endpoint is public.

Mistake 2: Insecure data fetching in Server Components

Server Components fetch data directly on the server. The common mistake: trusting URL parameters without validation. A component that does fetch(/api/users/${params.id}) without verifying the connected user has rights to this ID is vulnerable to IDOR (Insecure Direct Object Reference).

Worse: some developers pass sensitive data through Client Component props, thinking the Server Component filters them. In reality, these props are serialized into the HTML and visible in the page source.

Mistake 3: API Route authentication gaps

Next.js API Routes (route.ts files) are often created without authentication middleware. Unlike Express where global middleware is common, each Next.js API Route is independent. Result: forgotten endpoints with zero protection.

We find GET routes returning complete user lists, PUT routes modifying configurations without role checks, and DELETE routes accessible to any authenticated user.

Mistake 4: Middleware bypass

Next.js middleware (middleware.ts) is meant to protect routes. But it runs at the Edge level and cannot directly access the database. Many developers add JWT verification there but forget to re-verify permissions in Server Components or API Routes.

Moreover, middleware doesn't apply to Server Actions by default. A middleware protecting /admin/* doesn't block a Server Action defined in a file under /admin/.

Mistake 5: Exposed environment variables

Next.js distinguishes server variables (process.env.SECRET) from client variables (NEXT_PUBLIC_*). But naming mistakes expose secrets. We find API keys, service tokens, and session secrets in the client JavaScript bundle because the developer mistakenly prefixed with NEXT_PUBLIC_.

How we detect these flaws

Our external review analyzes the client JavaScript bundle, response headers, and exposed endpoints. We identify unprotected Server Actions, unauthenticated API Routes, and misconfigured environment variables. Full report within 48h.