Built an app with Lovable? What to check before real customers use it

When you click through an app and everything behaves, you've proven the happy path works. You signed up, logged in, saw your own data, and it looked right. That tells you the app does what it's supposed to do when you use it the way you intended.

It tells you nothing about what happens when someone else uses it the way you didn't intend. Can another logged-in user see your data by changing a number in the address bar? Can someone who was never meant to have an account get in anyway? A demo that works for you doesn't answer either question, because you never tried to break it.

The most common gap is access control: the app doesn't properly separate what one user can see from what another can see. In database terms this is usually missing row-level security, meaning the database will happily hand over any row to anyone who asks nicely, not just the rows that belong to the person asking. CVE-2025-48757, a published vulnerability record, documents exactly this pattern in Lovable-generated projects: apps built without row-level security where one user's request could return another user's data.

Beyond that, the usual list applies to any app, not just Lovable ones. Logins and permissions: does every page that should require a login actually check for one, and does every action check that the logged-in user is allowed to do it. Secrets and API keys: are any of them sitting in the code itself or in a file inside a public folder, where anyone who finds the URL can read them. Payments and personal data: if the app touches either, it needs more scrutiny than a feature that just displays a list. Who maintains the app after launch: someone needs to own fixes and updates, not just the person who built it for a demo. And backups: if the database disappears tomorrow, is there a copy anywhere.

I get asked this a lot, usually by someone assuming their app is too small or too new to be a target. It isn't. One of my own production sites logged more than 3,000 requests in the first two weeks, from automated scanners, not customers. I'm not naming the site or saying any of those requests succeeded. The point is simpler: the scanning starts almost immediately, before you've told anyone the site exists.

A lot of that traffic is bots probing for known files, things like a .env file that might have been left reachable, or a path that a popular framework uses by default. If a key does end up sitting in your code or in a public folder, you usually don't find out by spotting it yourself. You find out when a bill arrives for usage you didn't generate.

So the practical response is less about defending against a specific attacker and more about hygiene: know where your keys actually live, rotate any key you've ever pasted into a chat window with an AI tool, set a spending limit on every paid API key so a leak costs you a cap rather than an open tab, and keep secrets out of anything that ships to the browser.

If you're not going to check this yourself, hand someone a short list of questions rather than a vague "is it secure". Ask whether the security scan ran: Lovable's own pages say a basic scan runs before every publish, and a deeper scan can be run on demand (lovable.dev/security), so the first question is simply whether that happened and what it found. Ask someone independent of the build to review it, because the person who built the app is the least likely to spot what they assumed rather than checked. And ask for a concrete test: two separate accounts, used to confirm that one genuinely cannot see or change the other's data, not just that the interface doesn't show a button for it.

If an independent review comes back clean, or flags a handful of small fixes, keep what you have and make the fixes. Most of the time that's exactly where this lands. If the review finds that access control is fundamentally missing, meaning users can reach each other's data by design rather than by a small bug, that's not a patch job. The access control layer needs rebuilding properly before customers go anywhere near it.

I build with AI tools myself, Lovable included, and I review what comes out before it goes anywhere near a customer. I'm not an auditor and I don't certify anything. I'm someone who checks before customers touch it, which is a lower bar than compliance but a much higher one than clicking through a demo. If you want a second pair of eyes on something you've built, or a build with me from scratch, that's the kind of work I do, and the safe AI page covers the wider approach. Real client builds are a better sense of what that looks like in practice than anything I can describe here. If you'd rather start with a conversation, get a free automation plan and tell me what you've built.