The security holes AI coding tools leave in every app
I've now looked under the hood of enough AI-built apps to stop being surprised. Different founders, different ideas, different tools — Cursor, Claude, Lovable, Bolt, take your pick — and the same handful of AI generated code vulnerabilities show up almost every time. Not because the tools are bad. Because of what they were built to optimize for, and what they weren't.
An AI coding tool's whole job is to turn your words into working software as fast as possible. It's remarkably good at that job. What it isn't doing, unless you explicitly ask, is thinking like an attacker. Security isn't a feature you can see on the screen, so it doesn't show up in the demo, and it doesn't show up in what the tool defaults to either. Here are the gaps I run into constantly.
1. No auth check on the action that matters. The button is hidden from the interface if you're not logged in, or not an admin — and that feels like security while you're clicking through it. But hiding a button in the frontend doesn't stop anyone from calling the underlying API directly. If the server itself isn't checking who's making the request before it does something sensitive — delete a record, change a price, view someone else's data — then the lock is on the display, not the door. Anyone with a browser's dev tools open can walk right past it.
2. Data anyone can read, because nothing says otherwise. This is the one that should worry you most. Most AI-built apps sit on top of a database that, by default, will hand back any row to anyone who asks — unless something explicit tells it not to. That something is usually row-level security, and it's opt-in, not automatic. So the app "works" in every demo, because you're only ever looking at your own data. Nobody notices that a stranger could change one number in a URL and see someone else's.
3. Secrets sitting in code that ships to the browser. API keys, service credentials, admin tokens — they need to live somewhere, and the fastest place to put them while you're building is directly in the code the AI just wrote. The trouble is that a lot of that code ends up in the client bundle, which means it ends up in your users' browsers, which means anyone who opens the page source can read it. What was meant to be a private key becomes a public one the moment it ships.
4. Nothing checks what a user actually typed in. A form field, a URL parameter, a file upload — AI tools will happily wire these straight through to a database query or a server action, trusting that whatever arrives is what you expected. Most of the time it is. The rest of the time it's someone testing whether it is, and an app with no input validation gives them a very generous answer.
5. API responses that say more than they should. It's common for an AI-built endpoint to just hand back the whole database record because that was the easy way to build the feature — even when the interface only displays three of those fields. The other fields didn't disappear. They're sitting in the network response, visible to anyone who opens the browser's network tab, whether or not the page ever renders them.
None of these five show up when you click through your own app. That's exactly the problem — they're invisible to the person who built it and glaringly obvious to someone who goes looking. I wrote about the broader pattern behind this in what your AI-built app is missing before launch: the tool builds precisely what you describe, and everything you didn't think to describe just... isn't there.
So how do you actually check for these?
Honestly — most owners can't, not with confidence, and that's not a knock on you. Checking whether row-level security is actually enforced, or whether an endpoint is leaking fields, means reading the code the way an attacker would, not the way a user would. That's a different skill than the one that got your app built in the first place, and it's not one most non-technical founders have reason to have.
That's the specific gap the Launch-Ready Audit is built for: someone goes through your app's auth, data access, API responses, and input handling with the same eye an attacker would use, and hands you back exactly what's exposed, with evidence, ranked by what would actually hurt if someone found it first. Data isolation and auth checks are two of the non-negotiables — if a stranger can reach another user's data or trigger an action they shouldn't be able to, that's a hard stop regardless of how polished everything else looks.
Your Turn: pick one screen in your app that shows sensitive data — an account page, a dashboard, an order history — and open your browser's network tab while you load it. Look at the raw response, not the rendered page. If you see fields you didn't expect, or you're not sure whether the server would stop a different user's ID from working in that same request, that's worth having someone check properly before a stranger checks it for you.
See how the Launch-Ready Audit works →
— Kyle Tysvaer, Founder, Insightful Eye Marketing