Platform
Lovable breaks
Lovable breaks: row-level security, keys pasted into chat or left in the client, and a scan that warns without blocking publish. Fixes are for your own app.
19 cards are tagged Lovable. Symptoms in this set: Exposed data, Secrets, Auth, Payments, Over-open rules, Storage, Publishing. Open a card for the root cause, the fix prompt, and the self-check. The check is only for an app you own.
Exposed data
Supabase tables ship with row level security off
The app looks correct while you are signed in. A request that carries only the publishable key, and no user session, can still read or write a table.
Exposed data
A policy uses USING (true) on private rows
Row level security is on, and the app still returns every row to any signed-in user, or to nobody at all.
Exposed data
Table grants stay wide open after policies are added
You added policies, then a signed-out client can still insert, or a signed-in client can still delete rows the policy was meant to hide.
Exposed data
A view bypasses row level security
The table policies look right. A view the app selects from still returns every row.
Secrets
The service role key is in the browser bundle
Data API calls from the site ignore every row policy. Searching the shipped JavaScript turns up a secret or service role key.
Secrets
A VITE_ variable bundles a secret into the client
An API key works in the browser preview. Anyone who opens the built JavaScript can read it.
Auth
An Edge Function turns auth off and never checks the caller
A function that changes data or spends money returns 200 with no session. It was set to verify_jwt = false, or auth: 'none', to clear a 401 during development.
Exposed data
The admin client returns every user's rows
The function checks that someone is signed in, then a query through the admin client returns the whole table.
Payments
The Stripe webhook accepts an unsigned body
A payment shows as paid, or a paid feature unlocks, when a request hits the webhook URL without a valid Stripe signature.
Over-open rules
Firebase rules allow every read and write
The app was created in Firebase Test mode, or the rules say allow read, write: if true. Anyone who knows the project can read and overwrite the data.
Over-open rules
Any signed-in Firebase user can read the whole database
Signed-out visitors are blocked. Any account, including one you just created, can read and write every document.
Auth
The app freezes after sign-in
Login returns, then the next Supabase call never comes back. The screen stays on a spinner.
Auth
OAuth comes back to the wrong host
Google or GitHub sign-in leaves the user on localhost, on a preview URL that errors, or on the site with an error in the URL hash.
Auth
Confirmation and reset emails point at localhost
Sign-up works in the builder preview. The email link opens localhost, or the production site never receives the token.
Storage
A public Storage bucket serves private files
A document or invoice URL loads in a private window, with no login.
Storage
Storage upload returns 403 even with an insert policy
Upload fails with 'new row violates row-level security policy' even though the insert policy looks correct and the user is signed in.
Publishing
Lovable's scan finds issues and publish still continues
The publish dialog reports critical findings. The app goes live anyway, because blocking publish is a workspace setting and it is off.
Secrets
An API key was pasted into the Lovable chat
You pasted a provider key into chat so Lovable could wire up the feature. The key is now in the transcript, and maybe in client code.
Auth
The UI hides a page, and the API does not
The admin screen is hidden unless a localStorage flag is set. The request that loads the data still succeeds without that flag.