Is your API key in your JavaScript? VITE_ and NEXT_PUBLIC_ explained

Milo Kits — Sun, 25 Oct 2026 06:39:46 +0000

If your code reads an API key through a variable starting with VITE_, NEXT_PUBLIC_ or REACT_APP_, that key is in your public JavaScript and anyone can copy it. An environment variable keeps it out of your Git repo, not out of the browser: the build tool pastes the value into the bundle.

Why the prefix matters

Vite (Lovable, Bolt): VITE_ variables are exposed in client code, and the Vite docs say they shouldn't hold secrets.
Next.js (v0, many Cursor projects): NEXT_PUBLIC_ variables are inlined into the browser JavaScript at build time.
Create React App: same for REACT_APP_.

Hardcoding a key in a component is the same problem. If the browser runs the code, the browser has the key.

Safe in the browser vs secret

Usually fine in frontend code	Never in frontend code
Supabase anon / `sb_publishable_` key (with RLS)	Supabase `service_role` / `sb_secret_`
Stripe `pk_live_...`	Stripe `sk_live_...` or `rk_...`
Firebase web config	Firebase Admin service account JSON
Map keys restricted by domain	OpenAI, Anthropic, Gemini, Resend, Twilio, AWS keys, database URLs

Check your live site in two minutes

Open your live site, then DevTools (F12) > Sources. Press Ctrl/Cmd+Shift+F to search all files.
Search for: sk-, sk_live, rk_live, service_role, sb_secret_, AKIA, re_, SG., -----BEGIN.
In the Network tab: if the browser calls api.openai.com directly, the key is in the browser.
Locally, after npm run build, search dist/ or .next/ for the same strings.

The fix: call the API from the server

The browser calls your own endpoint (an API route, serverless function or Supabase Edge Function), and that endpoint calls the third-party API with a key from a server-only env var. Add a login check and a rate limit so it doesn't become a free proxy.

My [SERVICE] API key is exposed in my frontend (read from [VARIABLE] in [FILE]). Please: 1) create a server-side endpoint that reads the key from a server-only env var with no public prefix, 2) remove the key and the prefixed variable from all client code, 3) make the frontend call the new endpoint, require a logged-in user and add a per-user rate limit, 4) show me the diff and where to set the env var on my host.

Already leaked? In this order

Rotate the key in the provider's dashboard.
Set a spending limit or usage alert.
Check the provider's usage logs.
Deploy the server-side fix.
If it was ever committed to Git, treat it as public even after deleting the file.

Free pre-launch checklist (14 checks to run before you share your link): https://milokits.com/checklist?ref=devto

We make Milo's Launch Check, a passive outside-in check for AI-built apps that also looks for keys in your bundle. Launch week: Quick Check $19 instead of $29 until 1 November (code QUICK19): https://milokits.com/?ref=devto#pricing

How to test Supabase RLS with two accounts (10 minutes, no tools)

Milo Kits — Sun, 25 Oct 2026 06:39:38 +0000

To test Supabase Row Level Security (RLS), create two test users, add data as user A, then try to read and change it as user B and as a logged-out visitor. If B or a stranger gets A's rows, your policies are too loose. If A can't see their own rows, a policy is missing.

What you need

Your own app, live or on staging with the same database rules.
Two test accounts you create: A and B.
Two browsers, or one normal and one private window.

Step 1: Create data as user A

Sign in as A and create one of everything your app stores: a project, a note, an upload. Open DevTools > Network, reload, and find the request to /rest/v1/.... Note the table and the row id.

Step 2: Try to read A's data as user B

Change the ID in the URL. Open A's page address with A's id. B should get an empty page or an error.
Replay the request. Right-click a similar /rest/v1/ request > Copy as fetch, paste it in the Console and change the filter to id=eq.<A's id>. B should get [].
Ask for everything. Replay without a user filter. B should only see B's rows.

Step 3: Try to change A's data as user B

Replay an update or insert with A's user_id in the body. It should fail or change 0 rows. If B can insert a row with A's user_id, the insert policy is missing with check (auth.uid() = user_id).

Step 4: Repeat logged out

Your public key is in the page, so a stranger can send the same request. Private tables should return [] or a permission error.

Step 5: The SQL editor way (optional)

The SQL editor normally bypasses RLS, so a plain select proves nothing. Impersonate a user and roll back:

begin;
set local role authenticated;
set local request.jwt.claims = '{"sub": "USER_B_UUID", "role": "authenticated"}';
select * from public.your_table where user_id = 'USER_A_UUID';  -- expect 0 rows
rollback;

Step 6: What RLS doesn't cover by itself

Views run as their owner unless created with security_invoker = true.
security definer functions run with their owner's rights. Call them as B with A's id.
Storage has its own policies. As B, open A's file URL. Private files should need a signed URL.

If a test fails

Paste this into your AI coder:

I tested my Supabase app with two users. User B could [read / change] user A's rows in [TABLE / VIEW / FUNCTION / BUCKET]. Please: 1) show me the current policies, 2) rewrite them so each user can only select, insert, update and delete rows where user_id = auth.uid(), with a matching WITH CHECK, 3) set views to security_invoker = true and check auth.uid() inside any security definer function, 4) give me the SQL and the two-account test to confirm the fix. Don't run anything until I say so.

Only test apps you own, with test accounts you created.