Beyond the Supabase key, Lovable can inline other third-party API keys, for payments, email, or AI services, directly into generated code. If that key reached the browser bundle or your repo, treat it as compromised. Rotate it first, then move it so it is only used server-side rather than shipped to the client.
Why it's a problem
A key placed in Lovable's client code is downloaded by every visitor and can be read from the browser, and a key in a public repo is scraped within minutes. Depending on the service, an exposed key means someone can spend your money, send email as you, or run up API bills, all while the app keeps working normally.
How to fix it, in order
- 1Rotate the key. Revoke and regenerate it at the provider; the exposed value is already out.
- 2Check for unauthorized use. Review the provider's usage and billing for activity or charges you did not make.
- 3Move the call server-side. Use the key only in a server function or edge function, so it is never in the client bundle. Lovable supports server-side functions for exactly this.
- 4Store it as a secret. Keep the key in an environment variable or Lovable's secret storage, not inline in generated code.
Why Lovable does this
When an integration needs a key, the quickest way to make the generated app work is to place the key where the client code can reach it. Lovable produces a running app, and the key ships with it unless you move it to a server-side location.
Stop it happening again
Route third-party API calls through server-side functions, keep keys in secret storage, and scan the app for inline secrets before you publish it.
The quick fix
- Rotate the key first.
- Check provider usage and billing for unauthorized use.
- Move the API call to a server or edge function.
- Store the key as a secret, never inline in client code.