Security for AI-built apps

If you built your app with Lovable, Bolt, Cursor or v0, you shipped something that works. It loads, it logs people in, it saves data. What you cannot see from the outside is whether it is safe. The same handful of holes show up again and again in apps built this way, and none of them are visible until someone finds them for you.

This is not a knock on the tools or on you. It is a gap that comes with how AI builders work, and it is fixable once you know what to look for.

Why AI builders leave holes

An AI AI builder is optimized for two things: making the app work, and making it look done. Both of those are visible. You can see a button appear, a page load, a signup succeed. Security is the opposite. A missing login check looks identical to a working one until an attacker walks through it. An exposed database behaves perfectly for you and perfectly for the stranger reading it.

So the tool does what it is rewarded for. It gets you to "it works" fast, and it stops there, because that is where the visible finish line is. The unsafe version and the safe version look the same on your screen. The difference only shows up when someone goes looking, and by then it is a breach, not a warning.

There is a second reason. AI builders default to whatever gets you unblocked. Open the database so the app can read it. Skip the auth check so the page renders. Widen the permissions so the request stops failing. Each of these is the path of least resistance, and each one leaves a door open. The tool is not being careless on purpose. It is choosing "works now" over "safe later" every time the two conflict, because you asked it to build something that works.

The holes that keep showing up

A few patterns account for most of what gets AI-built apps broken into.

Databases left open by default. Many builders wire your app to a hosted database that starts wide open. Anyone who finds the address can read or change your data. Row-level security, the setting that limits each user to their own rows, is often off until someone turns it on, and nobody does.

Keys and secrets shipped where they can be read. An API key or database password belongs on the server, hidden. AI builders routinely commit these into the code or, worse, ship them to the browser, where anyone can open the developer tools and copy them. A leaked key is a live one until you rotate it.

Authentication that only lives in the browser. The app hides the admin button unless you are logged in, so it looks protected. But the check runs in the browser, and the browser belongs to the attacker. Remove the check, or call the underlying address directly, and the protection is gone. Real auth has to run on the server, where the user cannot touch it.

Admin pages with no login at all. Sometimes the dashboard, the user list, or the internal tools sit at a guessable address with nothing in front of them. If a page can change your data or show you everyone's records, it needs a login. Builders often forget to add one.

Permissive CORS. This is the setting that decides which other websites are allowed to talk to your app's backend. Set too loosely, it lets any site on the internet make requests as if it were yours. It is an easy default to leave wide open and an easy thing to miss.

Why "it works" is not "it is safe"

The hard part is that none of this shows up in the demo. Your app works. It looks done. You showed it to friends and they signed up. Every signal you can see says ship it. The problems are invisible by design, which is exactly why they survive all the way to production.

That is the whole reason for an outside check. You cannot test for a hole you cannot see, and you did not write the code, so you have no map of where the tool cut a corner. A scan reads the code for the specific mistakes AI builders tend to make, and tells you in plain words what is open and why it matters. Why Sentrint exists covers the thinking behind that. Common vulnerabilities walks through each hole in more detail.

What to do about it

You do not need to become a security engineer. You need to know which doors are open and close them. A scan surfaces the findings, sorted worst-first, and each one comes with a fix prompt you paste back into the same AI builder that made the app. The tool that opened the door is the one that closes it, one step at a time.

The point is not to scare you off building with AI. It is a good way to build. The point is that "works" and "safe" are two different finish lines, and the tools only carry you to the first one.

Check your app

The fastest way to find out what your app is leaking is to scan it. Sign in with GitHub and scan a repo free, one a month, no card: start a scan.