What is secrets management?
An API key in the browser, a password in the repository, a token nobody can rotate: the leaks that need no hacker at all.
In short
Secrets management is the practice of keeping an application's credentials, such as API keys, database passwords and OAuth tokens, out of code and out of the browser. Secrets are stored encrypted, given only to services that need them, rotated after a leak, and audited.
Also called: API key management
How do secrets leak from a prototype without any hacker?
In a prototype it is easy for a key to end up where it should not: pasted into client code so a feature works, committed to the repository, shared in a chat. Anything sent to the browser can be read by anyone who opens the developer tools.
Anything in the repository history stays there even after the line is deleted.
Which rules should every app follow for its secrets?
Four rules cover most apps: keep secrets in environment variables or a secrets manager, never in code; give the browser only keys designed to be public; give each service only the secrets it needs; and make every secret rotatable without an outage, rotating it when someone leaves or a leak is suspected.
- Secrets live in environment variables or a secrets manager, never in code.
- The browser only ever gets keys designed to be public.
- Each service gets only the secrets it needs.
- Every secret can be rotated without an outage, and is rotated when someone leaves or a leak is suspected.
Which Supabase keys are safe in the browser, and which are not?
Supabase gives every project two kinds of key. The publishable key, which replaces the older anon key, is meant for browsers and mobile apps, and row-level security limits what it can reach. The secret key, which replaces service_role, bypasses row-level security entirely, so it belongs only on servers and in Edge Functions.
| Key | Where it may go | What it can reach |
|---|---|---|
| Publishable (sb_publishable_…) | Browser, mobile app | Only what RLS policies allow |
| Secret (sb_secret_…) | Server, Edge Functions | Everything; it bypasses RLS |
Supabase blocks secret keys sent from a browser, but its docs say to treat any exposure as a leak anyway. The full comparison is in anon key vs service role key, and the exposed key checker looks for keys shipped in your front end.
How do you handle secrets in a Lovable app?
Lovable's docs say front-end code runs in the browser, so keys cannot be stored there safely. If you paste an API key into chat, Lovable detects it and points you to its Secrets store. The recommended pattern is server-side code that reads the key from Secrets, called from the front end.
- Move every third-party key into Lovable Secrets or your host's environment variables.
- Call paid or private APIs from server code, never directly from the browser.
- Run Lovable's deep scan, which looks for secrets left in source code or the repository.
- Turn on secret scanning in GitHub, which checks the whole git history on all branches.
What should you do when a secret leaks?
Rotate it straight away; deleting the line is not enough, because git history keeps it. Supabase's order is the safe general pattern: create a new key, replace the old one everywhere it is used, confirm every component uses the new key, then delete or deactivate the old one.
Check logs for use in between. If you have inherited an app with keys in odd places, our vibe-coding rescue covers exactly this clean-up.
Common questions
Are environment variables secure?
They keep secrets out of code, which is the first step. On the server they are fine; any variable bundled into the front end is public. Only keys designed to be public belong in the browser, and each service should get only the secrets it needs.
Is it safe to put the Supabase anon key in my front end?
Yes, that key is designed to be public. Supabase's publishable key, which replaces the anon key, is safe in browsers and mobile apps because row-level security limits what it can reach. That only holds if RLS is enabled with sound policies on every exposed table.
What should I do if I committed an API key to GitHub?
Rotate the key immediately: create a new one, swap it in everywhere, then revoke the old one. Deleting the line or the commit does not help, because git history and any clones keep it. GitHub secret scanning checks the full history and raises an alert.
Where should a Lovable app store its API keys?
In Lovable's Secrets store, read by server-side code, never in front-end code. Lovable's docs say browser code cannot hold keys safely, and the tool detects keys pasted into chat and points you to Secrets. Its deep scan also looks for secrets left in source.
Go deeper
Vibe coding security risks, and how to fix themThe security risks of vibe coding: exposed data, leaked keys, trusting the browser, fake packages and unsafe AI features, with a test and a fix for each.
Related terms
Read next
Sources
- OWASP Secrets Management Cheat Sheet
- The Twelve-Factor App: III. Config
- Supabase docs: Understanding API keys
- Lovable docs: Security
- GitHub docs: About secret scanning
Sources checked October 24, 2026
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
