Next.js (TypeScript/JavaScript) Web Security Spec (Next.js 16.1.x, Node.js 20.9+)

Next.js (TypeScript/JavaScript) Web Security Spec (Next.js 16.1.x, Node.js 20.9+)

This document is designed as a security spec that supports:

1. Secure-by-default code generation for new Next.js backend code (Route Handlers, API Routes, Server Actions, Proxy/Middleware).
2. Security review / vulnerability hunting in existing Next.js repos (passive “notice issues while working” and active “scan the repo and report findings”).

It is intentionally written as a set of normative requirements (“MUST/SHOULD/MAY”) plus audit rules (what bad patterns look like, how to detect them, and how to fix/mitigate them).

Target scope: Next.js 16.1.x (latest line shown in the App Router docs) ([Next.js][1]), running on Node.js 20.9+ (per Next.js system requirements). ([Next.js][2])

0) Safety, boundaries, and anti-abuse constraints (MUST FOLLOW)

• MUST NOT request, output, log, or commit secrets (API keys, passwords, private keys, session cookies, OAuth tokens, process.env dumps, database URLs with credentials).
• MUST NOT “fix” security by disabling protections (e.g., disabling origin checks, relaxing CORS to *, skipping authz checks, turning off cookie security flags, turning off CSP because it’s “hard”).
• MUST provide evidence-based findings during audits: cite file paths, code snippets, and configuration values that justify each claim.
• MUST treat uncertainty honestly: if a protection might exist in infrastructure (reverse proxy, CDN, WAF, platform headers), report it as “not visible in app code; verify at runtime/config”.
• MUST assume all request-facing server code is reachable by attackers unless there is a clearly enforced auth boundary (not just “the UI doesn’t link to it”).
• MUST treat TypeScript types as non-security boundaries: types do not validate runtime input; runtime checks are required. ([Next.js][3])

1) Operating modes

1.1 Generation mode (default)

When asked to write new Next.js code or modify existing code:

• MUST follow every MUST requirement in this spec.
• SHOULD follow every SHOULD requirement unless the user explicitly says otherwise.
• MUST prefer safe-by-default APIs and proven libraries over custom security code.
• MUST avoid introducing new risky sinks (dynamic code execution, unsafe redirects, serving user files as HTML, SSRF URL fetchers, building SQL strings, etc.).

1.2 Passive review mode (always on while editing)

While working anywhere in a Next.js repo (even if the user did not ask for a security scan):

• MUST “notice” violations of this spec in touched/nearby code.
• SHOULD mention issues as they come up, with a brief explanation + safe fix.

1.3 Active audit mode (explicit scan request)

When the user asks to “scan”, “audit”, or “hunt for vulns”:

• MUST systematically search the codebase for violations of this spec.
• MUST output findings in a structured format (see §2.3).

Recommended audit order:

1. Deployment entrypoints and environment (Dockerfiles, package.json scripts, hosting config).
2. Next.js config (next.config.*), Proxy/Middleware, routing patterns.
3. Authentication, sessions, cookies.
4. CSRF protections and state-changing endpoints (Server Actions, Route Handlers, API Routes).
5. XSS (React + CSP) and unsafe HTML rendering.
6. Cache/data-leak hazards (static rendering + caching + “use cache”).
7. File handling (uploads/downloads) and path traversal.
8. Injection classes (SQL/ORM misuse, command execution, unsafe deserialization).
9. Outbound requests (SSRF).
10. Redirect handling (open redirects).
11. CORS and security headers.

2) Definitions and review guidance

2.1 Untrusted input (treat as attacker-controlled unless proven otherwise)

In Next.js backends, untrusted input includes:

App Router:

• Route Handler params and request data:

  • context.params (dynamic segments), search params (request.url, new URL(request.url).searchParams)
  • request.headers, request.cookies
  • await request.json(), await request.formData(), await request.text()

• Dynamic APIs used in Server Components/Server Functions:

  • headers() and cookies() values ([Next.js][4])

Pages Router:

• req.query, req.cookies, req.body in pages/api/* handlers ([Next.js][3])

Plus:

• Anything from external systems (webhooks, third-party APIs, message queues)
• Any persisted user content (DB rows) that originated from users

2.2 State-changing request

A request is state-changing if it can create/update/delete data, change auth/session state, trigger side effects (purchase, email send, webhook send), or initiate privileged actions.

Special note for Next.js:

• Server Actions are invoked via network requests and can mutate state; treat them as state-changing endpoints. ([Next.js][5])

2.3 Required audit finding format

For each issue found, output:

• Rule ID:
• Severity: Critical / High / Medium / Low
• Location: file path + function/route name + line(s)
• Evidence: the exact code/config snippet
• Impact: what could go wrong, who can exploit it
• Fix: safe change (prefer minimal diff)
• Mitigation: defense-in-depth if immediate fix is hard
• False positive notes: what to verify if uncertain

3) Secure baseline: minimum production configuration (MUST in production)

This is the smallest “production baseline” that prevents common Next.js backend misconfigurations.

3.1 Run Next.js in production mode (MUST)

• MUST run next build + next start (or the managed platform equivalent), not next dev. Dev mode has different error/reporting behavior and is not designed for production exposure. ([Next.js][6])
• MUST ensure NODE_ENV=production in production (Next.js defaults NODE_ENV based on command; verify the runtime environment). ([Next.js][7])

3.2 Put a reverse proxy / edge layer in front when self-hosting (MUST for public internet)

• If self-hosting, MUST place a reverse proxy (e.g., nginx) or equivalent edge layer in front of the Next.js server to handle malformed requests, slow attacks, payload size limits, rate limiting, and similar concerns. ([Next.js][8])

3.3 Baseline header/cookie posture (SHOULD)

• SHOULD set a baseline of security headers globally (CSP, X-Content-Type-Options, clickjacking defense via CSP frame-ancestors and/or X-Frame-Options, etc.). Next.js provides guidance for implementing CSP via Proxy/headers. ([Next.js][7])
• MUST ensure auth/session cookies use secure attributes (Secure, HttpOnly, SameSite) as appropriate. ([Next.js][9]) IMPORTANT NOTE: Only set Secure in production environment. When running in a local dev environment over HTTP, do not set Secure property on cookies. You should do this conditionally based on if the app is running in production mode. You should also include a property like SESSION_COOKIE_SECURE which can be used to disable Secure cookies when testing over HTTP.

3.4 Clear separation between server-only and client code (MUST)

• MUST prevent secrets and privileged logic from being bundled into client code.
• MUST treat NEXT_PUBLIC_* environment variables as public (browser-exposed and inlined at build time). ([Next.js][7])

4) Rules (generation + audit)

Each rule contains: required practice, insecure patterns, detection hints, and remediation.

NEXT-DEPLOY-001: Do not run next dev in production; ensure production mode behavior

Severity: High (if production)

NOTE: If they are deploying to a specific Next.js hosting provider, they do not need to worry about this.

Required:

• MUST NOT deploy next dev or any development server mode to production.
• MUST ensure production builds and production runtime are used for any public deployment. ([Next.js][6])

Insecure patterns:

• next dev in Docker CMD, Procfile, platform start command.
• NODE_ENV=development in production environment config.
• Debug/dev-only endpoints or flags exposed publicly.

Detection hints:

• Search package.json scripts and deployment manifests for next dev.
• Search infra for NODE_ENV=development or missing NODE_ENV.
• Check Kubernetes/PM2/systemd entrypoints for next dev.

Fix:

• Use next build during CI/build and next start at runtime (or platform-native build/run).
• Ensure environment sets NODE_ENV=production.

Note:

• Dev mode is fine for local development. Only flag if it is being used as a production entrypoint.

NEXT-SUPPLY-001: Stay on supported Next.js releases; patch quickly for security advisories

Severity: High (Critical if known-vulnerable version)

Required:

• MUST run a supported Next.js version line and apply security updates promptly. Next.js documents an LTS/support policy. ([Next.js][10])
• MUST treat published advisories as urgent upgrade signals (e.g., update to a patched release). ([GitHub][11])

Insecure patterns:

• Running EOL Next.js major/minor without backported security fixes.
• Ignoring advisories, or pinning next to a vulnerable range.

Detection hints:

• Check package.json and lockfiles for next version.
• Compare against Next.js support policy and advisories.

IMPORTANT: Any versions older than these minor versions are vulnerable to "react2shell" vulnerability (https://nextjs.org/blog/CVE-2025-66478): 15.0.5 15.1.9 15.2.6 15.3.6 15.4.8 15.5.7 16.0.7

Fix:

• Upgrade next to a supported and patched version.
• Add a dependency update process + CI checks.

NEXT-SECRETS-001: Secrets MUST NOT be committed or exposed to the browser

Severity: High (Critical if secret is client-exposed)

Required:

• MUST store secrets in environment variables or a secret manager; MUST NOT commit .env* files.
• MUST treat .env* as sensitive; Next.js warns you “almost never want to commit these files.” ([Next.js][7])
• MUST treat any NEXT_PUBLIC_* environment variable as public and browser-visible (inlined into the client bundle at build time). ([Next.js][7])

Insecure patterns:

• .env, .env.local, .env.production committed to git.
• NEXT_PUBLIC_API_KEY, NEXT_PUBLIC_SECRET, NEXT_PUBLIC_DATABASE_URL, etc.
• Rendering process.env values into HTML or returning them from API routes.

Detection hints:

• Scan git history and repo files for .env content, DB_PASS=, API_KEY=, SECRET=.
• Grep for NEXT_PUBLIC_ and review any sensitive-looking names.
• Search for process.env usage in Client Components ("use client") and shared modules.

Fix:

• Move secrets to server-only env vars (no NEXT_PUBLIC_ prefix).
• Ensure .env* is ignored and secrets are injected at deploy time.
• Rotate leaked keys.

NEXT-SECRETS-002: Avoid server-only → client bundling mistakes (server/client boundary is a security boundary)

Severity: High

Required:

• MUST ensure server-only modules (DB clients, secret-dependent code) are not imported into Client Components or other client-bundled code paths.
• SHOULD use server-only patterns/layers (e.g., a dedicated DAL and server-only modules) and treat boundary violations as security bugs. Next.js explicitly discusses the “server-only” concept for sensitive modules. ([Next.js][6])

Insecure patterns:

• Importing DB clients, admin SDKs, or secret-reading modules into "use client" components.
• Shared lib/ modules imported by both server and client code that reference secrets.

Detection hints:

• Search for "use client" and examine its imports for server-only dependencies.
• Look for DB client packages (pg, mysql2, mongoose, prisma, admin SDKs) imported from components/ or other client paths.
• Search for process.env access in UI components.

Fix:

• Refactor into lib/server/* and only import from server contexts (Route Handlers, Server Components, Server Actions).
• Add an explicit “server-only” guard pattern (and/or tests) to prevent accidental imports.

NEXT-AUTH-001: Authentication/authorization MUST be enforced server-side for every protected action

Severity: High

Required:

• MUST enforce authn/authz in server-side code for:

  • Route Handlers (app/**/route.ts) ([Next.js][1])
  • API Routes (pages/api/**) ([Next.js][3])
  • Server Actions ("use server" functions invoked by clients) ([Next.js][6])

• MUST NOT rely on client-side checks (hiding UI, route guards on the client) as the only protection.

Insecure patterns:

• Sensitive Route Handlers with no session verification.
• Server Actions that mutate data but do not validate user identity/permissions.
• “Authorization” checks in React components only.

Detection hints:

• Enumerate all Route Handlers and API Routes; for each, identify whether it requires auth.
• Grep for "use server" and review all exported actions for auth checks.
• Search for admin actions triggered by query params / form submits.

Fix:

• Centralize auth helpers and call them in every protected endpoint/action.
• Implement least-privilege authorization checks (role/resource ownership) per action.

NEXT-AUTH-002: Proxy/Middleware-based auth MUST NOT create route coverage gaps

Severity: High

Required:

• If using Proxy or Middleware for authentication checks, MUST ensure it covers every route that needs protection.
• Next.js documentation notes Proxy can use a matcher, and for auth it’s recommended Proxy runs on all routes. ([Next.js][12])
• MUST treat matcher mistakes as an auth bypass risk.

Insecure patterns:

• Proxy/Middleware only matches “pages” but not /api/*, or only matches some route groups.
• “Denylist” style matchers that miss alternative request forms (framework-internal variants, RSC navigations, etc.).

Detection hints:

• Inspect proxy.ts / middleware.ts and its matcher.
• Compare matchers to the full set of routes (including app/api/** and pages/api/**).
• Ensure static assets and Next internals are excluded only intentionally, and that sensitive routes are included.

Fix:

• Prefer allowlisting protected route prefixes or running Proxy globally and doing internal allow/deny logic.
• Add integration tests: request protected route without auth and assert denial.

Notes:

• Proxy is commonly used for “optimistic checks”; it is not a complete authorization system by itself. ([Next.js][12])

NEXT-CSRF-001: Cookie-authenticated state-changing endpoints MUST be CSRF-protected

Severity: High

• IMPORTANT NOTE: If cookies are not being used for auth (ie auth is via Authentication header or other passed token), then there is no CSRF risk.

Required:

• MUST protect every state-changing endpoint that relies on cookies for auth (POST/PUT/PATCH/DELETE).
• For Server Actions, Next.js performs an Origin/Host comparison to help prevent CSRF; do not disable or weaken it. ([Next.js][5])
• If Server Actions must be callable from additional trusted origins (e.g., a trusted proxy domain), MUST use allowedOrigins with a strict allowlist. ([Next.js][5])
• For Route Handlers and API Routes, MUST implement CSRF protections explicitly (tokens and/or strict Origin/Referer + SameSite + custom headers). Route Handlers are an “escape hatch” and require application-level security decisions. ([Next.js][6])

Insecure patterns:

• POST endpoints (including Server Actions) that mutate state and accept cross-site requests with no token/origin checks.
• allowedOrigins: ['*'] (or broad wildcards) or “reflect Origin” logic.
• Using GET requests to change state.

Detection hints:

• Enumerate all state-changing endpoints and determine auth mechanism.
• Search for allowedOrigins and confirm the list is small, specific, and justified. ([Next.js][5])
• In Route Handlers/API Routes: look for missing CSRF token validation or missing Origin/Referer checks.

Fix:

• Implement a CSRF token strategy for cookie-auth endpoints.
• Keep cookies SameSite=Lax or Strict when compatible; don’t treat SameSite alone as sufficient.
• Use strict Origin validation for JSON API endpoints, especially when not using CSRF tokens.

Notes:

• XSS can defeat CSRF protections; CSRF defenses do not replace XSS prevention.

NEXT-SESS-001: Session cookies MUST use secure attributes in production

Severity: Medium

Required (production, HTTPS):

• MUST set session/auth cookies with:

  • Secure: true (HTTPS-only) IMPORTANT NOTE: Only set Secure in production environment. When running in a local dev environment over HTTP, do not set Secure property on cookies. You should do this conditionally based on if the app is running in production mode. You should also include a property like SESSION_COOKIE_SECURE which can be used to disable Secure cookies when testing over HTTP.
  • HttpOnly: true (not readable by JS)
  • SameSite: 'Lax' (recommended) or 'Strict' if compatible

• Only use SameSite: 'none' when you truly need cross-site cookies, and then MUST also set Secure. Cookie options are supported in Next.js cookie APIs. ([Next.js][9])

Insecure patterns:

• secure: false in production.
• httpOnly: false for auth cookies.
• sameSite: 'none' without a clear need, especially on cookie-authenticated state-changing endpoints.

Detection hints:

• Search for cookie setting sites (cookies().set(...), Set-Cookie headers, auth library cookie config).
• Review cookie options used in Route Handlers and Server Actions. ([Next.js][9])

Fix:

• Set secure cookie attributes at the auth/session layer.
• Reduce cookie scope: avoid wide domain unless you explicitly need subdomain-wide cookies.

NEXT-SESS-002: Sessions MUST be bounded and resistant to fixation/replay

Severity: Low

Required:

• SHOULD set bounded session lifetimes appropriate to the app.
• SHOULD rotate session identifiers on login and privilege changes.
• MUST NOT store sensitive secrets directly in client-readable storage (including cookies that are not encrypted).

Insecure patterns:

• Long-lived admin sessions with no rotation.
• “Remember me forever” for privileged roles without additional risk controls.
• Storing access tokens/refresh tokens in non-HttpOnly cookies or localStorage.

Detection hints:

• Review auth library configuration for expiration and rotation.
• Search for localStorage.setItem('token'...) and non-HttpOnly cookie usage.

Fix:

• Use short lifetimes for privileged sessions; refresh with rotation.
• Store only opaque session IDs in cookies; keep sensitive material server-side.

NEXT-INPUT-001: Runtime input validation is mandatory (TypeScript is not validation)

Severity: High

Required:

• MUST validate and normalize all attacker-controlled input at runtime (schemas, type checks, bounds).
• Next.js API Routes explicitly note req.body is any and must be validated before use. ([Next.js][3])
• MUST validate Server Action arguments (treat as hostile). ([Next.js][6])

Insecure patterns:

• Trusting req.body shape directly.
• Passing params.id/searchParams directly into DB queries or file paths.
• Parsing JSON and then assuming types without validation.

Detection hints:

• Identify endpoints that accept JSON/form input and check for schema validation.
• Grep for req.body. usage and for await request.json() usage in Route Handlers; verify validation exists.

Fix:

• Add schema validation (e.g., zod/yup/valibot) and reject invalid input with 4xx.
• Validate IDs as strict types (UUID/int) and enforce length/charset constraints.

NEXT-HEADERS-001: Essential security headers MUST be set (in app or at the edge)

Severity: Low

Required (typical web app):

• SHOULD set:

  • CSP (Content-Security-Policy) (see NEXT-CSP-001)
  • X-Content-Type-Options: nosniff
  • Clickjacking defense (frame-ancestors in CSP and/or X-Frame-Options)
  • Referrer-Policy and Permissions-Policy when appropriate

• MUST ensure cookies are set with secure attributes (see NEXT-SESS-001). ([Next.js][9])

Insecure patterns:

• No security headers anywhere (app or edge).
• Allowing iframing unintentionally.
• Content-Type sniffing possible due to missing nosniff.

Detection hints:

• Check proxy.ts / middleware for response.headers.set(...). ([Next.js][7])
• If not visible in app code, flag as “verify at edge/CDN”.

Fix:

• Set headers centrally (Proxy/Middleware or other centralized mechanism).
• Ensure consistent headers across routes.

NEXT-CSP-001: Use a CSP to reduce XSS impact; prefer nonces for scripts

Severity: Medium

NOTE: It is most important to set the CSP's script-src. All other directives are not as important and can generally be excluded for the ease of development.

Required:

• SHOULD deploy a CSP, ideally with nonces for scripts.
• SHOULD follow Next.js guidance for CSP implementation (including nonce generation and header application). ([Next.js][7])
• MUST avoid loosening CSP as a “fix” (e.g., script-src 'unsafe-inline') without explicit risk acceptance.

Insecure patterns:

• CSP missing on apps that display user-generated HTML/markdown.
• CSP that broadly enables inline scripts or eval without strict justification.

Detection hints:

• Search for Content-Security-Policy header setting and examine its directives.
• Check use of next/script and whether a nonce is provided when CSP requires it.

Fix:

• Implement CSP per Next.js guidance; use a nonce and apply it consistently.
• Reduce inline scripts; avoid eval.

Notes:

• CSP is defense-in-depth; it does not replace proper output encoding and sanitization.

NEXT-XSS-001: Prevent reflected/stored XSS in React/Next rendering

Severity: High

Required:

• MUST rely on React’s default escaping; MUST NOT insert untrusted HTML into the DOM without sanitization.

• MUST treat these as high-risk sinks:

  • dangerouslySetInnerHTML
  • rendering user-controlled strings into <script> tags or event handler attributes

• MUST avoid serving uploaded HTML as active HTML (serve as attachment or sanitize/transform).

Insecure patterns:

• <div dangerouslySetInnerHTML={{ __html: userContent }} /> with no sanitizer.
• Markdown renderers configured to allow raw HTML with no sanitizer.
• Returning user content with Content-Type: text/html from a Route Handler.

Detection hints:

• Search for dangerouslySetInnerHTML, __html:.
• Search for template-like string concatenation that builds HTML.
• Review any “render HTML” or “preview” features.

Fix:

• Sanitize untrusted HTML with a well-maintained sanitizer; prefer strict allowlists.
• Prefer rendering user content as text, not HTML.
• Add CSP to reduce impact.

NEXT-ACTION-001: Server Actions MUST be treated like public endpoints

Severity: High (Critical for privileged actions)

Required:

• MUST apply the same controls as for Route Handlers:

  • authn/authz
  • input validation
  • CSRF/origin protections
  • rate limiting for sensitive actions

• MUST NOT assume Server Actions are “not reachable” or “internal”.

• MUST understand Server Action request protections:

  • Next.js compares Origin with host to mitigate CSRF; extra origins must be explicitly allowlisted via allowedOrigins. ([Next.js][5])

Insecure patterns:

• "use server" functions that update DB state with no auth check.
• Adding overly broad allowedOrigins to “make it work”.

Detection hints:

• Grep for "use server" and inventory all exported actions.
• Identify any action doing privileged writes; confirm it checks identity and permission.

Fix:

• Wrap actions with an authz helper (fail closed).
• Keep allowedOrigins minimal and audited.

NEXT-ACTION-002: Do not accidentally leak secrets through Server Action closure/binding patterns

Severity: Medium (High if important secrets are exposed)

Required:

• MUST treat Server Action closed-over values as sensitive and design intentionally.
• Next.js notes that closed-over values are encrypted/signed, but values passed through .bind are not encrypted; do not rely on .bind to protect secrets. ([Next.js][6])
• If using a stable encryption key for Server Actions across deployments, MUST treat it as a secret and store securely (do not commit/log it). ([Next.js][6])

Insecure patterns:

• myAction.bind(null, process.env.SECRET) or binding sensitive tokens/IDs that should not be client-influenced.
• Logging action arguments that include secrets.

Detection hints:

• Search for .bind( on Server Action functions.
• Search for process.env usage near Server Actions.

Fix:

• Avoid binding secrets into actions; fetch secrets server-side inside the action.
• Keep action arguments minimal and validated.

NEXT-CACHE-001: Prevent data leaks via static rendering and shared caching

Severity: High (Critical if cross-user data leak)

Required:

• MUST ensure pages/endpoints that return user-specific or sensitive data are not statically generated or cached in a shared way.
• Route Handlers are not cached by default, but GET handlers can opt into caching/static behavior; do not do this for per-user data. ([Next.js][1])
• MUST treat use cache and similar caching mechanisms as potentially cross-user unless explicitly proven private; do not cache per-user DB results in shared caches. ([Next.js][1])
• SHOULD set explicit Cache-Control: no-store / private for sensitive responses (auth/session/user data APIs).

Insecure patterns:

• export const dynamic = 'force-static' on a route that returns user-specific data. ([Next.js][1])
• Using use cache around a function that queries user-specific data without a per-user cache key. ([Next.js][1])
• Returning auth/session responses from GET endpoints with caching enabled.

Detection hints:

• Search for dynamic = 'force-static', revalidate, use cache, cacheLife, unstable_cache.
• Inspect all GET Route Handlers that are cached/static and confirm they only return public data.
• Confirm that use of cookies()/headers() (dynamic APIs) is not accidentally removed in ways that make a route static. ([Next.js][1])

Fix:

• Mark sensitive routes as dynamic and set Cache-Control: no-store.
• Ensure caching keys include user identity if caching is truly needed (and store it in a user-private cache).

NEXT-FILES-001: User uploads MUST be validated, stored safely, and served safely

Severity: Medium

Required:

• MUST enforce upload size limits at the edge and in application logic.
• MUST validate file type using allowlists and content checks (not only extension).
• MUST store uploads outside the public/ directory (anything under public/ is served as static content by default).
• MUST serve potentially active formats safely (Content-Disposition: attachment) unless explicitly intended.

Insecure patterns:

• Accepting arbitrary file types and serving them back inline.
• Using user-supplied filename as the storage path.
• Writing uploads into public/uploads/ and serving them directly.

Detection hints:

• Search for formData() / multipart parsing, fs.writeFile, storage SDK usage.
• Look for any write path under public/.
• Look for “download” endpoints that set Content-Type: text/html or serve user files inline.

Fix:

• Use a dedicated object store (S3/GCS) or a safe server-side directory outside static roots.
• Generate random server-side filenames; store metadata separately.

NEXT-PATH-001: Prevent path traversal and unsafe file access

Severity: High

Required:

• MUST NOT use user-controlled strings as filesystem paths.
• MUST validate and normalize identifiers; use allowlists and safe base directories.
• MUST avoid reading arbitrary files based on request parameters.

Insecure patterns:

• fs.readFile(request.nextUrl.searchParams.get('path'))
• path.join(base, userPath) without normalization + boundary checks

Detection hints:

• Search for fs. usage in Route Handlers/API Routes.
• Search for path.join/path.resolve fed by request params.

Fix:

• Use opaque IDs that map to server-side stored paths.
• Enforce that resolved paths remain within an intended base directory.
• Sanitize and disallow .. from being used when creating urls

NEXT-SSRF-001: Outbound requests using user-influenced URLs MUST be restricted

Severity: Medium (High in internal networks)

NOTE: This is mostly only applicable to apps which will be deployed in a cloud/LAN setup or have other http services on the same box. Sometimes the feature requires this functionality unavoidably (webhooks).

Required:

• MUST treat any server-side fetch() to a user-provided URL as high-risk.

• SHOULD allowlist destinations (hosts/domains) for URL fetch features.

• SHOULD block:

  • localhost / private IP ranges / link-local
  • cloud metadata endpoints

• MUST restrict protocols to http: and https:.

• SHOULD set strict timeouts and restrict redirects.

Insecure patterns:

• await fetch(req.query.url) or await fetch((await request.json()).url)
• “URL preview” endpoints that fetch arbitrary URLs.

Detection hints:

• Search for fetch( in server code and trace where the URL comes from.
• Look for “webhook tester”, “preview”, “import from URL” features.

Fix:

• Parse URL, enforce http/https, allowlist hostnames, re-resolve DNS/IP to block private ranges.
• Set timeouts (AbortSignal) and limit redirects.

NEXT-REDIRECT-001: Prevent open redirects (including auth flows)

Severity: Low

Required:

• MUST validate redirect targets derived from untrusted input (e.g., next, redirect, returnTo).
• SHOULD prefer redirecting only to same-site relative paths.
• MUST validate any absolute URL against an allowlist.
• MUST ensure urls are http or https: schema, disallowing javascript: schema

Insecure patterns:

• redirect(searchParams.get('next')!)
• NextResponse.redirect(new URL(req.nextUrl.searchParams.get('to')!, req.url)) without checks

Detection hints:

• Search for redirect( (server components/actions) and NextResponse.redirect.
• Search for res.redirect( in API Routes. ([Next.js][3])

Fix:

• Only allow relative paths (/path) and reject protocol-relative (//evil.com) or absolute URLs.
• If invalid, fall back to a safe default (home/dashboard).

NEXT-CORS-001: CORS must be explicit and least-privilege

Severity: Medium (High if misconfigured with credentials)

Required:

• If CORS is not needed, MUST keep it disabled.
• Next.js API Routes do not set CORS headers by default, meaning they are same-origin by default; only enable CORS when you truly need it. ([Next.js][3])
• If enabling CORS:
  • MUST allowlist trusted origins (no reflection of arbitrary Origin)
  • MUST be careful with credentialed requests (cookies); never combine broad origins with credentials.
  • SHOULD restrict methods and headers.

Insecure patterns:

• Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true
• Reflecting Origin without validation.

Detection hints:

• Search for Access-Control-Allow-Origin, cors, “CORS” middleware/wrappers.
• Review preflight OPTIONS handlers.

Fix:

• Implement strict origin allowlist and minimal methods/headers.
• Ensure cookies aren’t exposed cross-origin unless necessary and reviewed.

NEXT-WEBHOOK-001: Webhook endpoints MUST verify authenticity using the raw body

Severity: Medium

Required:

• MUST verify webhook signatures using the raw request body (not a re-serialized parsed object).
• Next.js notes a use case for disabling body parsing is verifying the raw body of a webhook request. ([Next.js][3])

Insecure patterns:

• Verifying webhook signatures over JSON.stringify(req.body) (can change formatting).
• Accepting webhooks with no signature verification and no allowlist.

Detection hints:

• Find webhook endpoints (/api/webhook, /app/api/**/webhook).
• Check whether they use raw body verification.

Fix:

• Disable Next.js automatic body parsing only for those webhook routes, read raw bytes safely, verify signature, then parse.

NEXT-INJECT-001: Prevent SQL injection (use parameterized queries / ORM)

Severity: High

Required:

• MUST use parameterized queries or an ORM that parameterizes under the hood.
• MUST NOT build SQL by string concatenation / template strings with untrusted input.

Insecure patterns:

• db.query(`SELECT * FROM users WHERE id = ${id}`)
• "WHERE name = '" + user + "'"

Detection hints:

• Grep for SELECT, INSERT, UPDATE, DELETE strings.
• Trace untrusted input (params, searchParams, req.query, req.body, request.json()) into DB calls.

Fix:

• Use prepared statements / ORM query APIs.
• Validate and coerce types before querying.

NEXT-INJECT-002: Prevent OS command injection and unsafe subprocess use

Severity: Critical to High

Required:

• MUST avoid executing OS commands with attacker-controlled input.
• If subprocess is necessary:
  • MUST pass args as an array (not a single shell string)
  • MUST NOT use shell: true with attacker-influenced strings
  • SHOULD use strict allowlists for any variable component

Insecure patterns:

• exec("convert " + filename)
• spawn("bash", ["-c", userInput])
• spawn(userInput, ["foo"])

Detection hints:

• Search for child_process, exec, spawn, shell: true.

Fix:

• Use library APIs instead of shell commands.
• Hard-code commands and allowlist validated parameters (and use -- to separate flags where supported).

NEXT-INJECT-003: Avoid dynamic code execution and unsafe deserialization

Severity: High to Critical

Required:

• MUST NOT use eval, new Function, vm.runIn* on untrusted strings.
• MUST treat deserializing complex formats (YAML, XML, custom serialization) as risky; use safe parsers and strict schemas.

Insecure patterns:

• eval(req.body.code)
• Parsing YAML from user input with a non-safe schema.

Detection hints:

• Search for eval(, new Function, vm., require( with non-literals.
• Search for js-yaml, XML parsers, custom serializer usage on untrusted input.

Fix:

• Remove dynamic execution; use safe interpreters or strict parsers.
• Validate and constrain input.

NEXT-LOG-001: Logging MUST NOT leak secrets or sensitive headers

Severity: Medium

Required:

• MUST NOT log:

  • Authorization headers
  • cookies / session tokens
  • request bodies containing credentials
  • environment variables or configuration dumps

• SHOULD implement structured logging with redaction.

Insecure patterns:

• console.log(req.headers) in auth endpoints
• console.log(process.env) in server code

Detection hints:

• Search for console.log(, logger.info(, debug( in server routes/actions.
• Check for logs of headers/cookies/body.

Fix:

• Redact sensitive fields; log only what is needed for debugging.
• Use safe error messages for clients; keep detail server-side only.

NEXT-ERROR-001: Error handling MUST avoid leaking implementation details in production

Severity: Low

Required:

• MUST not expose stack traces or internal error details to end users in production.
• Ensure production mode behavior (Next.js production error handling differs from dev). ([Next.js][6])

Insecure patterns:

• Returning err.stack in JSON responses.
• Showing detailed exception data to unauthenticated users.

Detection hints:

• Search for res.status(500).json(err) or return Response.json(err).
• Verify error responses are sanitized.

Fix:

• Return generic error messages to clients; log details server-side with redaction.

NEXT-PROXY-001: Proxy/Middleware must not introduce header smuggling or unsafe header forwarding

Severity: Medium

Required:

• MUST be careful when copying/forwarding request headers upstream:

  • Do not forward attacker-controlled x-forwarded-* headers unless you have a trusted proxy chain.
  • Do not forward Authorization/cookies to unrelated outbound services.

• Next.js Proxy patterns often mutate headers; ensure this doesn’t create security issues.

Insecure patterns:

• Blindly cloning all request headers to an outbound fetch() call.
• Trusting x-forwarded-host or host to construct sensitive absolute URLs without allowlisting.

Detection hints:

• Search headers() and request.headers usage (especially for URL building). ([Next.js][4])
• Search Proxy/Middleware for header rewrites.

Fix:

• Allowlist forwarded headers explicitly.
• Validate hostnames before using them to build callback URLs or redirects.

NEXT-HOST-001: Host/Origin-derived URL construction MUST be allowlisted

Severity: Medium

Required:

• MUST NOT generate security-sensitive absolute URLs (password reset links, OAuth callback URLs, email verification links) directly from unvalidated Host headers.
• For Server Actions, Origin/Host matching is part of CSRF mitigation; do not weaken it. ([Next.js][5])

Insecure patterns:

• const base = "https://" + request.headers.get("host")
• Using unvalidated x-forwarded-host for absolute URL generation.

Detection hints:

• Grep for .get('host'), .get('x-forwarded-host'), and absolute URL building.
• Review auth-related email link generation code.

Fix:

• Use a configured, allowlisted canonical app origin (e.g., APP_ORIGIN=https://example.com).
• Allowlist hostnames; fail closed.

NEXT-DOS-001: Rate limiting and resource controls MUST exist for abuse-prone endpoints

Severity: Medium

Required:

• SHOULD implement rate limiting/throttling for:

  • login, password reset, signup
  • expensive Server Actions
  • webhook ingestion

• MUST implement request size limits (see NEXT-LIMITS-001).

• If self-hosting, MUST rely on reverse proxy for additional protections. ([Next.js][8])

Insecure patterns:

• No throttling on login/reset endpoints.
• Expensive actions callable without auth or with unlimited frequency.

Detection hints:

• Identify auth endpoints and check for rate limiting.
• Search for “send email”, “charge”, “generate report” flows.

Fix:

• Add edge rate limiting and app-level user/IP throttles.
• Add job queues for heavy work; return 202 when appropriate.

5) Practical scanning heuristics (how to “hunt”)

When actively scanning, use these high-signal patterns:

• Production misconfig:

  • next dev, NODE_ENV=development, dev-only start commands ([Next.js][7])

• Secrets exposure:

  • .env committed, NEXT_PUBLIC_ on sensitive variables ([Next.js][7])
  • process.env used in "use client" modules

• Auth coverage:

  • app/**/route.ts or pages/api/** with no auth checks ([Next.js][1])
  • "use server" actions with DB writes and no authz ([Next.js][6])
  • proxy.ts / middleware.ts matchers that exclude sensitive routes ([Next.js][12])

• CSRF:

  • cookie-auth POST/PUT/PATCH/DELETE with no token/origin checks
  • serverActions.allowedOrigins too broad ([Next.js][5])

• XSS:

  • dangerouslySetInnerHTML, raw HTML markdown rendering
  • missing CSP / overly permissive CSP ([Next.js][7])

• Caching/data leak:

  • dynamic = 'force-static' on sensitive GET handlers ([Next.js][1])
  • use cache, cacheLife, unstable_cache around user-specific data ([Next.js][1])

• Files:

  • writing uploads under public/
  • fs.readFile / path.join with request input

• SSRF:

  • fetch(userProvidedUrl) from Route Handlers / Server Actions

• Redirect:

  • redirect(searchParams.get('next')), NextResponse.redirect(...), res.redirect(req.query.next) ([Next.js][3])

• CORS:

  • wildcard origins, origin reflection, credentials + broad origins ([Next.js][3])

• Limits:

  • API routes with bodyParser: false and no raw-body verification for webhooks ([Next.js][3])
  • serverActions.bodySizeLimit raised without justification ([Next.js][5])

• Dependency hygiene:

  • old next versions that conflict with support policy/advisories ([Next.js][10])

Always try to confirm:

• data origin (untrusted vs trusted)
• sink type (HTML/DOM, SQL, subprocess, files, redirect, outbound HTTP)
• protective controls present (schema validation, allowlists, middleware/proxy checks, authz helpers, edge protections)

6) Sources (accessed 2026-01-27)

Primary framework documentation (

…(truncated)