This is not scaremongering. Independent security researchers keep finding AI-generated apps that leak user data. One audit of public Lovable apps reported that roughly one in ten exposed user information. In a single widely reported case, one app leaked the data of more than 18,000 people. The pattern is consistent, and the causes are a short list.
Secret keys sitting in the open
Apps connect to other services, payment, email, AI, with secret keys. These keys are meant to live on the server, where visitors cannot see them. AI-built apps often place them in the part of the app that runs in the browser, where anyone can open the page source and copy them. With your key, someone else can run up your bill or send email as you.
A database anyone can read
Most of these apps use a hosted database like Supabase. By default it needs rules saying who may read and write each record. Those rules are not added for you. Without them, the database is open: with the address, which is not secret, anyone can pull every record. This is the most common serious flaw, and the one behind most of the leaks above.
Logins that protect nothing
A login screen is not the same as enforced access. In many prototypes the screens exist, but the checks behind them do not. Change a number in the web address, or call the data directly, and the app hands it over. It feels locked because the front door has a lock. The windows are all open.
No limits on what people can send
A production app limits how often someone can hit it and checks everything they submit. Prototypes usually do neither. That opens the door to spam sign-ups, abuse, inflated bills, and inputs crafted to trick the database into doing something it should not.
Everything trusts the browser
A recurring theme: the app believes whatever the browser tells it. If a check only happens on the user's screen, it is not really a check, because the screen is the one place an attacker fully controls. Real security decisions have to be made on the server, every time.
Why this keeps happening
AI tools optimise for a working demo. A demo has one friendly user and no attacker, so the model never builds for one. Security is invisible when everything goes right, which is exactly the condition a demo is built under. It only shows up when something goes wrong, and by then it is live.
How to tell if you are exposed
- You can reach another user's data by changing a value in the web address.
- Your payment or service keys appear if you view the page source.
- You never set rules on who can read your database.
- The login was generated but never tested against someone trying to get past it.
If any of these sound familiar, the data is probably reachable today. Closing these gaps before you have real users is far cheaper than after. It is a core part of what we do when we take an app to production, and we are happy to tell you where you stand.