Not sure if your app is leaking keys? Run a free scan first. VibeVigil checks your live app for exposed keys, Supabase tables without RLS, missing security headers, SSL problems and downtime. Every issue comes with a ready-to-paste prompt for your coding agent. Scan my app for free → (only scan apps you own)

How to Check if Your Vibe-Coded App Is Leaking API Keys

AI coding tools are great at making things work. Sometimes "working" means a secret key got pasted into code that runs in the browser. If that happens, anyone who opens your site can copy the key and use it. They can run up your AI bill, read your database, or send email as you.

This guide shows you how to check your own app in about 20 minutes. You don't need to be a developer.

The short answer

1. Open your live app, press F12 (or right-click and pick Inspect), and go to the Sources or Network tab.
2. Search all files for these words: sk_, sk-, sb_secret_, service_role, OPENAI, ANTHROPIC, STRIPE, RESEND, secret.
3. Anything that looks like a real secret key is a leak. Rotate that key today (see "If you find a leaked key" below).

Some keys are meant to be public. The next section shows you which ones.

Public keys vs. secret keys

Not every key in your code is a problem. Here is a quick guide:

Supabase's own docs put it simply: the publishable key is "safe to expose online," but secret keys "provide full access to your project's data, bypassing Row Level Security." (Supabase: API keys)

Heads up: Supabase says it is deprecating the old anon and service_role keys by the end of 2026, and moving to publishable (sb_publishable_) and secret (sb_secret_) keys. If an AI tool tells you to paste a long key that starts with eyJ, it is using the old style. (Supabase: API keys)

Step 1: Search the code your visitors download

Everything in the browser is public. Check it like a stranger would.

1. Open your live site in Chrome or Edge.
2. Press F12 and open the Sources tab.
3. Press Ctrl+Shift+F (Windows) or Cmd+Option+F (Mac) to search across all files.
4. Search for each of these, one at a time:

sk_live    sk_test    rk_live    sk-    sb_secret_    service_role
OPENAI     ANTHROPIC  GEMINI     RESEND    SENDGRID    secret    password

5. Also open the Network tab, reload the page, and click around your app. Look at the request headers. A secret key should never be sent from the browser.

If you find service_role inside a long eyJ... key, you can paste that key into a JWT decoder you trust offline. The role field will say anon (fine) or service_role (leak).

Step 2: Check your environment variable names

Most vibe-coded apps use Vite (Lovable, Bolt) or Next.js (v0, many Cursor apps). Both tools copy certain variables into the browser code on purpose:

• In Vite, any variable that starts with VITE_ ends up in the browser. (Vite: Env Variables and Modes)
• In Next.js, any variable that starts with NEXT_PUBLIC_ ends up in the browser. (Next.js: Environment Variables)

So open your .env file (or your host's environment settings) and look for names like these:

VITE_OPENAI_API_KEY          <- leak
NEXT_PUBLIC_STRIPE_SECRET    <- leak
VITE_SUPABASE_SERVICE_ROLE   <- leak
VITE_SUPABASE_PUBLISHABLE_KEY  <- fine

Rule of thumb: if a variable has a public prefix, it must hold only a public key.

Step 3: Make sure your .env file isn't public

Some hosts serve every file in your project folder. Try opening these in your browser, using your own domain:

https://your-app.com/.env
https://your-app.com/.env.local
https://your-app.com/.git/config

You should get a "not found" page or your normal app page. If you see text with keys or settings, the file is public. Rotate every key in it and block the file on your host.

Step 4: Check source maps

Source maps are files that turn your shrunk-down code back into readable code. They make debugging easy, but they also show your original code to anyone.

In the Sources tab, look for your original file names (like src/lib/openai.ts). If you can read them, your source maps are public. That's not always a disaster, but any secret in your source code is now easy to find. Turn source maps off for production unless you need them.

Step 5: Check your GitHub history

If your app syncs to GitHub (Lovable, Bolt and Cursor all can), a key might live in an old commit, even if the file is gone now. Deleting a file does not remove it from history. (GitHub: Removing sensitive data from a repository)

If you are comfortable with a terminal, run this in your project folder:

git log -p -S "sk_live" --all
git log -p -S "service_role" --all
git log -p -S "OPENAI_API_KEY" --all

Any result means the key was committed at some point. Treat it as leaked, especially if the repo is public or was ever public. Also make sure .env is listed in your .gitignore file.

GitHub has built-in secret scanning and push protection that can catch many keys before they land. Turn it on in your repo's Settings → Code security. (GitHub: About secret scanning)

If you find a leaked key

Do these in order:

1. Make a new key in that service's dashboard (Supabase, Stripe, OpenAI and so on).
2. Move the new key to the server. Put it in a backend function, like a Supabase Edge Function, a Next.js server route, or your host's server environment. Never give it a VITE_ or NEXT_PUBLIC_ name.
3. Update your app so the browser calls your server function, and your server function calls the paid service.
4. Turn off the old key once everything works with the new one. For Supabase, you make a new secret key, swap it in, then delete or deactivate the old one. (Supabase: Rotate a leaked key)
5. Check the bill and the logs for the service. Look for use you don't recognize. For AI keys, set a monthly spending limit if the provider offers one.

Removing the key from your code is not enough on its own. Anyone who copied it can still use it until you turn it off.

Paste this prompt into your coding agent

Works in Lovable, Bolt, v0, Cursor or Claude Code:

Audit my app for leaked API keys and fix it. Don't delete any data.

1. Search the whole project, including .env files and config, for secret keys:
   Stripe sk_/rk_, Supabase service_role or sb_secret_, OpenAI, Anthropic, Gemini,
   Resend, SendGrid, and anything named SECRET, TOKEN or PASSWORD.
2. List every environment variable that starts with VITE_ or NEXT_PUBLIC_ and tell me
   which ones hold a secret. Only public keys may use those prefixes.
3. Move every secret key to server-side code (a Supabase Edge Function or a server route).
   The browser must call my server, and only the server may call the paid API.
4. Make sure the frontend uses only the Supabase publishable (or anon) key, never the
   secret or service_role key.
5. Make sure .env and .env.* are in .gitignore and are not served by my host.
6. Turn off public source maps for the production build.
7. Give me a list of every key I need to rotate, with the dashboard where I rotate it.
8. Explain each change in plain English and tell me how to test that the app still works.

After the fix, repeat Step 1 on your live site. Your searches should come back empty, except for keys that are meant to be public.

Want this checked for you, plus RLS, headers, SSL and uptime? Run a free VibeVigil scan →

FAQ

Is it OK that my Supabase key is visible in my code? If it's the publishable (sb_publishable_) or anon key, yes. That's by design. Your RLS rules protect your data. See our guide on how to check if Supabase RLS is enabled. The secret or service_role key must never be in the browser.

My app is small. Would anyone really find my key? Bots scan public sites and public GitHub repos for keys all the time. It's not about how famous your app is. A key in public code should be treated as found.

I asked my AI to "hide" the key, and it put it in a .env file. Am I safe now? Not always. If the variable name starts with VITE_ or NEXT_PUBLIC_, the key still ends up in the browser. The key needs to live in server-side code.

I deleted the key from my code. Do I still need to rotate it? Yes. Old versions of your site, GitHub history, and anyone who copied it may still have it. Make a new key and turn off the old one.

Sources

• Supabase docs, API keys: https://supabase.com/docs/guides/api/api-keys
• Vite docs, Env Variables and Modes: https://vite.dev/guide/env-and-mode
• Next.js docs, Environment Variables: https://nextjs.org/docs/app/guides/environment-variables
• GitHub docs, Removing sensitive data from a repository: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
• GitHub docs, About secret scanning: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning

Not sure your app is safe? Run a free scan first. VibeVigil checks your live app for Supabase tables without RLS, exposed keys, missing security headers, SSL problems and downtime. Every issue comes with a ready-to-paste prompt for your coding agent. Scan my app for free → (only scan apps you own)

How to Check if Supabase RLS Is Enabled (and Actually Working)

If you built your app with Lovable, Bolt, v0 or Cursor, it probably talks to Supabase straight from the browser. That is normal. But it means one setting decides who can read and change your data: Row Level Security (RLS).

This guide shows you how to check it in about 15 minutes. You don't need to be a developer.

The short answer

Open the SQL Editor in your Supabase dashboard and run:

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

Any row where rowsecurity is false is a table with RLS turned off. Fix those first.

But "RLS is on" does not always mean "my data is safe". Keep reading for the other checks.

Why this matters

• Your Supabase anon (publishable) key sits in your frontend code. Anyone can find it. That is by design. Supabase expects RLS to protect your data, not the key being secret.
• Supabase's docs say a table in an exposed schema (like public) without RLS can be read and written by any role that has access to it, and that includes the anon key. (Supabase: Row Level Security)
• This is not a made-up risk. In 2025, CVE-2025-48757 described Lovable-built apps that leaked data because RLS was missing or too loose. (NVD: CVE-2025-48757)

Step 1: Look for the "Unrestricted" label

1. Open your project in the Supabase dashboard.
2. Go to Table Editor.
3. Look at the list of tables. A table with RLS off shows an Unrestricted label. Its tooltip says the table "can be accessed by anyone via the Data API as RLS is disabled."

Write down every table with that label.

Step 2: Run the Security Advisor

Supabase has a built-in checker.

1. In the dashboard, open Advisors → Security Advisor.
2. Click to run it and read every item.

These are the warnings that matter most for RLS (Supabase: Database Advisors):

You can also run the same checks from the terminal with the Supabase CLI: supabase db advisors.

Step 3: Read your policies (on is not the same as safe)

RLS can be on and still let everyone in. Run:

select tablename, policyname, roles, cmd, qual, with_check
from pg_policies
where schemaname = 'public'
order by tablename;

Look for these red flags:

• qual or with_check is just true. That rule lets every user through.
• roles is {public} or includes anon on a table with private data. That means logged-out visitors are allowed.
• An UPDATE rule with no with_check. A user could change a row so it belongs to someone else.
• A rule that uses user_metadata. Users can change that value.

A good rule for private data usually looks like "only the owner can see this row":

create policy "Users can read their own notes"
on public.notes for select
to authenticated
using ( (select auth.uid()) = user_id );

Step 4: Check who has access at all (grants)

Supabase has two layers: grants (can this role touch the table at all?) and policies (which rows?). Adding policies does not remove the default grants. Run:

select table_name, grantee, privilege_type
from information_schema.role_table_grants
where table_schema = 'public'
  and grantee in ('anon', 'authenticated')
order by table_name, grantee;

If anon has DELETE, UPDATE or INSERT on a table that logged-out visitors should never change, remove it (see the fix below).

As of October 30, 2026: Supabase now applies this to existing projects: new tables in public no longer get these grants automatically. You need to add a grant in the same migration where you turn on RLS. Tables you already had keep their current grants, so you still need to check them. (Supabase changelog)

Step 5: Check views and database functions

Two things can skip RLS even when every table is protected:

Views. By default, a Postgres view runs with the rights of the person who created it, so it ignores RLS. Find your views:

select c.relname as view_name, c.reloptions
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'v';

If reloptions does not include security_invoker=true (or on), the view skips RLS. On Postgres 15 and newer you can fix it with:

alter view public.my_view set (security_invoker = true);

Functions marked security definer. Functions in the public schema can be called through your API at /rest/v1/rpc/.... If one is security definer, it runs with full rights. Make sure logged-out visitors can't call it:

revoke execute on function public.my_function from public, anon;

Step 6: Test your own app like a stranger

Do this only on an app you own.

1. Open your app in a private (incognito) window. Don't log in.
2. Visit every page. Does any private data show up?
3. Create two test accounts. Log in as account A and add some data. Log in as account B. Can B see or change A's data?

If anything leaks, go back to Steps 3–5.

If you use Lovable

Lovable has a Security view. A quick scan runs on every publish and checks the database for tables without RLS and rules that let everyone through. You can also run a deep scan on demand. Lovable's own docs say these scans don't guarantee your app is fully secure, so still do Steps 3–6. (Lovable docs: Security)

How to fix it

Option A: fix it yourself in SQL

Replace notes and user_id with your table and owner column:

-- 1. Turn RLS on
alter table public.notes enable row level security;

-- 2. Remove access you don't need, then give back only what's needed
revoke all on table public.notes from anon, authenticated;
grant select, insert, update, delete on table public.notes to authenticated;

-- 3. One rule per action: users only touch their own rows
create policy "notes_select_own" on public.notes for select to authenticated
  using ( (select auth.uid()) = user_id );
create policy "notes_insert_own" on public.notes for insert to authenticated
  with check ( (select auth.uid()) = user_id );
create policy "notes_update_own" on public.notes for update to authenticated
  using ( (select auth.uid()) = user_id )
  with check ( (select auth.uid()) = user_id );
create policy "notes_delete_own" on public.notes for delete to authenticated
  using ( (select auth.uid()) = user_id );

If some data really is public (like a blog post list), give anon only select on that table, and write a select rule that shows only the public rows.

Option B: paste this prompt into your coding agent

Works in Lovable, Bolt, v0, Cursor or Claude Code:

Audit my Supabase database security and fix it. Do not delete any data.

1. List every table in the public schema and say whether Row Level Security is enabled.
2. Enable RLS on every table that doesn't have it.
3. For each table, tell me who should be able to read, insert, update and delete rows
   (logged-out visitors, any logged-in user, or only the row's owner). Ask me if unsure.
4. Revoke the default grants from anon and authenticated, then grant back only what each table needs.
5. Write one policy per operation using "to authenticated" and "(select auth.uid()) = user_id".
   Every UPDATE policy must have both USING and WITH CHECK. Never use USING (true) on private data.
   Never use user_metadata in a policy.
6. Make every view in public use security_invoker = true.
7. Revoke EXECUTE from anon and public on any SECURITY DEFINER function that visitors shouldn't call.
8. Confirm the service_role / secret key is not used anywhere in frontend code or VITE_/NEXT_PUBLIC_ variables.
9. Put all changes in one migration file and explain each change in plain English.
10. Tell me how to test it: logged out, and with two different user accounts.

After the fix, run the Security Advisor again (Step 2) and repeat the stranger test (Step 6).

Want this checked for you, plus exposed keys, headers, SSL and uptime? Run a free VibeVigil scan →

FAQ

Is it OK that my Supabase anon key is visible in my code? Yes. The anon (publishable) key is meant to be public. RLS is what protects your data. The service_role (secret) key is different: it skips RLS completely and must never be in your frontend.

I turned on RLS and now my app shows no data. Why? RLS with no policies blocks everything. That's safe, but your app needs rules. Add select rules for the data each user should see (Step 3).

My AI fixed an RLS error by writing USING (true). Is that OK? Usually not. That rule lets everyone through, which is the same as having no protection for that action. Replace it with an owner check like (select auth.uid()) = user_id.

What changed on October 30, 2026? For existing Supabase projects, new tables in public are no longer reachable from the API until you add a grant. Old tables keep their access, so check them with Step 4.

Lovable says my app passed its security scan. Am I done? It's a good start. Lovable itself says its scans don't guarantee full security. Do the policy, grants, view and stranger checks above too.

Sources

• Supabase docs, Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
• Supabase docs, Database Advisors (lints): https://supabase.com/docs/guides/database/database-linter
• Supabase changelog, breaking change for table grants (Oct 30, 2026): https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically
• Lovable docs, Security: https://docs.lovable.dev/features/security
• NVD, CVE-2025-48757: https://nvd.nist.gov/vuln/detail/CVE-2025-48757