Exposed API keys in Lovable apps
A secret key is meant to stay on your server. When it ends up in the code the browser downloads, anyone who opens your app can copy it and act as you. This page scans your live app for keys that should not be there.
Scan your Lovable app for exposed keys
What it means
A password-like key that is supposed to stay private is sitting in your app where other people can find it. Anyone who copies it can act as you — run up bills, read your data, or send email in your name.
Why AI tools cause it
AI coding tools often paste an API key straight into a file to make something work, instead of hiding it in a private environment variable. It runs fine, so nothing warns you.
How xlogs checks it
xlogs scans your live JavaScript against 9 key formats covering Stripe, OpenAI, Anthropic, AWS, Google, GitHub, Slack, private key blocks, and Supabase service_role tokens.
How keys end up exposed
To make a feature work, an AI tool will sometimes paste a key directly into a file instead of hiding it in a server-only environment variable. The app runs fine, so nothing warns you. If that file is part of the frontend, the key ships to every visitor.
The scan reads your live JavaScript the way a visitor's browser does and matches it against known key formats for Stripe, OpenAI, AWS, Google, Supabase, and more. A public Supabase anon key is expected and is not flagged. A secret or service key is.
How to fix it
The goal: The key is stored only in a server-side secret / environment variable, never in code or the client bundle, and the exposed value has been rotated (regenerated) because the old one is public.
- Move the key's value into a server-only environment variable
- Remove the literal value from the code and any client-side bundle (the affected spot)
- Make sure the .env file is in .gitignore
- Rotate (regenerate) the key at the provider — assume the old one is compromised
In my app (the spot the scan shows): a secret key is exposed. Please make this true: The key is stored only in a server-side secret / environment variable, never in code or the client bundle, and the exposed value has been rotated (regenerated) because the old one is public. Steps: Move the key's value into a server-only environment variable; Remove the literal value from the code and any client-side bundle (the spot the scan shows); Make sure the .env file is in .gitignore; Rotate (regenerate) the key at the provider — assume the old one is compromised. Then tell me exactly what you changed, and do not print any secret values back to me.
Then verify: After you deploy the fix, xlogs re-scans your live app and your files and confirms the key is no longer present.
Full step-by-step fix guide, with a copy-paste block for each AI tool →
Common questions
Which keys are dangerous to expose?
Any secret key: a Stripe secret key, an OpenAI key, an AWS key, or a Supabase service_role key. These let the holder spend money, read data, or act as your backend. A public key that is designed to ship (like the Supabase anon key) is fine.
I found an exposed key. Is moving it to an env var enough?
No. Assume the exposed value is already compromised. Move it to a server-only environment variable, remove it from the code and the client bundle, and rotate (regenerate) it at the provider so the public copy stops working.