Check public environment variables before trusting a Next.js build

Next.js environment variables are server-side by default, but variables prefixed with NEXT_PUBLIC_ can be inlined into browser JavaScript at build time. To check exposure, review how the variable is used, build with an unmistakably fake marker, and inspect what the browser receives. A variable’s name is a starting point; the delivered value is the evidence you need.

Public: Treat a value used through NEXT_PUBLIC_ as suitable for browser disclosure.
Server-only: Keep confidential values on the server and check whether application code sends them outward.
Build: Changing the runtime environment does not automatically replace a value already inlined into a client build.

This is a documentation-based field manual, not a completed production experiment. Evidence reviewed: 2026-09-09, from the supplied packet reviewed at 2026-09-09T09:20:58+09:00. Test status: not performed. The proposed conditions are an isolated project copy, fake values, and the project’s documented build and serving commands.

The useful receipt is a documented boundary

The supplied Next.js environment-variable documentation establishes the distinction behind this review:

• Environment variables are server-side by default.
• Variables prefixed with NEXT_PUBLIC_ can be inlined into browser JavaScript at build time.
• A later runtime environment change does not automatically rewrite those inlined values.

Those are documented behaviors, not findings from a tested installation. They support a practical decision: a confidential value does not belong in a public variable.

The remaining question is application-specific. Does the project reference the variable in browser-bound code? Does server code put its value into a response? Which build artifact is actually being served?

Treat the public prefix as permission to disclose the value.

Start with what each value is allowed to reveal

Before running anything, make an inventory of variable names and their references. Record names and purposes; leave genuine secret values out of the worksheet.

For a hypothetical convenience-store offers app, a public display label might be harmless. A credential authorizing access to its private data service would need a different boundary.

Ask a plain question for each entry: Would it be acceptable for a visitor to copy this value?

Then trace the references. Find where the value enters the application, where it is read, and whether it reaches rendered content or a response. A server-side default does not establish that every later use stays private.

Use this copyable decision table:

Make the evidence unmistakably fake

Use markers that cannot be confused with credentials. These examples are hypothetical and have not been executed:

NEXT_PUBLIC_REVIEW_MARKER=FAKE_PUBLIC_MARKER_BUILD_AMBER
REVIEW_SERVER_MARKER=FAKE_SERVER_MARKER_PRIVATE_BIRCH

The distinct strings make the intended boundaries easy to follow. Neither marker should grant access to anything.

In an isolated review copy, connect the public marker to a temporary visible label in the browser interface. Use an explicit reference so the intended test path is easy to inspect:

<span>{process.env.NEXT_PUBLIC_REVIEW_MARKER}</span>

Keep the server marker in a server-side path. Do not deliberately return it to the browser as part of the test; that would create the disclosure you are trying to investigate.

If the project requires a working credential to start, document that limitation. Do not substitute a real credential merely to make this exercise appear complete.

Inspect the artifact the visitor actually receives

Follow the project’s documented installation and build procedure. Record the build command, serving command, runtime, relevant configuration, and marker names in your worksheet.

Use the resulting production build for this check. A development-session observation should not stand in for evidence about the deployed artifact.

Open the relevant page and inspect the browser-delivered material:

• Search loaded JavaScript for the exact public marker.
• Inspect page content and document responses.
• Inspect application responses triggered by the feature under review.
• Search the same material for the server marker.

Exercise the routes that reference these variables. Record which routes and interactions you covered instead of describing a partial check as site-wide verification.

A public marker found in browser-delivered JavaScript is evidence of exposure in that artifact. A server marker found in a response identifies a path to investigate.

A missing search result has a narrower meaning: you did not find that exact marker in the material inspected. It does not establish that every route or configuration is safe.

Evidence caption template: Browser inspection showing the fake marker, the resource containing it, and the route exercised. Capture only fake values; omit credentials and account details.

Finding a marker proves its presence; missing it does not prove universal absence.

Change the environment without confusing it with the build

To examine build-time behavior, preserve the existing artifact and change only the public marker in the serving environment:

NEXT_PUBLIC_REVIEW_MARKER=FAKE_PUBLIC_MARKER_RUNTIME_CEDAR

Serve the unchanged artifact again using the project’s supported procedure. Inspect the same route and resources.

The documented expectation applies specifically to values already inlined into the client build: changing the runtime environment does not automatically rewrite them. Record what appears rather than filling the worksheet with the expected answer.

Next, create a fresh build with the changed marker available during building. Inspect that artifact separately.

Keep the artifact identity alongside every observation. If results differ from expectations, check whether you inspected the intended build, whether the reference was included, and whether the runtime follows the documented behavior. An unexplained result is a reason to investigate, not a compatibility verdict.

Keep failures and unanswered questions visible

There are no verified failed installations, leaked credentials, or successful customer tests in the supplied evidence. The failure modes here are review risks, not reported incidents.

A prefix-only review can overlook application code that returns a server value. A runtime-only edit can leave an already inlined public value unchanged. A browser search covering only the landing page can leave other routes unexamined.

Use this reusable record:

Review date:
Project runtime and configuration:
Installation instructions consulted:
Build and serving commands:
Artifact inspected:
Variable name and intended visibility:
Fake marker:
Routes and interactions checked:
Browser resource or response inspected:
Observed result:
Unexamined paths and limitations:
Decision and required follow-up:

A useful receipt names the artifact, the observation, and the limits.

Make the source-purchase decision after the free check

The final decision is conditional: public variables must contain intentionally public values, confidential values need inspected server boundaries, and build-time settings need verification against the artifact being delivered.

As an optional purchasing example, the Saju source product and installation guide describes a Korean Saju web-app source license for one project. Consult that page for current deliverables and installation requirements. Its description does not prove customer installation or compatibility with every Next.js runtime.

The immediate action is free: copy the worksheet and trace a variable through your actual project using fake markers.

Related build logs

• AI Content Review Checklist: Check Facts, Context, and Permissions