Learn
Security

Are My Environment Variables Visible?

It depends on where they are used. Environment variables accessed in server-side code (API routes, Edge Functions) are hidden from users. But variables prefixed with NEXT_PUBLIC_, VITE_, or used in client-side code are bundled into your JavaScript and visible to anyone who opens DevTools.

Why this matters

Many builders assume all environment variables are secret. They are not. Frontend frameworks deliberately expose certain env vars to the browser — and if you put a secret API key in a NEXT_PUBLIC_ variable, it is visible to every visitor.

What's at stake

A secret key in a public environment variable is equivalent to hardcoding it. Anyone can extract it from your JavaScript bundle and use it to access your third-party services.

In detail.

How Environment Variables Work

Environment variables have two contexts: server-side and client-side.

Server-side variables are only available on the server (API routes, Edge Functions, server components). They never reach the browser and are safe for secrets.

Client-side variables are bundled into your JavaScript code during the build process. They are visible in the browser's DevTools under the Sources tab. Different frameworks use different prefixes to mark client-side variables:

  • Next.js: NEXT_PUBLIC_ prefix makes variables available in the browser
  • Vite/React: VITE_ prefix makes variables available in the browser
  • Create React App: REACT_APP_ prefix makes variables available in the browser

Rule of thumb: If a variable needs to stay secret, it must only be accessed in server-side code and must NOT have a public prefix. If it needs to be in the browser (like a Supabase anon key), it should be a key designed to be public.

What Is Safe to Expose

  • Supabase anon key (designed to be public, respects RLS)
  • Publishable Stripe key (can only create checkout sessions, not access data)
  • Public analytics IDs (Google Analytics, Plausible)

What Must Stay Server-Side Only

  • Supabase service role key (bypasses all security)
  • Stripe secret key (can access customer data and issue refunds)
  • OpenAI/AI provider API keys (can generate charges)
  • Database connection strings
  • Any key that grants write or admin access

Understand exactly which secrets are exposed in your app

  • Automated scan to detect secrets in client-side environment variables
  • Clear report showing which variables are public vs. private
  • Guidance on moving sensitive variables to server-side code
Get started with BWORLDS

Keep learning.

Related topics

did i expose my api keyhow to check if my secrets are leakedhow to check if my app is secureis my app safe to share

Frequently asked questions.

No, the .env file itself is never sent to the browser. But variables from your .env file that have a public prefix (like NEXT_PUBLIC_) are bundled into your JavaScript code during the build, making their values visible in the browser.

Yes. The Supabase anon key is designed to be public. It operates under Row Level Security policies and cannot bypass them. The key you must keep server-side is the service role key.

Open your deployed app in a browser, press F12 to open DevTools, go to the Sources tab, and search for your API key strings. Any key that appears there is visible to every visitor of your app.

Rotate the key immediately — generate a new one from the provider's dashboard and revoke the old one. Then move the variable to a non-public name and access it only from server-side code (API routes or Edge Functions).