Docs verified at Next.js version 16.3.5 as shown on the pages; the middleware file convention is deprecated in favour of proxy.
Next.js runs React on the server and the client. Its docs describe three things that matter for security testing. Only NEXT_PUBLIC_ variables reach the browser. An exported Server Action is reachable by a direct POST regardless of the page's UI. A page-level auth check does not extend to the Server Actions defined in it.
So the tests for a Next.js app are about server boundaries. Which variables were prefixed for the browser. Whether every Server Action and route handler checks the caller itself. Whether the proxy (formerly middleware) is doing work that should live in a data access layer.
Each row is taken from the vendor's documentation on the date shown. Defaults change; the date is the claim.
| Area | Default | Source |
|---|---|---|
| NEXT_PUBLIC_ prefix exposure | By default environment variables are only available on the server; variables prefixed NEXT_PUBLIC_ are inlined into the browser bundle at build time and frozen at that value. | docs · verified 2026-09-21 |
| .env files | The default create-next-app template adds all .env files to .gitignore; Next.js loads .env, .env.local and per-environment files from the project root. | docs · verified 2026-09-21 |
| Server actions | An exported Server Action is reachable via a direct POST request, not just the UI. Next.js adds encrypted non-deterministic action IDs, dead code elimination and an Origin to Host check. The docs say to verify authentication and authorization inside each action. | docs · verified 2026-09-21 |
| Middleware / proxy caveats | middleware is deprecated and renamed proxy; it runs on every route unless matched, defaults to the Node.js runtime, and Server Function calls on excluded paths skip it. The docs say to verify auth inside each Server Function rather than relying on Proxy alone. | docs · verified 2026-09-21 |
| Page-level checks | A page-level authentication check does not extend to the Server Actions defined within it; returning null in a layout does not stop nested segments or actions from being reached. | docs · verified 2026-09-21 |
Documentation home: nextjs.org/docs
36 patterns in the catalogue name Next.js; the most severe are listed here across secrets and keys, data access, login and permissions, payments, ai features. Attribution is descriptive: the default stack makes the pattern reachable, or a public incident names it.
The build writes the secret's value into public JavaScript, so anyone who loads the site can read it, and a redeploy with the same variable name republishes it.
Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.
Anyone who opens the app can copy the key from the downloaded JavaScript and read, change or delete every row in every table.
Anyone who changes the id in a URL or request can read, edit or delete another customer's record.
A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.
Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.
Anyone who reads the code or guesses a common placeholder can sign in as the administrator.
Anyone can write their own token naming another user, or an admin, and the server will act as that person.
A visitor who edits the signup request, or updates their own profile, can make themselves an admin.
Anyone who finds the webhook URL can post a made-up payment-succeeded event and get an order fulfilled or a plan activated for a user of their choosing, without paying.
Anyone who views the page source can copy the key and run their own workloads on your account until the bill or the provider stops them.
Whoever can influence the model's input can delete tables, email your whole customer list, or trigger any other action the app has wired up.
Anyone who views the page source can take the key and run up charges, send messages or pull data on your account until the key is revoked.
Keys, session tokens and database connection strings end up in log files and in HTTP responses that anyone can trigger, which hands out credentials and a map of the system's internals.
An old reset email found in a shared inbox, a forwarded thread or a breached mailbox lets someone take over the account months later.
Lovable reported that from 3 February to 20 April 2026 a backend regression let any logged-in Lovable user read the chat history and source code of public projects; a fix shipped within two hours.
Apr 2026 · Lovable · all sources
One education app built on Lovable had 16 vulnerabilities, 6 critical; a database function denied callers whose role was 'authenticated', so anonymous callers passed and 18,697 user records were readable without login.
Feb 2026 · Taimur Khan · all sources
On the Base44 app builder, undocumented registration and one-time-password endpoints accepted a non-secret app_id, so anyone could create a verified account on a private app; Wix fixed it within 24 hours.
Jul 2025 · Wiz Research · all sources
Two days after announcing a SaaS built with Cursor and no hand-written code, its founder reported subscription bypasses, maxed-out API keys and unwanted database writes; he shut the app down three days later.
Mar 2025 · Leo (Enrichlead founder) · all sources
Each entry links to its primary source in the evidence list. What to do about it is the self-check below.
Stated from the vendor's documentation. The limits are the vendor's scope statements, not judgements.
server-only package
Marking a module with import 'server-only' causes a build error if it is imported into the client environment.
Where it stops: Protects module boundaries; it does not filter the data a server component passes to client components.
vendor docs · verified 2026-09-21
React Taint APIs
experimental_taintObjectReference and experimental_taintUniqueValue, enabled via experimental.taint, prevent tainted objects or values from being passed to the client.
Where it stops: Experimental and described as an additional layer; the docs say to still filter and sanitize data in a Data Access Layer.
vendor docs · verified 2026-09-21
Server Action protections
Encrypted action IDs regenerated per build, removal of unused actions from the client bundle, POST-only invocation and an Origin to Host header comparison against CSRF.
Where it stops: The docs state these reduce risk where an auth layer is missing but that actions must still be treated as public POST endpoints and check authentication and authorization, including resource ownership.
vendor docs · verified 2026-09-21
Data Access Layer guidance
The authentication guide recommends a server-only Data Access Layer with verifySession(), DTOs that return only needed fields, and treating Route Handlers like public API endpoints.
Where it stops: A pattern to implement, not a built-in enforcement; Proxy is described as optimistic checks only, not the sole line of defence.
vendor docs · verified 2026-09-21
The critical patterns first. Each uses the dashboard and your browser.
.env files, list every variable whose name starts with NEXT_PUBLIC_.NEXT_PUBLIC_ variable holding a server-only key, or a search hit for that key's value in a loaded script..env, .env.local, .env.production, serviceAccountKey.json or firebase-adminsdk files.sk_live, sk-, service_role, BEGIN PRIVATE KEY and password=.git log --all -p -S sk_live -- . | head. Any output means a live key has been committed at some point.service_role and then for sb_secret_.supabase.co, and read the apikey header under Request Headers.Next.js pre-launch checklist
36 checks, in the order we run them. Usable without buying anything.
Self-check tool
Answer questions about your setup and get the patterns that apply, ordered by severity. Runs in your browser; nothing is sent.
For founders about to let real users in.
$490
For anyone who wants the three riskiest areas checked fast.
$290
All packages and prices. Every report includes a re-check after your fixes.
Each Server Action is an endpoint. Next.js docs recommend verifying the user inside the action or in a data access layer it calls, not only on the page. We call every action directly with a second user's session and report which ones act without checking.
Anything prefixed NEXT_PUBLIC_ is inlined into the JavaScript bundle at build time. Search your deployed bundle for the value; if a secret is there, rotate it, remove the prefix and read it on the server only.
Server-only secrets, a permission check in every Server Action and route handler, the server-only package or Taint APIs on sensitive data, security headers in next.config, and dependency updates. The Next.js patterns on this page map to each item.