Is Your AI-Generated App Secure Enough to Ship?

No - and the gap is bigger than most founders expect. Your app passing every functional test, handling registrations correctly, and loading fast means the AI did its job. It does not mean the app is secure. Security vulnerabilities do not appear in happy-path tests. They appear when someone deliberately tries to break your app - by injecting malicious input, probing exposed endpoints, or replaying requests your auth system was not designed to catch.

The AI that built your app was optimizing for functional correctness, not adversarial resistance. Those are different goals, and the data shows it.

Veracode's 2025 analysis of over 100 large language models found that 45% of AI-generated code contains security flaws. A separate scan of 5,600 applications built with vibe coding tools found over 2,000 vulnerabilities, more than 400 exposed secrets (API keys, credentials, database tokens), and 175 instances of exposed personally identifiable information - in apps that were working fine.

The core issue: AI models are trained to generate code that runs correctly. Security requires a different mindset - anticipating what an attacker will try to do, not just what a legitimate user will do. Without deliberate security intent baked into every generation, you get apps that work until someone breaks them.

If you built with an AI tool and shipped without a security review, you almost certainly have issues. The question is whether you find them before your users do.

The failures in AI-generated code are not random. They follow predictable patterns because the models make the same category of mistakes repeatedly.

Cross-site scripting (XSS): Veracode found that AI-generated code fails XSS protection 86% of the time. The AI outputs user input directly into the DOM without sanitization. Anyone who can get a user to click a link can inject JavaScript into your app.

Log injection: 88% failure rate. When the AI logs user actions, it often includes unsanitized input - meaning an attacker can write fake log entries, obscure their tracks, or corrupt your logging system.

Missing security headers: In a study of 15 AI-built applications, zero set any security headers. Content-Security-Policy, X-Frame-Options, HTTP Strict Transport Security - these are not configured by default in AI-generated apps. They are also not hard to add, which is why their absence is surprising.

No CSRF protection: Same study, same result - zero of 15 apps implemented Cross-Site Request Forgery protection. An attacker can trick a logged-in user into performing actions they did not intend.

Hardcoded secrets: The scan of 5,600 vibe-coded apps found over 400 exposed API keys, database credentials, and access tokens embedded directly in code. AI tools frequently generate working connection strings with real credentials included - and developers ship that code.

Hallucinated dependencies: A USENIX Security 2025 study found that AI models hallucinate package names in 5.2% of commercial model outputs and 21.7% of open-source model outputs. A non-existent package in your dependency tree is an open door for a supply chain attack - an attacker registers the package name and your next npm install pulls their malware.

Authentication bypass patterns: The Cloud Security Alliance found a 153% increase in design-level security flaws including authentication bypass and improper session management in AI-generated code. The AI builds an auth system that looks correct and fails in edge cases an attacker will find.

None of these are exotic. They are the OWASP Top 10 applied to AI-built apps - the same vulnerabilities that have been breaking production systems for 20 years, now being reproduced at scale by tools that are better at generating code than assessing its security.

OWASP - the Open Web Application Security Project, the non-profit that sets the industry standard for web security - published its Top 10 for LLM Applications in November 2024. It covers AI systems as both builders and components in production apps.

For a founder whose app was built by an AI tool, three entries matter most.

LLM02: Sensitive Information Disclosure. AI-generated apps handle user data - emails, payment information, personal details. The model may not have implemented proper access controls or data minimization. If your app stores more than it needs, exposes it through predictable URL parameters, or returns it in API responses without checking who's asking, you have a sensitive information disclosure problem. The OX Security scan found 175 instances of exposed PII across 5,600 apps.

LLM05: Improper Output Handling. When the AI generates code that processes user input and returns output, it often fails to sanitize what comes back. This is the mechanism behind XSS. Whatever a user submits - text, file names, query parameters - needs to be treated as untrusted and sanitized before it touches your DOM, your database, or your logs.

LLM06: Excessive Agency. When AI coding agents can call external APIs, write to databases, or execute system commands, they are often given more permissions than the task requires. An AI that needed read access ended up with write access. A function that should touch one table can touch five. Excessive agency means a single exploited function gives an attacker far more than it should.

The NIST AI Risk Management Framework takes a broader view - its Govern-Map-Measure-Manage model asks organizations to maintain inventories of AI models, APIs, datasets, and permissions, and to map end-to-end data flows. For a founder running a vibe-coded app, the practical translation is simple: do you know what your app can access, and does it need all of it?

If you don't have answers to those questions, you have not done a security review.

Further reading: How Do You Keep an AI-Generated Codebase Maintainable?

The demo works. It worked in every test. It worked for you and three friends. Then you opened it to real users and something broke that you didn't anticipate.

This is not a failure of the AI. It is a structural feature of how vibe-coded apps are built. The AI optimizes for the happy path - the user does the thing you expected, the app responds correctly, everyone is satisfied. Real users do not stay on the happy path. They hit refresh repeatedly, submit the form twice, probe the URL structure, and try inputs that should not work.

Security researchers at Georgia Tech launched the Vibe Security Radar in May 2025 to track CVEs traceable to AI coding tools. By March 2026 they had catalogued 74 CVEs from AI-generated code - a number that was 6 just months earlier. The security debt from AI-built apps is becoming visible at scale.

The speed compounds the problem. AI-assisted developers commit code 3-4x faster than non-AI developers. Monthly security findings in studied repositories rose from roughly 1,000 to over 10,000 in six months - a tenfold increase. Moving fast is exactly the point of vibe coding. Moving fast also means shipping vulnerabilities faster.

This plays out in documented incidents, not just statistics. Lovable - one of the leading vibe-coding platforms, with 8 million users - had a BOLA vulnerability left unpatched for 48 days after a security researcher reported it through its own bug bounty program. By the time it was patched, 18,697 user records had been exposed, including accounts from UC Berkeley and UC Davis. The vulnerability was in AI-generated Row Level Security policies - exactly the kind of database access control that looks correct until an attacker probes the edge cases.

The financial stakes are real. IBM's research found that security incidents involving AI-generated code (shadow AI incidents) average $4.63 million per breach - $670,000 above the baseline for standard breaches. An app that took a week to build can create a breach that takes months and millions to resolve.

The distinction that matters: "it works" means the app does what you intended. "Secure enough to ship" means the app survives what you didn't intend - and what someone else deliberately tries.

Most of the foundational checks can be run before you write a single line of custom code. The question is whether you run them at all.

Static analysis (SAST). Tools like Snyk, Checkmarx, or Veracode scan your codebase for known vulnerability patterns - injection flaws, insecure functions, missing input validation. Run this before every deploy, not just before launch. Many CI/CD systems can run it automatically on every commit.

Secrets scan. Check your codebase and your git history for API keys, database credentials, and access tokens. AI tools frequently generate working connection strings with real credentials in them. If you committed those, the secrets are in git history even if you remove them from the current code. Tools like GitLeaks or TruffleHog scan for this. Rotate any credentials that have been exposed.

Dependency audit. Run npm audit or equivalent to check every package your app depends on for known CVEs. Also verify that your packages exist - AI hallucinates package names in a material percentage of outputs, and a non-existent package is an attack vector waiting to happen.

Security headers. Use securityheaders.com to check whether your deployed app sets Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and HSTS. These are quick to add and they close a class of attacks that require zero application-specific knowledge.

Authentication and session review. Check that sessions expire, that tokens are invalidated on logout, that password reset flows cannot be abused, and that there is no way to access one user's data while authenticated as another. This is where automated tools have limits - a tool can flag missing expiry headers, but assessing whether your auth logic is correct requires a human who has seen auth bypass patterns before.

Payment and admin code. Never trust AI-generated payment processing or admin functionality without a senior engineer review. These are the two areas where a single flaw creates the largest exposure.

One thing that will not fix the problem: asking the AI to improve its own code for security. A peer-reviewed study accepted at IEEE-ISTAS 2025 found a 37.6% increase in critical vulnerabilities after just five iterations of LLM refinement. The AI produces code that looks more polished - but with measurably worse security underneath. Iterative prompting is not a substitute for a human security review.

Joylo runs an AI Confidence Score on every build - automated security, scalability, reliability, integrations, and code quality audits that flag uncertain code before it ships. That is the baseline. For the human review layer - the auth logic, payment flows, and database access controls that automated tools cannot fully assess - that requires Expert Assist or a Co-Build plan, where a named in-house engineer is already in your codebase.

If you need to know right now whether your existing AI-built app is secure, the honest answer is: you need an engineer to look at it, not just a scan.

The mainstream AI app builders - Lovable, Replit, Bolt - do something genuinely useful. They generate working apps fast. What they do not do is guarantee those apps are secure.

When something breaks, each of these platforms routes you to community forums, partner networks, or freelancer marketplaces. None offers in-house engineers. None provides a written production guarantee. If the AI gets stuck in a security hole it created, there is no named human accountable for fixing it.

Lovable builds on Supabase, which handles auth and the database layer. That gives you a reasonable foundation - Supabase has security features. The problem is that AI-generated Row Level Security policies and Edge Functions are exactly the category where design-level security flaws appear at high rates. The AI writes the policy, the policy has a gap, a real user finds the gap. There is no Lovable engineer who can see it or fix it.

Replit's AI agent has full access to your environment - it can write to databases, call external APIs, execute shell commands. This is the excessive agency problem from OWASP. The agent is productive precisely because it has broad permissions. Those same permissions become a risk when the agent or its generated code behaves unexpectedly.

Bolt.new generates fast prototypes. The community is helpful. When you need someone who knows your codebase and has a contractual obligation to fix it, the community is not the right answer.

Joylo is built by HST, an 18-year Dublin engineering firm. The same engineers who build production systems for regulated industries - the people who have actually cleaned up broken vibe-coded apps - built the security audit layer into every Joylo build. The AI Confidence Score runs security checks on every single build, on every plan including free. That is the automated layer.

For the human layer: Expert Assist puts a named in-house engineer into your codebase within 24 hours at a fixed price, with a written SLA. On Co-Build plans that engineer is engaged by default. No freelancer marketplace, no forum. A specific person, accountable by contract, who already knows your code.

The question is not whether you trust AI to write secure code. The question is who is accountable when it doesn't.

Further reading: What Is Vibe Coding and What Can It Do?

A real security review is not running a scanner and checking the output. It is an engineer reading your code with the question: "how would I break this?"

Here is what actually happens in a production-readiness review of an AI-built app.

Static analysis first. Run SAST tools to get a map of known vulnerability patterns. This takes minutes and surfaces the most obvious issues - the hardcoded credentials, the SQL injection patterns, the insecure function calls. Fix these before the human review starts.

Dependency tree audit. Check every package the app depends on. Are they real? Are they maintained? Do they have known CVEs? Is there a package in your dependencies that matches a hallucinated name the AI suggested? This is especially important for Node.js projects, where the average app has hundreds of transitive dependencies.

Auth and session flow walkthrough. An engineer traces every authentication path: login, registration, password reset, session expiry, logout, token invalidation. They look for the edge cases the AI did not anticipate - what happens if someone calls the password reset endpoint twice in rapid succession? Can sessions be replayed after logout? Can you access another user's resources if you know the pattern of their ID?

Database access review. What can each user role read and write? Are your queries parameterized or do they interpolate user input directly? If you are using Supabase or a similar platform, are the Row Level Security policies actually correct, or do they have gaps that let a crafted request bypass them?

Infrastructure and secrets check. Are environment variables set correctly in your deploy environment, not in your codebase? Are database connection strings scoped to the minimum necessary permissions? Is there anything in your git history that should not be there?

The NSA, CISA, and FBI's joint AI data security guidance from May 2025 describes this as "Secure by Design" - security built in from inception, not bolted on after the fact. For apps that were already built without that principle, it means a retrofit: audit first, fix the critical issues, and build the secure patterns into everything you add going forward.

Hussein Janoowala's engineering team does this routinely on apps that arrive broken, and on Joylo-built apps before they go to production. The common thread: not exotic attacks, just the predictable gaps that appear when code is generated for functionality rather than security.

You don't need to understand every vulnerability class to act on this. You need to know the app was reviewed by someone who does.

Start building on Joylo for free - every build gets an automated security audit before it ships. Already have an AI-built app that needs a security review? Expert Assist puts a named engineer in your codebase within 24 hours.