It might, and it is easy to check. Anything your website sends to a visitor's browser can be read by that visitor — including API keys that were written into the front-end code. Apps built quickly with AI tools such as Lovable, Bolt, Replit and Cursor are especially prone to this, because a key that works in the browser looks exactly like a key that is safe in the browser.
Which keys are safe to have in a website, and which are not?
Some keys are designed to be public; others must never leave a server.
| Safe in the browser | Never in the browser |
|---|---|
| Supabase anon / publishable key (with row-level security on) | Supabase service_role key |
Stripe publishable key (pk_...) | Stripe secret key (sk_...) |
| Firebase web config | AWS access keys (AKIA...) |
| Google Maps key restricted to your domain | OpenAI, Anthropic and other AI API keys |
| GitHub tokens, database passwords |
A secret key in your website lets anyone who finds it act as your app: run up your AI bill, charge or refund through your Stripe account, or read and delete your database.
Why do AI-built apps leak keys?
Mostly through environment variables. In Vite, Next.js and Create React App, variables whose names start with VITE_, NEXT_PUBLIC_ or REACT_APP_ are copied into the JavaScript your visitors download. A secret key placed in one of them is published with your site, even though it lives in a .env file.
Is my Supabase database open?
The Supabase anon key is meant to be public — as long as row-level security (RLS) is enabled on every table. Without RLS, anyone with that public key can read, and often change, the whole table. Check in the Supabase dashboard that RLS is on for each table and that each table has policies allowing only what your app needs.
How do I check my app myself?
- Open your live site, then your browser's developer tools (F12).
- In the Sources (or Debugger) tab, search all files for
sk_,service_role,AKIA,secretandapi_key. - Check whether your site publishes source maps (
.js.mapfiles): they hand out your original code, comments and all.
Or run the free scan at qopanza.com/scan: paste your site's address and it reads the JavaScript your site actually sends, checks for exposed keys, open Supabase tables, published source maps and missing security settings, and explains each finding in plain English. No account needed.
I found a leaked key. What now?
- Replace the key first, in the dashboard of the service that issued it (Stripe, OpenAI, Supabase, AWS and so on). Removing it from your code is not enough: anyone who already copied it can keep using it until it is replaced.
- Move the call to a server, for example a Supabase Edge Function or a serverless function, so the new key never reaches the browser.
- Turn on row-level security for every Supabase table.
Qopanza's step-by-step fix tells you exactly where to replace each key and what to change in your app, and on Pro, Fix it for me can make the code and hosting changes for you after you approve them. Start with the free scan.