Next.js security checklist for AI-built apps

In the App Router, Server Components, server actions and route handlers run on the server and can reach secrets and databases. Client Components run in the browser. The Next.js documentation says Client Components must follow the same security assumptions as code running in the browser, and that environment variables are only available on the server unless they are prefixed with NEXT_PUBLIC_.

The boundary is crossed in two directions. Data goes out when a Server Component passes props to a Client Component, and everything in those props reaches the browser. Requests come in through pages, route handlers and server actions. The documentation says an exported server action is reachable by a direct POST request, not only through your interface. So the question for every entry point is the same: what happens when a stranger calls this directly?

This page covers the framework. For where you host it, see the checklist for your platform, and for the general idea of why browser code cannot enforce access, see our guides on environment variables and client-side secrets.

The Next.js documentation says a page-level authentication check does not extend to the server actions defined within it, and that you should always re-verify inside the action. It lists built-in protections, such as encrypted action ids and removing unused actions from the build, and then says you should still treat server actions as reachable via direct POST requests.

Find every action and read it. The documented pattern is to check authentication first, then authorisation, meaning that this user may act on this specific record. The auth and db helpers below stand in for whatever your project uses.

grep -rln "use server" app src

'use server'

import { auth } from '@/lib/auth'
import { db } from '@/lib/db'

export async function deletePost(postId: string) {
  const session = await auth()
  if (!session?.user) {
    throw new Error('Unauthorized')
  }

  const post = await db.post.findUnique({ where: { id: postId } })
  if (!post || post.authorId !== session.user.id) {
    throw new Error('Forbidden')
  }

  await db.post.delete({ where: { id: postId } })
}

The documentation says to treat route handlers with the same security considerations as public-facing API endpoints. List them, then call each one against your own site with no cookie. Follow up with the two-account test: sign in as a second user, copy the first user's record id and request it.

find app src -name "route.ts" -o -name "route.js"

export SITE="https://your-site.example"

curl -i "$SITE/api/YOUR_ROUTE"
curl -i -X POST "$SITE/api/YOUR_ROUTE" -H "Content-Type: application/json" -d '{}'

Build the project and search the static output, which is what browsers download. Any hit for a secret-shaped string is a finding. Then list the public variables and confirm each is something you are content to publish. Adjust the patterns to your providers.

To stop server-only code being imported into client code by accident, the documentation recommends marking modules with the server-only package, which causes a build error if the module is imported in the client environment.

npm run build
grep -rEl "sk_live_|sb_secret_|service_role|BEGIN PRIVATE KEY" .next/static

grep -rn "NEXT_PUBLIC_" .env* 2>/dev/null
git ls-files | grep -E "^\.env"
git log --all -p -S"sk_live_" | head -50

The Next.js documentation recommends a data access layer for new projects: a server-only module that performs authorisation checks and returns minimal objects with only the fields the interface needs. It shows the opposite as a warning, where a whole database row is passed to a Client Component and every field is exposed.

AI-generated code often takes the short path and passes the whole row. View the page source or the network responses on a page showing user data and look for fields that are not on screen. Server action return values are sent to the client too, so return a small result instead of the raw record.

• Protecting the page and forgetting the server action inside it.
• Relying on a matcher in proxy or middleware, then adding a new route it does not cover.
• Returning null from a layout for unauthorised users. The docs say this does not stop nested routes and server actions from being accessed.
• Putting a secret in a NEXT_PUBLIC_ variable so a Client Component can call an API directly.
• Trusting a user id, role or price sent from the browser.
• Passing a full database row as props.
• Checking that the user is signed in but not that the record belongs to them.

Repeat the use server search and the route probes after every large generated change, since new entry points appear quietly. The documentation's own audit advice is to spend extra time on proxy.ts and route.ts, on use server files and on the props of use client files. Keep two test accounts for regression checks.