AI-Generated App Security Risks: The 2026 Audit Guide

The state of AI-generated app security in 2026

In 2026, roughly 60% of new application code is AI-generated or AI-assisted. The tools -- Lovable, Bolt, Cursor, Replit, v0, Claude Code -- have collapsed the time from idea to deployed URL from weeks to hours. The security infrastructure has not kept pace.

The market incentive for AI coding tools is speed and feature completeness: does it work when I click the button? Security controls are invisible until they fail. They add complexity to prompts, create friction in demos, and generate no visible value during development. So the tools omit them, and the builders -- often non-technical founders -- do not know to ask for them.

The result is a generation of production applications with structural security holes that would have been caught in any traditional code review.

Who is affected

Not limited to hobbyist side projects. We regularly see the following in apps handling real user data:

• SaaS platforms with 500-5,000 paying subscribers
• Internal tools at companies with 50-500 employees
• Healthcare-adjacent apps storing appointment notes or intake forms
• Fintech MVPs processing Stripe payments
• B2B portals where tenant isolation is a contractual requirement

The numbers

• 45-65% of AI-generated code contains at least one exploitable vulnerability (CSA 2025, Escape.tech 2026, CSET 2024)
• 89% of Lovable apps in our 50-app audit had RLS disabled or misconfigured on at least one table (AppStuck internal data)
• CVE disclosures directly attributed to AI-generated code reached 35 in March 2026 alone, up from 6 in January
• AI-assisted commits show a 3.2% secret-leak rate vs. a 1.5% baseline across all public GitHub commits

The 10 most common security flaws in AI-generated apps

Severity legend

Flaw 1: RLS disabled or misconfigured -- Severity: Critical

Supabase creates tables with RLS disabled by default. AI tools generate schema, generate frontend queries, and ship. The RLS step requires deliberate configuration not part of the prompt-to-code flow.

Vulnerable pattern:

// Lovable-generated -- VULNERABLE
const { data } = await supabase
  .from('orders')
  .select('*')
  .eq('user_id', userId);
// Without RLS, removing the .eq() filter returns ALL rows from ALL users

Why AI tools make this mistake: AI generates code that works in the happy path. The threat model -- a different user calling the same endpoint without the filter -- is not part of the prompt.

How to detect:

• Open Supabase Dashboard, Database > Tables. Any table without the RLS shield icon is exposed.
• Run: SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';
• From browser console: supabase.from('your_table').select('*') without filters. If you get rows that are not yours, RLS is off.

How to fix:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users read own orders"
  ON orders FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "Users insert own orders"
  ON orders FOR INSERT
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "Users update own orders"
  ON orders FOR UPDATE
  USING (auth.uid() = user_id);

Flaw 2: Secrets in client-side code -- Severity: Critical

VITE_ or NEXT_PUBLIC_ prefixed env vars are bundled into the JavaScript shipped to the browser.

Vulnerable pattern:

# .env -- VULNERABLE
VITE_STRIPE_SECRET_KEY=sk_live_...
VITE_SUPABASE_SERVICE_ROLE_KEY=eyJ...

// Used in frontend component
const stripe = new Stripe(import.meta.env.VITE_STRIPE_SECRET_KEY);

How to detect: run grep -r "sk_live|sk_test|AKIA|service_role|private_key" src/

How to fix: move all secret API calls to a server function. Environment variables that touch secrets must never have a client-side prefix.

// Fixed: server-side API route
import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY); // no NEXT_PUBLIC_
export default async function handler(req, res) {
  const paymentIntent = await stripe.paymentIntents.create({
    amount: req.body.amount,
    currency: req.body.currency
  });
  res.json({ clientSecret: paymentIntent.client_secret });
}

Flaw 3: No CSRF or origin validation -- Severity: High

AI tools almost never generate CSRF tokens or SameSite cookie attributes. Any state-changing route that relies on cookies for authentication is vulnerable to cross-site request forgery -- a malicious site can trigger account changes using the victim's active session.

Vulnerable pattern:

// Express route -- VULNERABLE (no CSRF protection)
app.post('/api/account/update', authenticate, async (req, res) => {
  await db.user.update({ where: { id: req.user.id }, data: req.body });
  res.json({ success: true });
  // A malicious site can POST here with the victim's session cookie
});

How to detect: run your production URL through securityheaders.com. Below B grade needs attention. Missing X-Frame-Options and Content-Security-Policy are first indicators.

How to fix:

import csrf from 'csrf-csrf';
import helmet from 'helmet';
const { doubleCsrfProtection } = csrf({
  getSecret: () => process.env.CSRF_SECRET,
  cookieName: '__Host-psifi.x-csrf-token',
  cookieOptions: { sameSite: 'strict', secure: true, httpOnly: true },
});
app.use(helmet());
app.use(doubleCsrfProtection);

Flaw 4: Predictable IDs / IDOR -- Severity: High

AI tools generate API routes with no ownership check.

Vulnerable pattern:

app.get('/api/invoices/:id', authenticate, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice); // No ownership check -- any authenticated user gets any invoice
});

How to detect: search for route handlers that fetch by a path parameter (req.params.id) without also filtering by req.user.id or equivalent.

How to fix:

app.get('/api/invoices/:id', authenticate, async (req, res) => {
  const invoice = await db.invoice.findUnique({
    where: { id: req.params.id, userId: req.user.id }
  });
  if (!invoice) return res.status(404).json({ error: 'Not found' });
  res.json(invoice);
});

Flaw 5: Auth tokens in localStorage -- Severity: High

Supabase's default client-side SDK stores session token in localStorage. Anything readable by JavaScript is readable by XSS and malicious browser extensions.

Vulnerable pattern:

// Default Supabase client-side setup -- VULNERABLE
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
);
// Session JWT is stored in localStorage by default --
// accessible to any JavaScript running on the page, including injected scripts

How to detect: Open DevTools > Application > Local Storage. Strings starting with eyJ are JWTs -- they should not be there.

How to fix:

import { createServerClient } from '@supabase/ssr';
export function createClient(cookieStore) {
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
    {
      cookies: {
        get: (name) => cookieStore.get(name)?.value,
        set: (name, value, options) =>
          cookieStore.set({ name, value, ...options, httpOnly: true, secure: true }),
        remove: (name, options) =>
          cookieStore.set({ name, value: '', ...options, httpOnly: true }),
      },
    }
  );
}

Flaw 6: No rate limiting on auth endpoints -- Severity: Medium

Search your codebase for login and password-reset routes. If you do not see a rateLimit middleware, it is missing.

Vulnerable pattern:

// Login handler -- VULNERABLE (no rate limiting)
app.post('/api/auth/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await verifyCredentials(email, password);
  if (!user) return res.status(401).json({ error: 'Invalid credentials' });
  res.json({ token: generateToken(user) });
  // No throttle -- thousands of password attempts per second are possible
});

How to detect: grep -r "login\|password-reset\|forgot-password" src/ -- then check each handler for rateLimit.

How to fix:

import rateLimit from 'express-rate-limit';
const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 10,
  message: { error: 'Too many attempts, please try again later.' },
  standardHeaders: true,
});
app.post('/api/auth/login', authLimiter, loginHandler);
app.post('/api/auth/reset-password', authLimiter, resetPasswordHandler);

Flaw 7: SQL injection via raw queries -- Severity: Critical

Vulnerable pattern:

const results = await db.query(
  `SELECT * FROM products WHERE category = '${req.query.category}'`
);

How to detect: grep -rn "WHERE.*\${" src/

How to fix:

const results = await db.query(
  'SELECT * FROM products WHERE category = $1',
  [req.query.category]
);
// Or with Prisma:
const results = await prisma.$queryRaw`SELECT * FROM products WHERE category = ${req.query.category}`;

Flaw 8: XSS via dangerouslySetInnerHTML -- Severity: High

Vulnerable pattern:

function CommentBody({ comment }) {
  return <div dangerouslySetInnerHTML={{ __html: comment }} />;
}

How to detect: grep -rn "dangerouslySetInnerHTML" src/ -- then check each result for sanitisation.

How to fix:

import DOMPurify from 'dompurify';
import { marked } from 'marked';
function CommentBody({ comment }) {
  const rawHtml = marked(comment);
  const clean = DOMPurify.sanitize(rawHtml, {
    ALLOWED_TAGS: ['p', 'strong', 'em', 'a', 'ul', 'ol', 'li', 'code', 'pre'],
    ALLOWED_ATTR: ['href', 'target', 'rel'],
  });
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}

Flaw 9: Webhook endpoints without signature verification -- Severity: High

Vulnerable pattern:

app.post('/api/webhooks/stripe', async (req, res) => {
  const event = req.body; // No signature check
  if (event.type === 'checkout.session.completed') {
    await fulfillOrder(event.data.object); // Anyone can fake this
  }
  res.json({ received: true });
});

How to detect: grep -r "webhook\|stripe.*event\|clerk.*event" src/ -- for each handler, check for a signature verification step.

How to fix:

app.post('/api/webhooks/stripe', express.raw({ type: 'application/json' }), async (req, res) => {
  const sig = req.headers['stripe-signature'];
  let event;
  try {
    event = stripe.webhooks.constructEvent(req.body, sig, process.env.STRIPE_WEBHOOK_SECRET);
  } catch (err) {
    return res.status(400).send(`Webhook error: ${err.message}`);
  }
  if (event.type === 'checkout.session.completed') {
    await fulfillOrder(event.data.object);
  }
  res.json({ received: true });
});

Flaw 10: Sensitive data in logs and analytics -- Severity: Medium

Vulnerable pattern:

// Sentry config -- VULNERABLE
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  sendDefaultPii: true, // Sends cookies, session data, user IP, full request bodies
});
// Every error event captures: email, session token, credit card fields, passwords

How to detect: search for Sentry.init and check sendDefaultPii. Search for analytics event calls that pass user objects directly.

How to fix:

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  sendDefaultPii: false,
  beforeSend(event) {
    if (event.request?.data) {
      delete event.request.data.password;
      delete event.request.data.creditCard;
    }
    return event;
  },
});

Severity overview

OWASP Top 10 mapped to AI-generated code

Tool-specific risk profiles

The pattern across all tools: security is a non-functional requirement. Prompts do not mention it. The tools do not volunteer it. The output works. The gaps are invisible until someone exploits them.

The 89% RLS finding: what we found auditing 50 live Lovable apps

This is our data. 50 Lovable-generated applications that came to AppStuck for rescue or hardening between Q4 2025 and Q1 2026. Real apps: SaaS tools, client portals, internal platforms, one healthcare-adjacent intake form.

Source: Lovable Review 2026: The View From 300+ Production Rescues

Methodology:

• 50 Lovable apps reviewed between Q4 2025 and Q1 2026
• Each received a structured security assessment covering all 10 flaw categories
• RLS tested by querying the Supabase REST API directly (bypassing the application layer)
• Results classified by severity using CVSS 3.1

Findings table:

The median app had 4.7 distinct security issues. Not a single app was clean across all categories. The most dangerous combination -- present in 31 of the 50 -- was RLS disabled plus secrets in client-side code.

How to audit your own AI-generated app: 30-minute checklist

Tools needed: browser DevTools, terminal access to codebase, Supabase Dashboard, securityheaders.com, TruffleHog (free secret scanner).

Step 1: Scan for secrets (5 min)

npx trufflehog filesystem ./ --only-verified
grep -r "sk_live\|sk_test\|AKIA\|service_role\|private_key\|supersecretkey" src/
grep -r "VITE_\|NEXT_PUBLIC_" src/ | grep -i "key\|secret\|token\|password"

Step 2: Check RLS status in Supabase (5 min)

SELECT tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY rowsecurity;
-- Any row with rowsecurity = false is exposed

Also: open DevTools console on your deployed app. Run: window.supabase.from('users').select('*'). If you get other users' data, RLS is off.

Step 3: Check security headers (2 min)

Go to securityheaders.com and enter your production URL. Below B grade needs attention. Missing Content-Security-Policy and Strict-Transport-Security are first priorities.

Step 4: Audit environment variables (5 min)

For every key in .env that contains "secret", "key", "private", or "token": is it referenced in any file in src/ that runs in the browser? If yes, it is exposed.

Step 5: Check auth token storage (3 min)

Open DevTools > Application > Local Storage. Are there keys that look like JWTs (strings starting with eyJ)? If yes, they are in localStorage.

Step 6: Test one endpoint for IDOR (5 min)

Log in as User A, get the ID of a record they own. Log in as User B in incognito. Try accessing User A's record ID from User B's session. If you get the record, you have an IDOR.

Step 7: Check webhook handlers (5 min)

grep -r "webhook\|stripe.*event\|clerk.*event" src/

For each handler: is there a signature verification step before business logic runs?

Step 8: Review Sentry config (5 min)

Search for Sentry.init. Confirm sendDefaultPii is not set to true. Confirm no PII fields in analytics event calls.

Compliance considerations: GDPR, SOC 2, HIPAA

GDPR

GDPR requires "appropriate technical and organizational measures" (Article 32). Missing RLS and secrets in client bundles are plausible violations if they result in unauthorized access to EU personal data.

• RLS disabled means any authenticated user can access other users' personal data -- likely a reportable breach under GDPR Article 33 (72-hour notification requirement)
• PII sent to Sentry or Mixpanel (US-based) may violate data transfer restrictions without Standard Contractual Clauses
• No data retention policies creates GDPR Article 5(e) storage limitation issues

SOC 2

SOC 2 Type II is increasingly required for B2B SaaS. AI-generated apps fail multiple Trust Services Criteria:

• CC6 (Access Controls): no RLS, no IDOR protection, no MFA
• CC7 (System Operations): no logging of sensitive data access, no alerting on anomalous patterns
• CC8 (Change Management): no audit trail of who changed what in the database
• CC9 (Risk Mitigation): no documented threat model, no vulnerability management process

HIPAA

If your app stores Protected Health Information, HIPAA's Security Rule requires technical safeguards including access controls, audit controls, and transmission security. AI-generated apps fail every category. Do not put PHI in a Lovable app without a deliberate HIPAA compliance build-out. HIPAA violations carry civil penalties from $100 to $50,000 per violation, capped at $1.9M per violation category per year.

When to hire a security audit

Cost and timeline:

• Assessment only ($2,500-$3,500): full written security report, severity ratings, prioritized fix list, no code changes
• Assessment + remediation ($3,500-$7,000): report plus all fixes applied, re-test after changes, 1-2 weeks delivery

See AppStuck enterprise services for security work within larger engagements.

Case study: Security Hardening in practice (composite, anonymized)

Client profile: B2B SaaS, 800 subscribers, Lovable + Supabase, $35,000/month through Stripe, non-technical founder, 4 months in production, no security review. An enterprise prospect requested a security questionnaire, which triggered the audit.

Assessment findings:

• 6 of 8 tables had RLS fully disabled. Two had RLS enabled but policies that allowed all authenticated users to read all rows.
• Stripe secret key present in a VITE_ environment variable, bundled into the production JavaScript.
• Stripe webhook handler accepted all POST requests without signature verification -- a test POST with a fake event body triggered a fulfillment action.
• No rate limiting on login or password-reset endpoints.
• Sentry initialized with sendDefaultPii: true -- user emails and plan names were captured in every error event.

Remediation:

• RLS enabled on all 8 tables; 24 explicit policies written for SELECT, INSERT, UPDATE, DELETE.
• Stripe operations moved to a Supabase Edge Function with the secret key in Supabase Vault. VITE_ key removed and rotated.
• Stripe webhook handler rewritten with stripe.webhooks.constructEvent signature verification.
• Rate limiting added to auth endpoints via Edge Function middleware.
• Sentry config updated: sendDefaultPii: false, beforeSend hook strips email and plan fields.

Outcome: 9 business days total. Enterprise prospect's security questionnaire answered satisfactorily. Client closed the enterprise contract the following week -- worth more than 10x the cost of the security engagement.

Frequently asked questions

Are AI-generated apps secure?

Not by default. Research from multiple sources in 2025-2026 indicates that 45-65% of AI-generated code contains at least one exploitable vulnerability. Our own audit of 50 live Lovable apps found 89% had Supabase Row Level Security disabled or misconfigured, exposing all user data to any authenticated session.

What is the biggest security risk in Lovable apps?

Disabled or misconfigured Supabase Row Level Security (RLS). Without RLS, any logged-in user can read, modify, or delete every other user's data using the Supabase API directly. This is the most common and most severe flaw we find in Lovable-generated codebases.

Is vibe coding a security risk?

Yes, in its current state. Vibe coding tools optimize for speed and working features, not security. They do not know your threat model, your compliance requirements, or your user data sensitivity. The resulting code often lacks authentication guards, input validation, rate limiting, and proper secret management.

How do I fix RLS in my Supabase app?

Run ALTER TABLE your_table ENABLE ROW LEVEL SECURITY; for every table in Supabase, then define explicit policies for SELECT, INSERT, UPDATE, and DELETE. A policy that restricts reads to the row owner looks like: CREATE POLICY user_isolation ON your_table FOR SELECT USING (auth.uid() = user_id);

What does an AI app security audit cost?

AppStuck's Security Hardening tier is priced at $2,500-$7,000 fixed-fee, delivered in 1-2 weeks. Scope depends on codebase size and the number of integrations. The engagement includes a full security report, all fixes applied to the codebase, and a post-fix re-test.

Can AI-generated code pass a SOC 2 audit?

Not without remediation. AI-generated code typically lacks the access control documentation, secret rotation procedures, logging standards, and data handling policies required for SOC 2 Type II. It can be made SOC 2 compliant, but it requires deliberate hardening work beyond what any vibe coding tool currently provides.

Do Bolt, Cursor, and Replit have the same security problems as Lovable?

Similar categories of problems, different severity profiles. Bolt shares the Supabase RLS issue when paired with Supabase backends. Cursor and Claude Code generate more structurally sound code because they work within existing codebases, but they still omit rate limiting, CSRF headers, and webhook signature verification by default.

What OWASP Top 10 risks apply to AI-generated apps?

All ten apply to some degree. The highest-frequency matches are A01 (Broken Access Control, via missing RLS and IDOR), A02 (Cryptographic Failures, via secrets in client code), A03 (Injection, via raw SQL queries), A05 (Security Misconfiguration, via disabled RLS and missing headers), and A07 (Identification and Authentication Failures, via tokens in localStorage).

How long does a security audit of a vibe-coded app take?

A thorough security audit of a typical Lovable or Bolt app (10-30 database tables, 3-5 integrations) takes 3-5 business days for assessment and 5-10 days for remediation, depending on severity. AppStuck's full Security Hardening engagement is scoped at 1-2 weeks start to finish.

What is IDOR and why is it common in AI-generated apps?

IDOR (Insecure Direct Object Reference) happens when your API returns records by a predictable ID without checking ownership. AI tools generate endpoints like GET /api/orders/:id without verifying that the requesting user owns that order. An attacker who knows any valid order ID can iterate through all orders. The fix is always an ownership check in the query or middleware.

Related resources

• Lovable Review 2026: The View From 300+ Production Rescues
• AI App Rescue: how AppStuck works
• Lovable development and rescue services
• Bolt rescue and hardening
• Cursor code review and hardening
• Node.js security patterns
• React security patterns
• AppStuck for enterprise teams

Book a Security Discovery Call

30 minutes. We review your stack, confirm which of these flaws are present, and scope a remediation engagement if needed. No obligation.

Book a call Learn how AppStuck works