Is an application built with AI secure? How to tell, even if you are not technical

By Kike Gandia · Co-Founder & CEO, OSCP

Building an application with Lovable, Bolt, v0, Replit or a copilot such as Cursor or Copilot is no longer unusual. What almost never happens is that somebody checks whether that application is secure before putting it in front of real users. And there is an important difference between "it works" and "it is secure": the first is verified by anyone opening it in a browser; the second requires looking where nobody looks. This guide explains what actually goes wrong, why, and how to check in a short time whether your application has a problem.

Why an AI-generated app can work perfectly and still be exposed

Models generate code that meets the goal you give them. You ask for "users can save their notes", and the result saves notes. What you do not ask for — because it does not occur to you that it needs asking — is that one user must not be able to read another user's notes.

That asymmetry is the origin of almost every problem. Functionality tests itself: if it does not work, you see it. Security does not test itself: if it is wrong, the application keeps working exactly the same. Nothing breaks, nothing warns you, and the flaw only surfaces when somebody goes looking for it.

There is a second factor: builders optimise for showing you results fast. That means permissive defaults in the data layer and in permissions, designed so nothing blocks you while you build. Closing them is the responsibility of whoever publishes the application, and it is the step almost nobody takes.

The difference between a copilot and an app builder

Having used GitHub Copilot or Cursor is not the same as having used Lovable, Bolt, v0 or Replit, and the audit changes accordingly.

With a copilot there is a repository and somebody who has at least read the code. The flaws are code flaws: injections, insufficient validation, hand-written secrets, insecure dependencies. They resemble those of any traditional development done in a hurry.

With an app builder there may be nobody who has read the code at all, and the flaw is rarely in a specific line: it sits in the configuration. A database reachable from the browser, undefined permissions between users, third-party service keys embedded in the front end. Reviewing only the code achieves nothing here: you have to assess the deployed application.

The practical consequence is that if you built with a builder and somebody offers you "a repository review", they are offering you half the work.

The three questions that decide whether you have a problem

Before any technical detail, three questions separate a reasonably closed application from an exposed one.

1. Can one user see another user's data? Create two accounts, put different data in each, and from the first one try to reach the second by changing an identifier in the URL or in a request. If you can, you have a serious problem that is cheap to fix.

2. Are there keys in the browser? Open the developer tools, network tab, and look at what is being sent. If you see database credentials, payment API keys or tokens that are not public by design, they are within anyone's reach.

3. Who can write to your database? It is the question fewest people ask and the one with the worst consequences. A database that accepts writes without checking who is making them allows every user's data to be deleted or altered, not merely read.

What happens if you leave it as it is

The risk is not abstract. An application with an open data layer exposes everything it holds: emails, names, user-uploaded content and, depending on the product, payment or health information. No sophisticated attack is required; it is enough for somebody to look.

If that data includes personal information about EU residents, you are also facing a breach with concrete obligations: notification to the supervisory authority within 72 hours and, depending on impact, communication to those affected. The GDPR does not distinguish between a flaw introduced by a developer and one introduced by a code generator.

And there is a commercial cost that arrives before the regulatory one: as soon as you sell to another company, your client will ask about the security of your product. The same applies when you raise investment. Reaching that conversation having reviewed nothing is the fastest way to lose the deal.

What to do now, in order

You do not need to stop the product or rebuild it. The order that removes the most risk per unit of effort is this:

1. Close the data layer. Enable row-level access rules and verify that nobody unauthenticated can read or write.
2. Get secrets out of the front end. Any key not meant to be public has to live on the server.
3. Check authorisation between users, not just login. Authentication is knowing who you are; authorisation is knowing what you may touch.
4. Review what you actually store. Many generated applications keep more data than they need, and every extra field is exposure surface.
5. Get an external review before a launch or a due diligence, not after.

The first three can be done by whoever built the application in an afternoon. The fourth and fifth require looking at it with an attacker's judgement.

FAQ

Is an AI-built app less secure than one written by a developer?

Not by nature, but more often in practice. Model-generated code reproduces insecure patterns present in its training data, and whoever publishes it frequently lacks the judgement to spot them. An experienced developer makes fewer basic configuration mistakes; a rushed one makes the same ones. The real difference is not the tool, it is whether anybody has reviewed the result with security judgement.

My application is small and has few users, does it still affect me?

Size does not protect you. The scans that discover open databases are automated and indiscriminate: they sweep entire ranges of the internet without knowing who owns each service. An application with twenty users and an open data layer is found just as quickly as one with twenty thousand. What changes with size is the impact, not the probability.

Can I check this myself or do I need someone external?

The three checks in this guide can be run by anyone with a browser open, and they rule out the most serious and most common flaws. What they do not cover is business logic: a user applying a discount they are not entitled to, changing the status of someone else's order, or escalating to administrator through an unforeseen path. That requires somebody attacking the application deliberately, because it is not visible by inspection.

Related service

security audits for apps built with AI

Sources

I want to know whether my application is secure