An endpoint that should require a signed-in owner answers anyone. A tool server hands out environment secrets, a review page skips login, visitors on a shared demo account can delete its content, or a query parameter decides where the server sends a request, token included. The author only tests from their own account, so nobody notices until a stranger tries it. This pattern appeared in 5 verified builder reports in our data, in both hand-built and AI-generated apps.
Each handler carries its own check, so any handler that was generated or copied without one is open. In Next.js, a check at page level does not protect the Server Actions defined on that page. Every exported action can be called with a direct POST, whether or not your UI uses it. The same is true of any route handler or serverless function: leaving it unlinked does not protect it.
A route that checks the session but not ownership passes every test run from the author's own account. OWASP's point is that access to one object of a type does not mean access to every object of that type. The bug only shows up with a second account or with no account at all.
An MCP or admin tool server deployed on a public URL is public. The MCP specification makes authorization optional, so a server that works without a token also works for anyone else. If a tool returns process.env or an admin token for debugging, every caller can read it.
At build time, Next.js inlines NEXT_PUBLIC_ variables and Vite inlines VITE_ variables into the client bundle. If a secret is given the public prefix to silence a client error, its value ships to the browser. If a client component imports a shared env or config module, the list of secret names and their expected formats ships too.
If a handler fetches a URL or host taken from the query string, the caller chooses where your server sends its request, along with the Authorization header you add. This is server-side request forgery (SSRF). fetch follows redirects by default, so even a validated URL can redirect to another origin.
Put session verification in a server-only module and call it at the top of every route handler, Server Action and tool handler. Here auth() stands for your auth library's session call. In code review, treat any handler that does not call the helper as a bug.
import 'server-only'
export async function requireUser() {
const session = await auth()
if (!session?.user) throw new Error('Unauthorized')
return session.user
}Load the record and return 404 if it is missing. Before any read or write, compare its owner with the session user. Never trust an owner id, role or isAdmin flag sent by the client.
const user = await requireUser()
const review = await db.review.findUnique({ where: { id } })
if (!review) return new Response(null, { status: 404 })
if (review.authorId !== user.id) return new Response(null, { status: 403 })Keep an internal MCP or admin server off the public internet, or require a bearer token on every request and answer a missing or invalid token with 401. The MCP specification says HTTP servers that support authorization must check that the token was issued for them and must never pass it on to upstream APIs. Remove any tool that returns environment variables.
Never give a secret a NEXT_PUBLIC_ or VITE_ prefix. Add import 'server-only' to every module that reads process.env, so importing it from the client fails the build. Before each release, search the built client output for secret names and key prefixes.
npm run build
grep -rlE 'sk_live_|sb_secret_|SERVICE_ROLE|SECRET_KEY' .next/static dist 2>/dev/nullRemoving a key from the code does not remove it from builds that are already deployed or cached. Issue a new key at the provider, deploy it as a server-only variable, then revoke the old one.
Accept a short name, map it on the server to a fixed origin, and reject anything else. Do not accept full URLs from the request. Set redirect: 'error' so a redirect cannot send the request to another origin.
const ORIGINS = { images: 'https://images.example.com' } as const
const origin = ORIGINS[target as keyof typeof ORIGINS]
if (!origin) return new Response(null, { status: 400 })
const res = await fetch(new URL('/v1/render', origin), {
redirect: 'error',
headers: { Authorization: `Bearer ${process.env.RENDER_TOKEN}` },
})Enforce read-only access for the demo user on the server, not by hiding buttons. If visitors must be able to write, restore the seed data on a schedule. Restore it now as well, since the live data may already have been changed.
No. Anyone can call a deployed route handler or function URL directly, and Next.js documents that exported Server Actions can be called with a direct POST. Check authentication and authorization inside each one.
No. Both frameworks inline those values into the JavaScript sent to the browser at build time, and minifying does not hide a string. Call the provider from a server route and keep the key in a variable without the public prefix.
No. Supabase's docs say a secret key bypasses every Row Level Security policy and must never go in a browser, a shipped app or source control. The newer sb_secret_ keys are refused with 401 when Supabase detects a browser User-Agent.
The specification makes authorization optional, but an HTTP server without it answers anyone who finds the URL. For a local STDIO server, the specification says to take credentials from the environment instead.
Either one stops the leak. A 404 for records the caller does not own also avoids confirming that the id exists.