Is the Supabase anon key in my Lovable app a leak?

No. The anon or publishable key is meant to be in the browser. It's only safe if Row Level Security is on for every table with sensible policies. The service_role key and sb_secret_ keys are the ones that must never be in the frontend.

I removed the key in Lovable. Why does the scan still find it?

Probably because you haven't republished. Edits in the editor don't change your live site until you publish again. Also check for a custom domain and the lovable.app URL, which can serve different builds.

Can the free scan see my Lovable app's code?

It sees what any visitor sees: the published page and up to 25 scripts it links to. It flags Stripe, OpenAI, Anthropic, AWS, Google and Supabase secret keys there. It doesn't read your Lovable project files or your Edge Functions.

Lovable app leaking an API key? Move it to an edge function

Lovable builds a Vite + React frontend, so any key the frontend reads ends up in public JavaScript. This page fixes one problem end to end: get a leaked key out of your Lovable app and into a server-side secret.

Short answer: Revoke the leaked key at the provider first. Then ask Lovable to move the call into a Supabase Edge Function that reads the key with Deno.env.get(), add the new key as a secret, republish, and confirm the old key is gone from your live JavaScript.

This page is one fix, done properly. For a full pre-launch review of a Lovable app, use the Lovable security checklist. For why VITE_ variables leak in the first place, read VITE_ variables are public.

How the key got there

You asked for a feature that uses a paid API, such as "add an AI assistant" or "send an email when someone signs up", and gave Lovable the key in chat. If the generated code calls that API from a React component, the key is written into the frontend source or a VITE_ variable, and the published build carries it to every visitor. Lovable often routes keys through an Edge Function on its own, but it's still worth checking, because a later edit can quietly bring the client call back.

Find it in your live app [manual]

Open the published URL (yourapp.lovable.app or your custom domain), not the editor preview.
DevTools, Network, filter JS, reload. Then Ctrl+Shift+F (Cmd+Option+F on a Mac).
Search for the start of your key (sk-proj-, sk_live_, sk-ant-, re_ for Resend, and so on) and for the provider's API host, for example api.openai.com.
In Lovable, switch to code view and search the project for the same string. Note every file that contains it.

Move it to an edge function

Revoke the leaked key [manual]. At the provider (OpenAI API keys page, Stripe Dashboard, Resend, and so on), delete or roll it. Do this first; the copy in your old build is public.

Ask Lovable to restructure. Paste this into the chat:

Security fix: an API key is exposed in client-side code. Move every call to [PROVIDER] out of the React frontend into a Supabase Edge Function named "[provider]-proxy". The function must read the key with Deno.env.get("[PROVIDER]_API_KEY"), verify the user's Supabase auth token and reject anonymous requests, validate the input, and return only the data the UI needs. Update the frontend to call it with supabase.functions.invoke. Remove the key and any VITE_ variable holding it from all frontend files. Do not hard-code the key anywhere.

Add the new key as a secret [manual]. Lovable usually prompts you for the secret through its own form when a function needs one. If it doesn't, add it in the Supabase dashboard under Edge Functions, Secrets, using the exact name the function reads. Never paste the new key into the chat as part of code.
Review the function [manual]. Open the generated function in code view and confirm it checks the auth header and that the key appears only as Deno.env.get(...).
Republish, then rerun the search from the previous section on the live URL.

Two Lovable-specific gotchas

The service_role key. If you ever asked Lovable to "fix permission errors", it may have reached for the Supabase service_role key in the client. That key bypasses Row Level Security. Search your bundle for eyJ, decode any JWT, and treat "role":"service_role" as an emergency. The leaked API key checker shows the decode step.
Old builds on other URLs. If you use a custom domain, check the lovable.app address too, and check any other host you deployed to.

Make it stick

Add to your project's knowledge or instructions: "All third-party API keys live in Edge Function secrets. Never put keys in frontend code or VITE_ variables."
Rerun the bundle search after any feature that touches a paid API.
Keep RLS on for every table, since your anon key is public by design.

What the free scan checks here (and what it doesn't)

It fetches your published page and up to 25 linked scripts and flags Stripe sk_live_/rk_live_, OpenAI, Anthropic sk-ant-, AWS AKIA/ASIA, Google AIza, and Supabase service_role and sb_secret_ keys. It notes a Supabase anon key and project URL as info only and does not test whether your tables are readable. It also checks /.env, /.git/HEAD, HTTPS and four security headers.

It doesn't see your Edge Function code, your Lovable project files, or keys for providers outside that list, such as Resend. Those are [manual].

FAQ

Is the Supabase anon key in my Lovable app a leak?: No. The anon or publishable key is meant to be in the browser. It's only safe if Row Level Security is on for every table with sensible policies. The service_role key and sb_secret_ keys are the ones that must never be in the frontend.
I removed the key in Lovable. Why does the scan still find it?: Probably because you haven't republished. Edits in the editor don't change your live site until you publish again. Also check for a custom domain and the lovable.app URL, which can serve different builds.
Can the free scan see my Lovable app's code?: It sees what any visitor sees: the published page and up to 25 scripts it links to. It flags Stripe, OpenAI, Anthropic, AWS, Google and Supabase secret keys there. It doesn't read your Lovable project files or your Edge Functions.