“A contractor who builds exactly what you describe, fast, and never mentions the building code, because you didn't ask.”
The gap between 'it works' and 'it's safe'
Ask an AI tool to build a feature and it optimises for the thing you can see: the screen renders, the button submits, the data shows up. That's the demo, and the demo passes. Security is the part you can't see in the demo: the check that one user can't read another's data, the key that shouldn't be in the browser, the endpoint that should refuse an unauthenticated request. None of it changes what the happy path looks like, so none of it gets built unless someone asks.
This isn't a knock on the tools. It's a description of what they were trained to do: produce code that satisfies the request. "Build me a dashboard where users see their orders" produces a dashboard where users see their orders. It does not produce "…and where user A provably cannot reach user B's orders," because you didn't say that, and in the demo, with one logged-in user, the difference is invisible.
Why the model leaves the holes
Three forces compound. The model fills in the most common pattern from its training data, and a lot of that data is tutorials and quick-start code that were never meant for production. It has no view of your threat model: it doesn't know whether this is a hobby project or handling payment data. And each round of prompting can quietly undo a safeguard from a previous round, because the model is optimising the current request, not preserving the last one.
A real breach, in detail
In 2025 a security researcher, Matt Palmer, crawled 1,645 applications built on the AI platform Lovable and found 303 insecure endpoints across 170 of them (roughly one in ten) where anyone could read, modify, or delete any row in the database. Exposed data included names, phone numbers, payment details, and API keys. The root cause wasn't exotic: the generated apps talked to their database directly from the browser with no row-level access rules. It became CVE-2025-48757, rated critical (CVSS 9.3).
Nothing about those 170 apps looked broken. They shipped, they worked, real users signed up. The hole was structural and invisible from the front end, exactly the kind of gap this course is about. The numbers that circulate alongside stories like this ("X million keys leaked") are often unverified; the documented CVE is enough to make the point on its own.
The five holes, and the rest of this course
The good news: the holes are not infinite or mysterious. AI-built apps leak in a small number of predictable places, and each maps to a chapter:
- Data access: the database trusts the browser, so any user can reach any row (chapter 2).
- Secrets: API keys and credentials end up in client code or in git (chapter 3).
- Authorization: login exists, but per-resource ownership checks don't (chapter 4).
- Exposed surface: forgotten endpoints, open APIs, and unverified webhooks (chapter 5).
- Everything else before launch: headers, dependencies, errors, and the checklist that catches the rest (chapter 6).
Work through them in order and you'll close the gaps that produced incidents like the Lovable CVE. None of it requires being a security specialist. It requires knowing the five places to look and what "done" means in each.
In one line each
- AI tools optimise for the visible demo, not the invisible safeguards: security is the part nobody prompts for.
- Generated holes look finished: the app works perfectly for the one tester who has permission to see everything.
- CVE-2025-48757 exposed ~170 Lovable apps via missing database access rules: structural and invisible from the front end.
- The holes are predictable and few: data access, secrets, authorization, exposed surface, and pre-launch hardening.
Where to go next