Lovable API key exposed: what to do now

As of October 10, 2026, if a secret API key from your Lovable app has leaked, revoke or rotate it at the provider first, then find how it leaked and move it into a server-side secret before you issue a new one. Some keys are meant to be public: the Supabase publishable (anon) key and the Stripe publishable key are safe in browser code. Others are not: the Supabase secret or service role key, Stripe secret and restricted keys, and AI keys from OpenAI, Anthropic or Google. Deleting a key from your code does not delete it from your git history or from anyone who already copied it. Only revoking it ends the risk.

This guide is for founders who have just had a surprise bill, an alert or a worrying message from a developer. It covers which keys are safe where, the first hour, how to tell whether the key was abused, and how to move it server-side in Lovable. Platform facts come from Lovable, Supabase, Stripe, OpenAI, Anthropic, Google and GitHub documentation, listed under Sources.

Which keys are safe to have in a Lovable app's browser code?

Anything your app's screens use is downloaded to every visitor's browser, where anyone can read it. Lovable's security guide says secrets stored in frontend code are visible to users and should be considered compromised. Its Secrets documentation adds that values prefixed VITE_ live in the project's .env file and are built into the browser code, while the Secrets manager is for backend values only. So the question is simple: was this key designed to be public?

Some keys, such as a maps key, are built for the browser. Lovable's integration guide recommends domain restrictions on any key used in browser code, so it only works on your site. Our entry on the Supabase anon key vs service role key explains the Supabase pair in more depth.

How do you know a key has leaked?

Usually someone tells you. Several providers watch for leaked keys and act on their own:

• OpenAI's help center says it disables a key immediately when it detects it on the public internet or inside an app in an app store.
• Anthropic says GitHub notifies it when a Claude API key appears in a public repository, and Anthropic deactivates the key.
• Supabase says it revokes secret keys found in public GitHub repositories and tells the project owner how to rotate them.
• Stripe says it notifies you when it detects an exposed secret or restricted key, and sometimes deactivates it.
• GitHub's secret scanning can raise an alert in your repository's Security tab, and tells partner providers directly so they can revoke the key.

Other signs are a bill you cannot explain, or an AI feature that suddenly stops because the provider disabled its key. Lovable's deep scan also looks for leaked secrets in your code. None of these catches everything; Stripe says it does not guarantee detection of every exposed key.

What should you do in the first hour?

1. 01Revoke or rotate the key at the providerStripe says to rotate an exposed key immediately, even if you are not sure anyone saw it. On Stripe's API keys page, choose Rotate key and set the expiration to Now; a later expiration keeps the old key working for up to 7 days. For OpenAI, delete the key on your API keys page. In the Claude Console, open API keys and choose Delete API Key. For Gemini, Google says to create a replacement and disable the leaked key. The feature that used it will stop. That is the price of stopping the bill.
2. 02Handle a Supabase secret key with careSupabase's guide says not to rush: fix the cause of the leak first, create a new secret key under Settings, API Keys, put it everywhere it is used, then delete the old one, which cannot be undone. Legacy anon and service_role keys are deactivated instead, which can be reversed. This key bypasses every access rule, so also treat it as a possible data exposure and read what to do if users can see each other's data.
3. 03Check usage and save what you findLook at the provider's usage for the leak period: OpenAI's usage dashboard, the Claude Console's usage and spending, or, in Stripe, the key's menu and View request logs. Screenshot or export it now, for the provider's support team.
4. 04Set a hard spend limitOpenAI lets you set a hard spend limit for the organization or a project under Limits, and says enforcement is not instantaneous, so spend can slightly exceed it. Anthropic suggests watching usage in the Console and setting auto-reload thresholds carefully. In Google Cloud, an alerts-only budget does not cap spending; spend cap budgets exist for services that support them.
5. 05Clean up the code and its historyRemove the key from the code, but know it is still in your git history. GitHub's guide says to revoke or rotate a leaked secret first, because rewriting history is disruptive and copies survive in clones and forks. Lovable creates GitHub repositories as private by default; check yours still is. If public remixing is on, Lovable warns that people who remix can view your source code. Turn it off under Project settings, Sharing.
6. 06Talk to the providerOpenAI's help center suggests contacting support after a compromise, and Anthropic says to contact support if suspicious activity continues. Stripe keeps a support page on protecting against compromised keys. Whether charges are refunded is the provider's decision.

How do you move the key server-side in Lovable?

Put the key in Lovable's Secrets and make the call from an edge function. Lovable's docs say secrets are encrypted, injected into your edge functions and never reach the browser. You find them under More, Cloud, Secrets, and once saved, a value can never be viewed again in Lovable, only replaced or deleted. Functions read them with Deno.env.get and the secret's name. If your project uses its own Supabase project instead of Lovable Cloud, the backend view's Manage secrets button opens your Supabase dashboard.

Do not paste the new key into the chat. Lovable asks for keys through a secure input in the chat, and its docs say it recognizes keys pasted into messages and offers to store them as secrets. If the leaked key was Lovable's own LOVABLE_API_KEY, the Secrets view has a Rotate action; Lovable says the old key may stay valid for up to an hour.

Prompting can move the code. It cannot revoke the old key, clean your git history, read your bill or set your limits. Watch for a second leak too: Lovable's guide says a function running on the server is still callable by a client, so a function that calls OpenAI for anyone who asks spends your money like a leaked key. It needs a sign-in check and per-user limits, which our guide to the Lovable OpenAI integration sets out.

How can you tell whether the key was abused?

Compare what the provider recorded with what your app normally does. Look for:

• Usage at hours, volumes or in models your app never uses, starting near the time the key leaked.
• Requests in Stripe's request logs for that key that your server did not make, such as refunds, new customers or reads of customer data.
• For a Supabase secret key, reads or changes to data that no user of yours made. Logs expire quickly: Lovable Cloud's Logs view keeps up to 5 days.

If a key with access to customer data may have been used, treat it as a possible breach and get advice. If only an AI key leaked, the damage is usually money, and the spend limit caps it.

How do you stop it happening again?

• Keep every secret key in Lovable's Secrets and call providers only from edge functions. Our glossary entry on secrets management covers the habit.
• Use a Stripe restricted key with only the permissions your app needs. Stripe recommends restricted keys over secret keys and access policies on live keys, which block and notify you of requests from unexpected places.
• Give each environment its own key, as Anthropic recommends, and set expiry dates. OpenAI suggests expiring project keys and rotating them regularly; Anthropic suggests every 90 days.
• Turn on GitHub secret scanning and push protection. Scanning is free for public repositories and needs GitHub Secret Protection for private ones. Push protection for users is on by default and stops you pushing secrets to public repositories.
• Run Lovable's deep scan before each release. Our guide to the Lovable security scan explains what it covers.
• Add rate limiting to every function that spends money.

The full set of checks, from keys to access rules, is in our Lovable security checklist.

When should you stop prompting and get help?

• A Supabase secret or service role key leaked, because your customers' data may have been read.
• A Stripe secret key leaked, because money and customer records are in reach.
• The bill keeps climbing after you revoked the key you know about, which suggests a second leak.
• The same key, or a new one, ends up in the frontend again after a later prompt.
• You cannot find every place a key is used, so you cannot rotate it without breaking the app.

Our vibe-coding rescue service handles exactly this: engineers find every key, move each one server-side, rotate it without downtime and add checks so it stays there. To see what else might be exposed, take the free production-readiness check.

On a Plutonapps plan, every change you prompt is code-reviewed and security-checked before it ships, which is where a key in the wrong file gets caught. Plans are on our pricing page.

Sources

All checked on October 10, 2026. OpenAI's help center pages were read through search results, because the pages refused direct fetching.

• Lovable documentation: Secrets, on where secrets live, how functions read them, VITE_ values and LOVABLE_API_KEY rotation (docs.lovable.dev/features/secrets).
• Lovable documentation: Security best practices, on frontend secrets being compromised and server functions being callable by clients (docs.lovable.dev/tips-tricks/security-best-practices).
• Lovable documentation: Integration security, on publishable keys, domain restrictions and key rotation (docs.lovable.dev/integrations/security).
• Lovable documentation: Security overview, on the deep scan's leaked-secrets check and key detection in chat (docs.lovable.dev/features/security).
• Lovable documentation: Sync your Lovable project with GitHub, on private repositories by default (docs.lovable.dev/integrations/github).
• Lovable documentation: Control project access, on public remixing exposing source code (docs.lovable.dev/features/project-visibility).
• Lovable documentation: Logs, on the 5-day window (docs.lovable.dev/features/logs).
• Supabase documentation: API keys, on publishable and secret keys and replacing a compromised key (supabase.com/docs/guides/api/api-keys).
• Supabase blog: Supabase Security Retro: 2025, on revoking secret keys found in public GitHub repositories (supabase.com/blog/supabase-security-2025-retro).
• Stripe documentation: API keys, on key types, rotation, the 7-day grace period, request logs and access policies (docs.stripe.com/keys).
• Stripe documentation: Best practices for managing secret API keys, on handling exposed keys and Stripe's detection (docs.stripe.com/keys-best-practices).
• OpenAI Help Center: Best Practices for API Key Safety, on keys in browsers and mobile apps (help.openai.com/en/articles/5112595).
• OpenAI Help Center: Keeping your OpenAI account secure, on disabling leaked keys and contacting support (help.openai.com/en/articles/8304786).
• OpenAI documentation: Production best practices and Spend limits, on key rotation, hard spend limits and enforcement lag (developers.openai.com/api/docs/guides/production-best-practices; developers.openai.com/api/docs/guides/spend-limits).
• Anthropic Help Center: API key best practices, and What should I do if I suspect my API key has been compromised, on GitHub detection, deleting keys, separate keys and rotation (support.claude.com/en/articles/9767949; support.claude.com/en/articles/8384961).
• Google: Using Gemini API keys, on keys in client code and replacing a leaked key (ai.google.dev/gemini-api/docs/api-key).
• Google Cloud documentation: Create, edit, or delete a budget, on alerts-only and spend cap budgets (docs.cloud.google.com/billing/docs/how-to/budgets).
• GitHub documentation: About secret scanning, About push protection, and Removing sensitive data from a repository (docs.github.com/en/code-security/secret-scanning; docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository).