How to Secure a Web Application You Didn't Write

You shipped an app without writing the code. An AI tool built it (Lovable, Replit, Cursor, v0, one of a dozen platforms that turn a described product into a deployed one), it works, and people are using it. Somewhere behind that is a question you have no way to answer: is it actually secure?

You cannot read the code fluently, so you cannot check. Hiring a security firm feels premature for something built in a weekend. So the question settles itself by default: I assume it's fine.

This post replaces that assumption with an hour of actual looking. Not a security course. A short self-check built from what researchers keep finding when they scan apps exactly like yours, and an honest line about where the self-check ends.

Why would an AI-built app be insecure?

Because the defaults that produce a working demo fastest are frequently the ones that leave data reachable, and nobody in the loop reviews the layers underneath. When researchers scanned live apps built with these platforms at scale, the failures landed in the same few places, over and over.

Last fall, the research team at Escape, a company that builds security scanners, scanned deployed apps from vibe-coding platforms: Lovable, Base44, Create.xyz, Vibe Studio, Bolt.new. They analyzed over 5,600 publicly available applications and identified more than 2,000 vulnerabilities, over 400 exposed secrets, and 175 instances of personal data left readable, including medical records and bank account numbers.^[1]

Escape sells scanning tools, so an alarming finding is commercially convenient for them. Their methodology is public, which is more than most write-ups in this space offer; weigh the numbers with both facts in hand.

Where the failures sat matters more than the count. The critical weaknesses were reachable directly through public endpoints: database keys sitting in the code every visitor's browser downloads, misconfigured interfaces, and databases missing row-level security (the rule that decides which user may read which rows). Not exotic exploits. Doors left open.

There is also a reason to expect this from AI-written code specifically. CodeRabbit, a company that sells AI code review, analyzed 470 proposed code changes on open-source projects and found the AI-authored ones carried about 1.7 times as many issues as human-only ones, with security issues up to 2.74 times higher in the worst category.^[3]

The tools optimize for the working happy path. Nobody handles the unhappy path unless someone asks.

How do I know if my web app is actually secure?

You separate "nothing obvious is wrong" from "I actually checked." Most owners have done neither. The four checks below need no code reading; they cover the failure classes the scans surfaced most often, the ones visible from an ordinary browser.

Are your keys sitting in the browser?

Every modern browser ships a developer console: right-click the page, choose Inspect, open the Network tab, and reload. You are looking at everything your app sends to every visitor. If an API key, a database credential, or anything labeled secret appears in that code or traffic, it is public.

Escape found exactly this at scale: service keys, in their words, "often trivially retrievable from frontend bundles," the bundled code a browser downloads.^[1]

You do not need to understand what you see. You need to search it (the console has a search box) for words like key, secret, and token, and notice whether long credential-looking strings show up.

Does typed input go anywhere unchecked?

If your app accepts anything a user types (a search box, a contact form, a profile field) and nothing checks that input before it reaches the database, the app can be manipulated by typing. AI-generated scaffolding skips validation constantly, because the happy path works without it.

You cannot read the database query. You can do what your builder never did: type unusual things into every field. Apostrophes, angle brackets, a very long string. If odd input produces odd behavior (a raw error page, a blank screen, your input echoed back with formatting applied), treat it as a finding.

Can one user open another user's records?

The most damaging failure is also the easiest to test. Log in, open one of your own records, and look at the address bar; most apps put a record number in the URL. Now change that number, or paste the URL into an incognito window where you are not logged in.

If someone else's data loads, or any data loads at all, access control is missing. The scaffolding built the routes and left "who is allowed" as a later step that never came.

Is the padlock actually there?

The padlock in the address bar means traffic between your users and your app is encrypted in transit. Its presence proves very little. Its absence, or a browser warning about mixed or insecure content on any page, proves the baseline was never configured, and it is the one sign every visitor can see too.

What does passing the self-check prove?

Less than you would like. It proves the loudest, most owner-visible failures are not screaming. It says nothing about how logins and sessions behave under abuse, what your third-party code is exposed to, whether the data layer enforces its own rules, or a dozen other surfaces that need someone who can read the whole thing.

That gap is not a reason to skip the self-check. It is the reason to hold the result loosely: four green lights mean you have done a first pass of due diligence, not that the app is secure. The risks that hurt worst are usually the ones that never make your list at all.

Who would bother attacking your small app?

Nobody, and that is the wrong comfort. Exposed apps are not chosen, they are found. Escape's team assembled its target list from public launch directories, Reddit threads, and Shodan (a search engine for internet-connected systems), then scanned 14,600 assets automatically.^[1] Your app is on lists like that whether or not anyone is watching it.

The question is not whether your app could survive a determined expert. It is whether it survives being found by a script.

When should you get a professional assessment?

The moment any of the four checks fails. And even on a clean pass, if the app handles payments, health information, or personal data at scale: the self-check is a floor, and an assessment covers the layers you cannot see from a browser.

One more study says why this is worth paying for rather than putting off. Researchers at Wake Forest University watched the network traffic of 444 iPhone apps with AI features and found 282 of them exposing usable credentials for the AI services behind them.^[2]

Those are mobile chatbot apps rather than web apps, but notice the method: they found the exposure the way you just checked your own app, by watching what it sends. Then the team notified every affected developer, waited three months, and re-tested.

Only 28 percent had fixed the problem. The rest were still exploitable.

Being told about a hole is not the same as closing it, and most people never close it.

An outside assessment exists to find what the self-check cannot: we wrote about what an application security audit actually finds, and where security sits in the larger journey from working demo to an app that is actually production-ready. If your app takes payments, the compliance bar is its own question on top of this one.

The hour of looking does not make your app secure. It tells you whether you have been checking or guessing, and everything else follows from which one it was.