Security Vulnerabilities in AI-Generated Apps, A UK Guide

The evidence base is now substantial

In 2025 and early 2026, enough AI-generated applications have been deployed and independently audited to produce a reliable picture of the security risks. The numbers are not encouraging.

Veracode’s 2025 study tested more than 100 large language models and found that 45% of the generated code samples failed its security tests. This is a study result, not a failure rate for every deployed application. See the study’s published methodology and results.

The vulnerability patterns are not random. They cluster around seven predictable areas, each of which arises from the same root cause: AI tools optimise for producing functional code quickly, not for producing secure code. The security gaps they leave are consistent enough that an experienced engineer reviewing an AI-generated codebase for the first time knows which areas to check first.

The seven vulnerability categories

1. Secrets in client-accessible code or public repositories

This is the single most common and immediately damaging vulnerability in AI-generated applications. It manifests in two ways.

The first is secrets in the client-side JavaScript bundle. In a Next.js application, any environment variable prefixed with NEXT_PUBLIC_ is included in the bundle that is sent to the browser. It is accessible to anyone who opens the developer tools. AI tools frequently place API keys in this prefix category either through misunderstanding of the convention or because the tool was prompted to "make the API call work" without considering where the key should live. A Supabase service_role key exposed in a NEXT_PUBLIC_ variable can bypass Row Level Security. Current sb_secret_ keys are also privileged secrets: browser rejection does not stop an attacker using them through another client. Keep both kinds server-side and rotate an exposed key.

The second is secrets committed to the repository. .env files containing API keys and database credentials are frequently committed to GitHub accidentally, either because the .gitignore was not correctly configured or because the AI tool added them to the tracked files. GitHub's own secret scanning catches some of these, but not all, and a committed secret remains in the git history even after the file is removed.

Immediate action if you find this: Rotate the exposed credential immediately. The secret is compromised from the moment it was exposed, not from the moment you discover it. Do not wait until after remediation to rotate it.

2. Supabase Row Level Security misconfigurations

Supabase's Row Level Security is a database-level access control mechanism. When correctly configured, it ensures that a user can only read and write the rows in the database that belong to them. When misconfigured, it produces one of two failure modes: every authenticated user can access every row in every table (full data exposure), or users cannot access any data at all because the policies are too restrictive.

The researcher reporting CVE-2025-48757 found 170 exposed projects among 1,645 Lovable showcase sites scanned in March 2025. The CVE concerns insufficient Row Level Security and is disputed by the supplier. CVE record; researcher’s account.

RLS policy review requires a human with knowledge of the intended data access model. The AI cannot reliably self-audit because the correct policy depends on decisions about who should be able to see what, which requires understanding the application's business logic rather than its code.

3. Firebase security rules that allow public read or write access

Firestore database creation offers Test mode, which allows public reads and writes, and Production mode, which denies mobile and web client access until rules permit it. Server credentials follow their own access controls. Review the selected mode and write least-privilege rules before production; public access is not an inevitable default. See Firebase’s database documentation.

The correct production Firebase security rules are specific to the application's data model and access requirements. A rule that allows any authenticated user to write to any document is nearly as bad as no rules at all for most applications. Rules must be written to enforce the principle of least privilege at the collection and document level.

4. Authentication flows with exploitable gaps

Authentication implementation in AI-generated applications tends to handle the happy path, normal login and registration, correctly, while leaving edge cases exploitable. Common gaps include: no rate limiting on login endpoints (allowing brute-force attacks), email verification that can be bypassed by directly accessing authenticated routes, JWT tokens with no expiry or with excessively long expiry (allowing a stolen token to be used indefinitely), and OAuth state parameter handling that is vulnerable to CSRF attacks.

These gaps are not visible in normal use. They are visible to an attacker who is specifically looking for them, and they are visible in a security-aware code review.

5. Missing input validation and injection exposure

Input validation is the practice of verifying that data submitted by users conforms to the expected format before processing it. AI-generated code frequently handles expected inputs correctly and does not validate unexpected inputs at all. The consequences range from application crashes (unexpected data breaks the processing logic) to SQL injection or NoSQL injection (crafted inputs that manipulate database queries), cross-site scripting (inputs that inject executable JavaScript into the application's output), and path traversal (inputs that navigate the server's filesystem).

In Supabase and Firebase applications, injection attacks at the database query level are less common than in traditional SQL applications because the SDKs provide parameterised queries by default. Input validation at the application layer is still required for business logic integrity and for XSS prevention in any data that the application displays back to users.

6. No rate limiting on API endpoints

API endpoints in AI-generated applications typically have no rate limiting. A user who discovers the API endpoint for user registration can register thousands of accounts in seconds. A user who discovers a paid action endpoint can trigger it repeatedly without paying. A competitor can scrape the application's data at will. Rate limiting is a standard production requirement that AI tools consistently omit because the application functions without it in a development context with a single user.

For applications deployed on Vercel, assess Vercel WAF rate limiting. Other platforms may use middleware or an edge service. Test the limits against authentication, paid actions and expensive API endpoints, including how region-specific counters affect enforcement.

7. Dependency hallucination and supply chain risk

AI coding tools sometimes suggest npm packages that do not exist, or packages that exist but are not the package the AI described. When a developer installs a package from a hallucinated name, there are three possible outcomes: the installation fails because the package does not exist (the benign case), the installation succeeds because a different package with that name exists and is benign, or the installation succeeds because a package with that name has been deliberately published by an attacker to intercept exactly this kind of hallucination-driven installation. This last case is called "slopsquatting" and is a documented attack vector in AI-assisted development.

The mitigation is auditing the installed dependency list against the intended packages: checking that each dependency is the correct and maintained package, that the version is current, and that the package has not been reported as malicious. This is a one-time audit task, not an ongoing operational requirement.

UK-specific regulatory context

The vulnerabilities described above are security problems in any context. In the UK, several of them carry specific regulatory implications.

A controller must notify the regulator of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to pose a risk to people’s rights and freedoms. Communication to individuals has a separate high-risk threshold and exceptions under Article 34. See Article 33 and Article 34.

For firms in scope, FCA operational resilience rules require important business services to stay within impact tolerances during severe but plausible disruption; assess the technology those services depend on. An AI-built application handling financial data without a security review is an operational risk governance issue as well as a technical one.

For legal applications, Paragraph 6.3 of the SRA Code of Conduct requires client affairs to be kept confidential unless disclosure is required or permitted by law or the client consents. Technology and cyber security controls support that duty. An AI-built application handling client communications or matters data without a security review does not meet that standard.

The correct response before launch

A pre-launch security review of an AI-generated application does not require a full penetration test. It requires a senior engineer to review the codebase with the seven vulnerability categories in mind, spending focused time on the areas where AI tools consistently fail.

The AI App Diagnostic Audit includes a security posture review as a core component. The written report rates each finding by severity and provides specific remediation instructions. For applications in regulated sectors, the report includes the applicable UK regulatory context for each security finding.

The alternative, launching without a review and discovering the vulnerability after a user's data is exposed or a breach notification obligation is triggered, carries a remediation cost and a reputational cost that substantially exceeds the cost of the review.