Next.js security: check APIs, Server Actions and secrets

Locate the trust boundary

Client code is controlled by the caller. A server component or server action can use trusted server data, but its location does not automatically enforce authorization. Identify every entry point that accepts user input or returns private information, including endpoints called outside the rendered UI.

Authorize Server Actions and Route Handlers

Verify the session and object permissions inside each relevant server operation. The executable fixture uses a local synthetic identity header solely for testing; production must use a verified session. Its Route Handler invokes a server function and compares cross-owner access before and after an ownership check.

const actor = await requireSession();
const document = await db.document.findUnique({ where: { id } });
if (!document || document.ownerId !== actor.id) throw new Error("Forbidden");

Primary sources: Primary reference 1 · Primary reference 2

Continue: Exposed .env, .git or API keys: contain the leak and verify the fix

Return only the data the browser needs

Build a minimal response DTO after authorization. Do not return internal notes, secrets or a full database record merely because a client ignores those fields. Inspect serialized responses and page data, not just visible text. Our fixture verifies that its synthetic internal field never appears in a response.

Treat NEXT_PUBLIC variables as public

Values intentionally exposed through NEXT_PUBLIC belong in client builds. Server-only environment variables must not leak through a DTO, rendered HTML, logs or error messages. Changing an environment variable may require rebuilding or redeploying the component that embeds it; verify the actual release artifact.

Primary sources: Primary reference 1 · Primary reference 2

Continue: IDOR and BOLA: test access to another user’s data

Test private caching behavior

Test consecutive requests from A and B and an anonymous client. Private responses must not be served across identities through an inappropriate shared cache. Review the exact framework APIs and deployment configuration in use, and inspect cache-related headers alongside returned content.

Track framework and dependency versions

Record the actual deployed Next.js version and dependency inventory. A framework advisory is relevant only when its version and preconditions match. Updating a manifest without deploying the new build does not fix the running service. Retest the original scenario after the release.

Primary sources: Primary reference 1 · Primary reference 2

Continue: Monitor CVEs and dependencies in your application

Use a reproducible release checklist

Build the supplied isolated fixture, run the documented requests and verify 200 for the vulnerable cross-owner branch, 403 after the fix, 200 for an owner and 401 without a recognized test identity. This checks a Route Handler calling a server function; it does not claim full browser Server Action protocol coverage.

Keep the checks in your workflow

Preserve the tested commit, fixture identities and expected outcomes. Add the supported HTTP scenarios to staging and release checks. Separate source review from dynamic scanning, and review skipped checks when a deployment changes routes, responses or authorization behavior.

Continue: Add security checks to CI/CD and GitHub Actions

Reproducible examples and downloads

Tested with: guides-1 · Next.js 16.4.3

All example data is synthetic. Downloads contain no active keys or customer records. Run examples only in your own isolated test environment.

• next-fixture.zip — example / template
• launch-checklist.csv — example / template

Example verification record: versions, actions and observations

Questions and answers

Editorial team and sources

Scantelio editorial team: methodology and limitations. Example verified: 2026-11-02.

• Reference 1 · nextjs.org
• Reference 2 · nextjs.org