Lovable will build the admin panel and leave it unlocked

Lovable is genuinely good at the hard part. Ask for login and you get working login. The gap is smaller and more annoying than people expect: it will happily put your OpenAI key in the browser, hide an admin button instead of protecting it, and make your uploads bucket public — because each of those is the shortest path to a working preview. Here are the four, and how to check yours in about ten minutes.

1. Your API keys are in the page

You asked for AI features. The model needed an OpenAI key, so it put one in the frontend and called the API from the browser. It works perfectly. It also means the key is in the JavaScript you serve to everybody.

People scan for this automatically. A leaked OpenAI key gets found and drained, usually within hours, and you find out from the bill. Same story for Stripe secret keys, Resend, Twilio, and anything labelled service_role.

The rule is short: if a key can spend money or bypass permissions, it never touches the frontend. It goes in a Supabase Edge Function, and the browser calls your function instead of the vendor.

2. The admin check is in the UI, not the app

You asked for admin-only features. What you usually get is a conditional that hides the admin section unless the logged-in user is you.

That is a visual change. The route still exists, the query still runs, and the endpoint still answers anyone who calls it. Anyone can open the network tab, watch what a request looks like, and replay it with their own account — no tooling, no exploit, just a copied request.

A real check lives somewhere the browser cannot reach: a database policy that scopes rows to the user, or a server-side check inside an Edge Function. If your only defence is that the button is not rendered, you do not have one.

3. Your uploads bucket is public

This one gets missed constantly because nothing about it looks wrong. Supabase Storage buckets can be public or private, and a public bucket serves every file in it to anyone with the URL — no login, no token.

Public is the right setting for avatars and product images. It is the wrong setting for the thing your app probably also stores: ID photos, invoices, CVs, medical forms, anything a user uploaded assuming you would keep it. And the URLs are predictable enough to walk.

Split them. One public bucket for decoration, one private bucket for user files, served through signed URLs that expire. In Supabase this is Storage → your bucket → toggle off Public bucket.

4. Your payment webhook believes anyone

Only relevant if you took the Stripe route, but it is the most expensive item here.

Stripe tells your app about payments by POSTing to an endpoint you expose. That endpoint is public — it has to be. Which means anyone who guesses the URL can POST it too, and if your handler does not verify the signature Stripe sends, it will cheerfully mark an order paid because a stranger said so.

The fix is one call to stripe.webhooks.constructEventwith your webhook signing secret before you trust a single field in the body. Ask for it explicitly — this is not something a "set up payments" prompt reliably gives you.

And yes, Row Level Security

You cannot write about Lovable and skip this. CVE-2025-48757, published in 2025, found 170+ Lovable-built apps whose tables had no Row Level Security, which made them readable — often writable — by anyone with the public anon key. Lovable fixed its code generation and added a scanner.

The important detail: that fix applies to new projects. It does not reach into a database you built before it, so an older app is unverified until you verify it. If you only read one more thing, read how Row Level Security actually fails — including why a broken read policy returns an empty list instead of an error, which is why nobody notices.

Then watch it, because you are going to keep prompting

Fixing the four above is a one-afternoon job. Keeping them fixed is not, because you will keep building, and a prompt that adds a feature can quietly move a boundary. These are the changes worth an alert:

• A table's protection being switched off — one SQL statement, no visible effect on the app, and the table becomes public.
• Login attempts that do not look like your users — the same password tried against hundreds of accounts, or thousands of signups overnight, is visible in Supabase auth logs before anything succeeds.
• Your admin key being used from a browser — the observable consequence of a service_role key that made it into the frontend. There is no innocent version of this request.
• One endpoint being read over and over with rising offsets — that is somebody downloading a table, and it looks nothing like normal traffic.

Where Defencecore fits

Items 1 to 4 are yours to fix — no monitoring tool can decide that a bucket should have been private. Defencecore covers the part that comes after: it reads your Supabase logs continuously and opens an incident with the evidence attached when a boundary actually moves. It is read-only, so it can explain a problem and never cause one.