The 7 security flaws AI-generated applications repeat most

By Kike Gandia · Co-Founder & CEO, OSCP

When you audit applications built with generators or coding assistants, the findings repeat with striking regularity. These are not exotic flaws or sophisticated exploitation chains: they are always the same configurations nobody closed. Here is the list, ordered by how often it appears and by the damage it causes, with the concrete check that rules each one out.

Summary: the seven flaws and how to check them

Every row can be verified without special tooling, using only a browser and two test accounts.

Flaw	How to check it	Consequence if left open
Database with no row-level rules	Query the data API while signed out	The whole database is readable
No authorisation between users	Change an identifier in the URL from another account	Read and edit other people's data
Third-party keys in the front end	Network tab of the developer tools	Your payment or email account used at your cost
Open file buckets	Open an uploaded file URL with no session	Mass download of user documents
Unprotected admin endpoints	Try /admin-style routes with no session	Full control of the application
Open sign-up with no verification	Create an account with a non-existent email	Abuse, spam and ghost accounts
Errors revealing internal structure	Force an error with invalid data	A map of your database handed to the attacker

1 and 2. The data layer: the flaw that dominates everything

The first two are really the same problem seen from two angles, and together they explain most leaks in generated applications.

Builders connect the application straight to the database from the browser. That is a legitimate and very practical design decision: the front end talks to the database with no intermediate server. But it is only secure if row-level access rules are defined, because they are the only thing separating one user from everybody else's data.

When those rules are not enabled, anyone who opens the developer tools sees the database address and the key the front end connects with, and can request the data directly. Nothing has to be broken: the application hands the information over because it is configured to hand it over.

The second angle is subtler and survives the first fix: even if you require authentication, if the rule does not check who owns each record, any registered user can read everybody else's. Authenticating is not authorising.

3 and 4. What stays in the browser

Everything the front end needs in order to work travels to the user's browser, and there it is public by definition. The common confusion is assuming something "cannot be seen" because it does not appear in the interface.

Third-party keys. Stripe keys, transactional email service credentials or payment API keys that should live on the server end up in the front-end bundle because that was the quick way to make it work. Whoever finds them can issue charges, send email in your name or burn through your quota.

File buckets. Invoices, receipts and images uploaded by users are stored with permissive defaults. If a file URL is guessable or simply does not require a session, all of them can be downloaded. This is the flaw with the worst reputational reading, because the content is usually personal documentation.

5, 6 and 7. The ones that surface on their own

Unprotected admin endpoints. The builder creates a panel for you to manage the application and sometimes protects the interface but not the data route behind it. Checking it means opening that route with no session.

Open sign-up with no email verification. It looks minor and it is not: it allows bulk account creation, and if the product hands out a free quota or sends email, it becomes a direct cost and a reputation problem for your sending domain.

Errors revealing internal structure. When something fails, many generated applications return the raw database error, table and column names included. For an attacker that is a free map: it saves them the slow part of the work. The fix is trivial — catch errors and return a generic message — and it is almost never in place.

What to fix first

If you can only do one thing this week, enable row-level access rules and verify that they require record ownership, not merely a session. That single change closes the two flaws behind most real leaks.

After that, move any key not intended to be public out of the front end and review your bucket rules. The last three flaws on the list are cheaper to fix and less urgent, but worth closing before any external review: they are the ones that make the worst impression in a due diligence, because they reveal that nobody looked.

FAQ

Are these flaws the fault of the builder I used?

No. They are configurations the tool leaves open so you can build without friction, and closing them is the responsibility of whoever publishes the application. Lovable, Bolt, v0, Replit and Supabase document how to do it and warn about it. The problem is that someone building without a technical background does not always realise the warning applies to them, and the product works just as well if they ignore it.

How many of these seven does a real application usually have?

Finding several at once is the norm, because they share a cause: nobody reviewed the configuration once the application started working. It is rare to find a generated application with a single isolated flaw, and just as rare to find one with all seven: the usual case sits in between, and almost always includes at least one of the first two.

I have already fixed the data layer, do I still need an audit?

This list covers configuration flaws, which are the most frequent and the ones detectable from the outside. It does not cover your product's business logic: prices that can be manipulated, state flows that can be skipped, permissions that can be escalated through an unforeseen path. That is specific to each application and appears on no generic list.

Related service

audits for apps built with AI

Sources

Review my application