Q272: Secrets Exposure Environment Variables and Frontend Boundaries

What Interviewers Want To Evaluate

Interviewers want to know whether you understand that frontend bundles are public.

They want to hear about environment variables, build-time injection, public prefixes, server-only secrets, CI logs, source maps, analytics keys, and what to do when a secret leaks.

Short Interview Answer

Secrets must not be shipped to the browser. Frontend environment variables are often embedded at build time if they are referenced in client code, and frameworks may expose variables with public prefixes intentionally. I separate public configuration from secrets, keep secrets in server-only runtime environments, avoid logging them in CI or telemetry, audit source maps and bundles, and rotate any credential that may have been exposed.

Detailed Interview Answer

The browser is not a secret keeper.

Anything shipped to the client can be inspected:

JavaScript bundles
source maps
HTML
network requests
localStorage
sessionStorage
IndexedDB
cookies without HttpOnly
console logs

If a value must remain secret, it cannot depend on browser secrecy.

Public Configuration

Some values are public by nature:

public analytics ID
public API base URL
feature flag client key
Sentry DSN
publishable payment key
build version
environment name

These are not always harmless, but they are not secrets.

They should be scoped, rate-limited, and safe to expose.

Real Secrets

Real secrets include:

database URLs
private API keys
service tokens
signing keys
refresh tokens
webhook secrets
cloud credentials
admin tokens
private OAuth client secrets

These belong server-side.

If client code needs an action requiring a secret, call a server endpoint that performs the action after authorization.

Build-Time Injection

Many frameworks replace environment variable references during build.

That means:

if client code imports it, it may end up in the bundle
if a variable has a public prefix, it is intended for client exposure
if a secret is used in static generation, build logs may reveal failures

In Next.js, public variables are commonly prefixed for client use.

Server-only values should stay in Server Components, Route Handlers, Server Actions, or deployment environment settings.

CI and Logs

Secrets can leak through:

console output
failed commands
debug dumps
test snapshots
artifact uploads
build cache
crash reports
analytics payloads
source maps

Masking helps but is not enough.

Do not print secrets.

Scope CI tokens narrowly.

Source Maps

Source maps help debugging.

They can also expose source structure.

If source maps are public, verify they do not include hardcoded secrets.

Private upload to an error-monitoring provider is often safer than public source maps.

Still, the main rule is simple:

do not hardcode secrets in source code.

Secret Rotation

If a secret leaks:

revoke or rotate it
identify exposure window
inspect logs for use
deploy new configuration
remove leaked value from history where appropriate
notify stakeholders if needed
document incident
add prevention checks

Do not only delete the line from code.

The old secret may already be copied.

Frontend Boundary Design

When the frontend needs a protected operation:

frontend sends user intent
server authenticates user
server checks authorization
server uses secret
server returns safe response

Examples:

create payment session
send email
generate signed upload URL
query private provider API
create AI completion

The frontend should never receive the provider secret.

Interview Example

If asked, "Can we put an API key in the React app?"

Answer:

"Only if it is a publishable client key designed for browser exposure. If it grants privileged access, it must stay server-side. I would create a backend endpoint or server action that validates the user and performs the privileged call using the secret."

Common Mistakes

Common mistakes include:

assuming env vars are automatically secret
using private keys in client components
printing env objects in CI
hardcoding tokens for quick demos
putting refresh tokens in localStorage
making source maps public without review
not rotating leaked credentials
using one broad token for every environment

Senior-Level Framing

The senior framing:

"I treat frontend code as public. Secrets live behind server-side authorization boundaries, and any exposed credential must be scoped as if users can inspect it."

Practice Prompt

Classify these values:

NEXT_PUBLIC_ANALYTICS_ID
DATABASE_URL
payment publishable key
payment secret key
Sentry DSN
OAuth client secret
signed upload URL
feature flag client key

For each, decide public or secret, storage location, and rotation strategy.

Final Mental Model

Environment variables are not magic.

Where a value is used determines whether it stays private.

If the browser can use it directly, the user can probably see it.