Lovable security checklist: 14 checks before you take payments

A Lovable security checklist is the short list of things you confirm before real customers, and especially their payments, touch your app: who can read each table, where your secret keys live, whether your server code checks who is calling, and whether a customer can change a price. Lovable's built-in scans catch a good share of this, but by Lovable's own description they do not replace a thorough review. This guide gives you a 14-point checklist you can work through in an afternoon, in plain English, with the exact places to look.

If you would rather have a senior engineer walk through it with you, that is what our Lovable app security audit is for. Everything below is also something you can do yourself first.

Why a checklist, when Lovable already scans my app?

Lovable ships two built-in scans. The Quick scan runs automatically every time you publish and looks at your database access rules, known vulnerable npm packages, and any MCP server your app exposes without sign-in. The Deep scan runs on demand and reads your application code for problems like users seeing data that is not theirs, endpoints anyone can trigger, leaked secrets, and payment logic a customer can tamper with.

That is genuinely useful. But Lovable's documentation is clear that these tools "cannot guarantee complete security" and recommends a professional review for apps that handle sensitive data or critical functions. Scanners read code and configuration. They do not know your business rules. A scanner cannot tell that a "team member" should never see the "owner" billing page, or that a discount code should only work once.

A checklist fills that gap. It makes you test the app the way a curious customer, or a bored attacker, would.

Before you start: three things to have open

1. Your Lovable project, with the Security view open (More → Security in the project toolbar). 2. Your database dashboard. In Lovable this is under More → Database; if you connected your own Supabase project, open the Supabase dashboard instead. 3. Two browsers or one normal window plus one private window, so you can be two different people at once.

Give yourself about three hours the first time. The second time it takes under an hour.

The Lovable security checklist (14 checks)

Part 1: Data access (checks 1 to 5)

1. Run a fresh Deep scan, not just the Quick scan. The Deep scan does not run on its own as you work. Open the Security view and click Run deep scan. Lovable says it usually takes 3 to 13 minutes. Read every Critical and Warning finding before you continue.

2. Confirm Row Level Security is on for every table. Row Level Security (RLS) is the rule set that decides which rows each person can see. A table without it, in the exposed part of your database, can be read and changed by anyone with your project URL. Supabase's Security Advisor flags this as rls_disabled_in_public, rated ERROR. In your database dashboard, open each table and confirm RLS is enabled.

3. Look for rules that say "everyone". RLS being "on" means nothing if the rule is true. Supabase's advisor calls this permissive_rls_policy: a policy with USING (true) lets every matching user read every row. That is fine for a public product catalogue. It is a data leak for orders, messages, invoices or profiles. Read each policy and ask: "Does this mention the signed-in user, or does it let everyone through?"

4. Check file storage, not just tables. Uploaded files (avatars, invoices, contracts) live in storage buckets with their own access rules. A public bucket with a broad read rule lets people list every file in it. Supabase flags this as public_bucket_allows_listing. For anything private, use a private bucket and rules that tie each file to its owner.

5. Run the two-account test. Sign up as User A in one window and User B in another. As A, create something private: an order, a note, a profile detail. Copy the URL. Paste it into B's window. If B can see A's data, your rules are wrong, whatever the scanner says. We go deeper on this in is my AI-built app secure? The two-account test.

Part 2: Secrets and keys (checks 6 to 8)

6. Search the browser for secret keys. Open your live app, open the browser's developer tools, and search the loaded JavaScript (the Sources tab, then search across files) for sk_live, sk-, service_role, sb_secret_ and SECRET. Anything you find there is public. Lovable's own best-practices guide says secrets placed in frontend code "should be considered compromised".

7. Know which keys are allowed in the browser. The Supabase publishable (or legacy anon) key is designed to be public and is safe only when RLS does its job. We explain the conditions in is the Supabase anon key safe in the browser?. Anything prefixed VITE_ is baked into the browser bundle, so it must never hold a private value. Private values belong in Lovable's Secrets, which are injected into Edge Functions and, per Lovable, never reach the browser.

8. Rotate anything that ever leaked. If a secret key was ever pasted into frontend code or a public repo, deleting it from the code is not enough. Create a new key in the provider's dashboard, update it in Secrets, then revoke the old one.

Part 3: Server code and payments (checks 9 to 12)

9. Every Edge Function checks who is calling. An Edge Function is a public web address. Anyone who finds it can call it directly, without using your app's buttons. Each function that does something private should verify the signed-in user and, for admin actions, check their role on the server, not just hide the button in the interface.

10. Prices come from the server. If your checkout sends the price from the browser, a customer can edit it. The amount should be looked up on the server from your product list, or set as a price in Stripe, never trusted from the page.

11. Paid status is set by a verified webhook. Don't mark an order "paid" because the customer landed on a /success page. Anyone can type that address. Stripe's documentation explains how to verify the signature on each webhook event so you only trust events Stripe actually sent. Your app should unlock paid features only after a verified event arrives.

12. Roles can't be self-assigned. If you have an is_admin flag or a role field, check where it lives. Supabase warns (advisor rls_references_user_metadata, rated ERROR) that user_metadata can be edited by the user, so policies that trust it can be bypassed. Store roles in a table only the server can write.

Part 4: Accounts and recovery (checks 13 and 14)

13. Turn on leaked-password protection. Lovable's Quick scan flags this when it is off. It checks new passwords against the Have I Been Pwned database and rejects ones known to be leaked. In Lovable's built-in backend it is under More → Users → Settings → Email; on your own Supabase project, see Supabase's password security guide.

14. Test recovery and sign-out like a stranger. Request a password reset for an email you don't own: the message on screen should not reveal whether the account exists. Sign out, press the browser's Back button, and reload: private pages should not reappear. Make sure your production login redirects point to your real domain, not a preview address.

How to score your results

Mark each check as Pass, Fail or Not sure.

• Any Fail in checks 2, 3, 5, 6, 10 or 11: fix before you take another payment. These are the ones that expose customer data or let people skip paying.
• Any Fail elsewhere: fix this week.
• More than three "Not sure": that is a signal in itself. It usually means the app grew faster than anyone's understanding of it, which is normal for AI-built apps and worth an outside look.

Re-run the Deep scan after your fixes. Scan results are tied to a specific version of your code, so old findings stay visible with a clock icon until you scan again.

What this checklist does not cover

Fourteen checks will not make an app bulletproof. They leave out load and speed under real traffic, backups you have actually restored, logging that hides personal data, and privacy obligations like data deletion requests. Our broader list of production checks for AI-built apps covers those. If your app works in preview but misbehaves after publishing, start with why Lovable apps break in production.

You can also try our free launch-ready self-check for a quick read on where you stand.

Practical takeaways

• Lovable's scans are a strong first pass. Run the Deep scan yourself before every big release, because it does not run automatically.
• "RLS is on" is not the same as "data is private". Read the rules and run the two-account test.
• Search your live app for secret keys. If one ever leaked, rotate it.
• Never trust the browser for prices, paid status or roles.
• Score every check honestly. "Not sure" counts.

FAQ

Is a Lovable app secure by default?

Lovable adds guardrails, such as steering API keys into Secrets and scanning database rules on every publish. But security depends on your data rules and business logic, which only you (or a reviewer) can judge. Treat the defaults as a starting point, not a finish line.

How often should I run this checklist?

Run the full list before launch and before you add payments. After that, run checks 1, 2, 3 and 5 after any change to sign-in, roles or the database, and the full list every quarter.

Does the Quick scan check my payment logic?

No. The Quick scan covers database settings, dependencies and MCP exposure. Payment and billing issues are part of the Deep scan, and even then, rules like "this coupon works once" need a human to confirm.

Can I fix the findings by asking Lovable?

Often, yes. Lovable can attempt fixes from the Security view or the chat. Always re-test afterwards with the two-account test, because a fix that makes the warning disappear is not always a fix that matches your business rules.

---

Want a second pair of eyes before customers pay? Our Lovable app security audit reviews your access rules, secrets, Edge Functions and payment flow, and hands you a plain-English fix list. Book a free technical assessment and we'll tell you what to fix first.