The security risks hiding inside AI-generated apps

A vibe-coded app can run perfectly in front of you and still be wide open underneath. That is the uncomfortable part of AI app generation: the demo works, the client is impressed, and none of that tells you whether the login screen can be bypassed or the database is exposed to anyone who inspects a network request.

AI models are trained to produce something that looks finished. They are not trained to ask “who else could reach this endpoint.” That gap is where most of the real risk in AI-generated software lives, and it rarely shows up until someone goes looking for it.

The numbers are worse than most builders assume

Independent research on LLM-generated code backs this up with a specific, uncomfortable stat: models successfully compile working code in around 90% of cases, but roughly 45% of that code carries at least one OWASP Top 10 vulnerability - things like bypassable login checks or injection flaws that let an attacker manipulate a query.

That is not a rare edge case. It means close to half of what a tool like Lovable, Bolt, or Base44 generates for you on a given prompt has a real, exploitable weakness baked in from the start. The app still “works” in every visible sense. The vulnerability just doesn’t announce itself until a user (or attacker) finds it.

Where the risk actually comes from

Security failures in AI-generated apps tend to cluster around a handful of repeatable patterns:

• Client-side authentication checks. The AI implements “is this user allowed to see this page” in the browser instead of on the server. Since browser code is fully visible and editable, anyone can open dev tools, flip the check, and get in.
• Hardcoded secrets. Non-technical builders testing locally often don’t know how to manage .env files properly, so API keys and database connection strings get typed directly into the code. Those files then get pushed to a public GitHub repo without anyone noticing.
• Permissive database rules. To get a prompt working fast, the AI configures database access broadly rather than narrowly. If any other part of the app is compromised, that wide-open configuration turns a small bug into a full data leak.
• Over-scoped OAuth connections. Wiring up an integration like Google Calendar or Slack requires configuring OAuth scopes by hand. Ask for too much access and you’ve created a liability; miss a scope and the integration silently breaks. Either way, the builder is making a security decision they usually don’t realize they’re making.

None of these show up in a demo. They show up in a security audit, a curious user’s browser console, or a breach notification months later.

Why “it works” is the wrong test

The trap is that AI app builders reward you for shipping fast, and fast feedback loops train you to test the happy path only. You click through the signup flow, the dashboard loads, the form submits, everything looks right. None of that tells you whether the CRUD action behind that form checks who is making the request.

Testing security properly means asking different questions:

1. Can a logged-out user reach this URL directly?
2. Can User A see or edit User B’s records by changing an ID in the address bar?
3. Are role checks enforced on the server, or only hidden in the UI?
4. Do OAuth-connected integrations request only the scopes they actually use?

Most non-technical builders don’t know to ask these questions, and most AI coding assistants won’t raise them unprompted unless you explicitly say “review this for security issues” - and even then, the fix is another generated patch, not a structural guarantee.

The alternative: infrastructure you don’t have to audit

This is the actual argument for building business apps on a platform with security built into the foundation rather than generated per project. Softr is a useful example of the opposite approach: authentication, role permissions, and data access rules are native platform features, not code the AI writes fresh for every app.

Concretely, that means:

• Server-side CRUD by default. Database read/write actions run on Softr’s servers, not in the browser, so there’s no client-side check to bypass in the first place.
• Visual role permissions instead of hand-written RLS. User Groups and Data Restrictions control who sees and edits which records, configured visually and verified through preview impersonation instead of being buried in database policy code that’s easy to misconfigure.
• Pre-verified OAuth connectors. Integrations with tools like Google Calendar, HubSpot, and Stripe use Softr’s already-approved developer applications, so builders never touch raw OAuth scopes or store third-party credentials themselves.
• Utility auth flows shipped out of the box. Login, password reset, OTP, and domain-restricted signup are pre-built, so there’s no custom authentication logic for an AI to get subtly wrong.

That doesn’t mean AI-generated tools are unsuitable for everything. For a personal project, an internal prototype nobody outside your team will touch, or a static landing page, the risk profile is low and vibe coding is genuinely the faster path. The calculation changes the moment real users, real customer data, or external logins enter the picture.

What to check before you ship

If you’re building on a code-generating AI tool anyway, a short list is better than none:

• Grep the codebase for hardcoded API keys and connection strings before any commit.
• Confirm access-control checks are duplicated on the server, not just hidden in the frontend.
• Review OAuth scopes granted to every connected integration and strip anything unused.
• Ask a second person, ideally someone technical, to try to access another user’s data by guessing or changing an ID in the URL.

That checklist won’t make generated code as safe as infrastructure that was never generated in the first place, but it catches the failures that show up most often. For a portal, CRM, or internal tool that real people will log into with real data, the more durable fix is choosing a foundation where the security work was already done, so it isn’t a coin flip on every prompt.