Secure a Next.js App Generated by AI

Direct answer: Treat every callable Server Action and Route Handler as an API. Keep secrets and database access in server-only modules, authenticate and authorize close to the data source, validate every argument, return minimal data-transfer objects, and test endpoints directly as signed-out, allowed, and cross-account callers. Proxy, hidden buttons, and Server Components do not replace resource authorization.

Next.js App Router data-security, authentication, Proxy, and environment-variable guidance was reviewed against official documentation on July 17, 2026. The current Next.js documentation uses Proxy for the feature previously called Middleware.

AI-generated Next.js code can look safer than it is because server and client code share one project and similar syntax. A function marked "use server" does run on the server, but its request arguments remain untrusted. A Server Component can keep a secret operation off the browser, yet still fetch another tenant’s record. Proxy can redirect a signed-out user while a Route Handler remains callable directly.

The vibe coding security guide recommends mapping the trust boundary before reviewing individual lines. In Next.js, start with every path that can reach server data or a side effect.

Inventory every callable server entry

List Route Handlers, Server Actions, Server Functions, authentication callbacks, webhooks, cron routes, file uploads, and server-rendered data loaders. For each entry, record:

1. how the caller is authenticated;
2. which resource and action are authorized;
3. how input is parsed and bounded;
4. which server-only function reaches the data source;
5. which fields enter a response or Client Component;
6. which negative tests cover the path.

Next.js documentation says exported Server Actions are reachable as HTTP endpoints when the application makes them callable. Current builds remove unused actions, but dead-code elimination is not an access-control strategy. Route Handlers are plainly APIs. Apply the same authentication, authorization, validation, rate, and error rules to both.

The risky pattern: authorization in the page only

Vulnerable pattern. The page hides the form from non-admins, but the action trusts a client-supplied workspace.

"use server"

export async function inviteMember(formData: FormData) {
  const workspaceId = String(formData.get("workspaceId"))
  const email = String(formData.get("email"))

  await db.invitation.create({ data: { workspaceId, email } })
}

The surrounding Server Component may render this form only after an administrator check. That does not bind the later request to the authorized workspace. A caller can submit the action with a different identifier.

Generated code often misses this because the model follows component flow. It sees that an admin-only page supplies workspaceId and treats the value as established. It does not automatically model a direct HTTP call, a stale tab after role removal, or a copied identifier from another tenant.

Centralize secure data access

Next.js recommends a server-only data access layer for projects with sensitive data. Authenticate inside that layer or pass a verified user context, authorize the actual resource, and return a narrow data-transfer object.

import "server-only"
import { z } from "zod"

const inviteSchema = z.object({
  workspaceId: z.string().uuid(),
  email: z.string().email().max(254),
})

export async function inviteMember(input: unknown) {
  const value = inviteSchema.parse(input)
  const user = await requireUser()

  const membership = await db.workspaceMember.findFirst({
    where: {
      workspaceId: value.workspaceId,
      userId: user.id,
      role: "ADMIN",
      status: "ACTIVE",
    },
    select: { workspaceId: true },
  })

  if (!membership) throw new Error("Not found")

  await createInvitation({
    workspaceId: membership.workspaceId,
    email: value.email,
    invitedById: user.id,
  })

  return { accepted: true }
}

The example establishes one active-admin rule. Production code still needs duplicate handling, invitation expiry, rate limits, audit records, email side-effect retries, and a decision about the final owner. Return a generic denial if distinguishing missing from forbidden resources would leak existence.

The server-only import creates a build-time guard against importing the module into client code. It does not authenticate requests. A database module that imports server-only can still query too broadly.

Keep authorization near the data source

Proxy is useful for optimistic checks such as redirecting an obviously signed-out browser. It should not be the only gate. Current Next.js authentication guidance advises against relying on Proxy for all authorization because it runs on every matching request and may not sit beside the resource decision.

Layouts are also a weak place for the final check. Partial rendering can leave a layout from an earlier navigation in place. Check authorization in the Page, Server Action, Route Handler, or data access operation that needs it.

Avoid duplicating subtly different role logic across components. A small policy function can answer a typed question such as canInviteMember(user, membership). Still load current server state before calling it. A role from local storage, form data, or an unsigned cookie is not trusted input.

Minimize the server-to-client boundary

React Server Components can query data without shipping the query code to the browser. The returned props can still become client-visible. Do not pass a whole user, workspace, billing, or provider object to a Client Component when it needs three fields.

type WorkspaceSummary = {
  id: string
  name: string
  canInvite: boolean
}

Create the DTO after authorization. Exclude password hashes, private notes, provider tokens, internal flags, raw session objects, and unrelated tenant fields. Review serialized page data, Route Handler JSON, error payloads, source maps, and logs.

For environment variables, Next.js bundles NEXT_PUBLIC_ values for the browser. Keep truly secret values unprefixed and access them only from server-only modules. A server variable also becomes public if code returns it to a Client Component or response.

The browser-local security headers checker can review response headers for a public URL. It cannot inspect Server Actions, Route Handler authorization, environment variables, or data returned after login.

Test entries directly, not only through the UI

Use an authorized local or test environment and disposable accounts.

1. Call each sensitive Route Handler and Server Action without a session. Expect a denial.
2. Perform the intended action as Account A.
3. Reuse Account A’s resource ID as Account B. Expect denial for read, update, delete, export, upload, and invitation paths.
4. Remove or downgrade A, then repeat from an existing tab and direct request.
5. Send missing, malformed, oversized, duplicated, and unexpected fields.
6. Confirm errors omit secrets, provider responses, stack traces, and other tenant data.
7. Verify production headers, cookies, callback origins, and environment configuration separately.

Do not use broad scanners against systems you do not own. A negative test should have a specific expected result and safe fixture. If a finding is corrected, rerun the same request on the new build rather than relying on the fact that TypeScript compiles.

Isolate callbacks, webhooks, and scheduled routes

Not every Route Handler has a user session. OAuth callbacks, provider webhooks, and scheduled jobs need their own authentication contract. Verify OAuth state and callback origins. Verify a webhook signature over the exact raw body, reject stale or replayed events, and make side effects idempotent. Protect scheduled routes with a server-held credential or platform identity and a narrow method.

Do not remove authentication from a shared handler because an external provider cannot send the application’s cookie. Give the provider a dedicated route and verification method. Keep its request schema and permissions narrower than a user-facing API. If it uses an administrative database client, authorize the event’s account mapping before changing tenant data.

Test these routes with a missing signature, altered body, stale timestamp, duplicated event ID, wrong method, and oversized payload. A successful provider test event confirms one integration path. It does not make arbitrary direct requests trusted.

The React frontend security guide covers browser trust and raw HTML. The server-side authorization guide applies the same server-entry model beyond Next.js.

Keep the conclusion precise

A clean review of one action supports that action, role set, build, and environment. It does not prove all dynamic routes, third-party callbacks, dependencies, infrastructure, or business logic are safe.

Record the commit, deployment, entry points, identities, data operations, and negative-test results. Recheck after adding Server Actions, Route Handlers, client props, environment variables, roles, data models, or Proxy rules.

Sources

• Next.js: Data Security
• Next.js: Authentication
• Next.js: Environment Variables
• Next.js: Proxy
• React: use server
• OWASP: Authorization Cheat Sheet