Are my environment variables public?

Also searched as: .env file exposed · Vite expose environment variables · Secrets exposed as environment variables

Updated 3 October 2026

Short answer

Some of them are, by design. Any setting your frontend reads is bundled into the JavaScript every visitor downloads. In Vite apps that's every variable starting VITE_; in Next.js, every one starting NEXT_PUBLIC_. That's fine for things meant to be public, such as your site's address or a publishable key. It's a leak for anything secret. Separately, check that your .env file itself can't be downloaded from your site.

What's the problem

You were told to keep keys out of the code and put them in environment variables, so you did. But the app still works in the browser with those keys, which means the browser has them. And anything the browser has, anyone can read.

Why it happens

  • "Environment variable" doesn't mean secret. On a server, environment variables stay on the server. In a frontend build, the build tool copies the values into the code it produces, so they ship to every visitor.
  • The prefixes are the switch. Vite only exposes variables starting VITE_, and Next.js only those starting NEXT_PUBLIC_. Developers often add the prefix to make an error go away, and with it publish the secret.
  • The .env file is in the wrong place. If it sits in the folder your web server serves, anyone can request yoursite.com/.env and download it.

How to fix it

  1. List every variable your frontend uses. Search the code for import.meta.env.VITE_ and process.env.NEXT_PUBLIC_, or your framework's equivalent.
  2. Sort them into public and secret. Public: site addresses, publishable keys designed for browsers, analytics IDs. Secret: anything that grants access, spends money, or bypasses security, such as service keys, database passwords and AI or payment API keys.
  3. Move every secret behind your server. The browser calls your backend or a serverless function, which holds the key and makes the call.
  4. Rotate every secret that was ever exposed. Removing it from the code isn't enough. Someone may already have it.
  5. Check yoursite.com/.env returns "not found", and that .env is listed in .gitignore so it never reaches the repository.

When to call Preventionlabs

If two or three variables need moving and you have a backend, that's an afternoon. Call us when there's no server side to move them to, when secrets run through the whole frontend, or when you're not sure what's exposed. Data exposure is on the MVP-level protection checklist in every resurrection, and it's checked the way an attacker would check it: by reading what your site sends to the browser.

Submit your project for a free assessment

Free assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.

Sources

  1. Vite: Env Variables and Modes: Protecting secretsbuild tool docsVITE_* variables should not contain sensitive information such as API keys.
  2. Vite: Env Variables and Modesbuild tool docsThe values of these variables are bundled into your source code at build time.
  3. Next.js: Environment Variablesframework docsIt will be inlined into any JavaScript sent to the browser.
  4. Next.js: Environment Variablesframework docsNon- NEXT_PUBLIC_ environment variables are only available in the Node.js environment, meaning they aren't accessible to the browser
  5. Supabase: API keysplatform docsNever put one in a browser, a shipped application, or source control.

Related

I leaked an API key. What do I do? Revoke it and create a new one now, before anything else. Deleting it from the code doesn't help: it's still in the history. Then check what it was used for. Supabase RLS is disabled. Is my data public? A table in an exposed schema without Row Level Security is readable and writable through your public key, which is in your app. Turn RLS on for every table. Is my AI-built app secure? Don't assume so. Research found people using AI assistants wrote less secure code and were more confident in it. Check access control, keys and data first. How do I check my app is secure before launch? Check what attackers try first: who can see whose data, logins, open keys and databases, injection, payments, rate limits, HTTPS and old dependencies.
← All of Is it safe?