We Analyzed Apps Built with Lovable and Bolt — Here Are the Security Vulnerabilities We Found

AI app builders are creating a new category of software. Tools like Lovable and Bolt let non-technical founders and solo developers go from idea to deployed product in hours. The speed is real. So are the security gaps.

We ran PreBreach scans against a sample of 40+ publicly deployed applications built with Lovable and Bolt over a three-month period. These were real production apps with real users -- SaaS products, marketplaces, internal tools, and customer-facing dashboards. We are not naming specific apps, but the patterns are consistent enough to be systemic.

This is not a criticism of Lovable or Bolt as products. They do what they promise: rapid application generation. But their security model assumes the developer will handle hardening after generation. Most developers do not.

Here is what we found.

---

The Numbers

Out of 40+ applications scanned:

• 87% had at least one High or Critical severity finding
• 72% had exposed API keys or secrets in client-side JavaScript bundles
• 65% had missing or misconfigured Supabase Row Level Security policies
• 58% had no rate limiting on any endpoint
• 45% had API endpoints with no authentication checks
• 40% had CORS configured to allow all origins
• 33% were running with debug mode or verbose error output in production

The median app had 6 distinct vulnerability findings across multiple categories. The median CVSS v4.0 score for the most severe finding per app was 7.8 (High).

---

Vulnerability 1: Supabase Row Level Security Missing by Default

Prevalence: 65% of apps using Supabase

When Lovable or Bolt generates a Supabase-backed application, it creates tables, sets up the client connection, and writes CRUD operations. What it frequently does not do is enable Row Level Security (RLS) on those tables.

Without RLS, any authenticated user (or anyone with the anon key, which is public by design) can read, insert, update, and delete any row in any table. The Supabase client connects directly to PostgREST, and PostgREST respects RLS policies. No policies means no restrictions.

What we found:

• User tables with full read access, exposing emails, names, and hashed passwords
• Order/transaction tables where any user can view all orders
• Admin tables with no access restrictions, allowing privilege escalation
• File metadata tables exposing private file URLs

How to check:

Go to your Supabase dashboard, navigate to each table, and check the RLS status. Or run this query:

SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';

If rowsecurity is false for any table, it is unprotected.

How to fix:

Enable RLS and add policies for each table:

-- Enable RLS
ALTER TABLE public.projects ENABLE ROW LEVEL SECURITY;

-- Users can only read their own projects
CREATE POLICY "Users can view own projects"
  ON public.projects FOR SELECT
  USING (auth.uid() = user_id);

-- Users can only insert their own projects
CREATE POLICY "Users can create own projects"
  ON public.projects FOR INSERT
  WITH CHECK (auth.uid() = user_id);

-- Users can only update their own projects
CREATE POLICY "Users can update own projects"
  ON public.projects FOR UPDATE
  USING (auth.uid() = user_id);

-- Users can only delete their own projects
CREATE POLICY "Users can delete own projects"
  ON public.projects FOR DELETE
  USING (auth.uid() = user_id);

Every table that stores user data needs policies. There are no shortcuts.

---

Vulnerability 2: Exposed API Keys in Client Bundles

Prevalence: 72% of apps

AI-generated code frequently places API keys, service tokens, and secret credentials directly in client-side files. Sometimes they are hardcoded. Sometimes they are in environment variables that get bundled into the frontend.

What we found:

• Supabase service role keys (full admin access to the database) in client bundles
• Stripe secret keys (can create charges, read customer data, issue refunds)
• OpenAI/Anthropic API keys (financial exposure from token consumption)
• SendGrid/Resend API keys (can send email as your domain)
• Third-party SaaS API keys for integrations

How to check:

View your production site's JavaScript bundles. In Chrome DevTools, go to Sources > your domain > static/js. Search for strings like sk_, sk-, service_role, Bearer, apikey, or any key prefix used by your third-party services.

You can also search your source code:

# Search for common secret patterns in your codebase
grep -rn "sk_live\|sk-\|service_role\|PRIVATE_KEY\|SECRET_KEY" src/ --include="*.ts" --include="*.tsx" --include="*.js"

How to fix:

Move all secret API calls to server-side code. In a Next.js app, this means Server Actions, API routes, or server-only modules.

// BAD: Client-side file calling Stripe with secret key
const stripe = new Stripe(process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY);

// GOOD: Server-side API route
// app/api/checkout/route.ts
import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!); // No NEXT_PUBLIC_ prefix

export async function POST(request: Request) {
  // Handle checkout server-side
}

If Lovable or Bolt generated client-side code that calls a third-party API with a secret key, you need to refactor that call to go through your server.

---

Vulnerability 3: No Server-Side Validation

Prevalence: 58% of apps

AI builders generate frontend form validation, but frequently skip server-side validation entirely. The client validates that an email field contains an email. The server accepts whatever it receives.

What we found:

• API endpoints accepting arbitrary JSON without schema validation
• Type coercion vulnerabilities where string fields accept objects or arrays
• Missing length limits allowing oversized payloads
• No sanitization of user-generated content before database storage

The problem in practice:

A form that collects a username with a 50-character limit on the frontend can be bypassed by sending a direct API request. If the database column is TEXT with no constraint, an attacker can insert megabytes of data. If that data is rendered on another user's page, it can cause denial of service or XSS.

How to fix:

Add Zod validation to every endpoint. This is non-negotiable for any input that reaches your database or an external service.

import { z } from "zod";

const createPostSchema = z.object({
  title: z.string().min(1).max(200).trim(),
  content: z.string().min(1).max(50000).trim(),
  tags: z.array(z.string().max(30)).max(10).optional(),
});

export async function POST(request: Request) {
  const body = await request.json();
  const result = createPostSchema.safeParse(body);

  if (!result.success) {
    return Response.json({ error: result.error.flatten() }, { status: 400 });
  }

  // result.data is validated and typed
}

---

Vulnerability 4: Default Firebase Security Rules

Prevalence: Found in 100% of Firebase-backed apps in our sample (smaller subsample of 8 apps)

When Bolt generates a Firebase-backed application, it often deploys with the default security rules or overly permissive rules that allow any authenticated user to read and write any document.

Default rules that ship with development setups:

// These rules allow anyone to read/write everything
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;  // Wide open
    }
  }
}

Or the slightly less terrible but still dangerous:

// Any authenticated user can read/write everything
allow read, write: if request.auth != null;

How to fix:

Write granular rules that enforce ownership and access control:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }

    match /projects/{projectId} {
      allow read: if request.auth != null &&
        resource.data.ownerId == request.auth.uid;
      allow create: if request.auth != null &&
        request.resource.data.ownerId == request.auth.uid;
      allow update, delete: if request.auth != null &&
        resource.data.ownerId == request.auth.uid;
    }
  }
}

---

Vulnerability 5: Missing Authentication on API Endpoints

Prevalence: 45% of apps

AI-generated APIs often implement the "happy path" without considering who is calling the endpoint. The generated code handles creating, reading, updating, and deleting resources. It does not check whether the requester should be allowed to do those things.

What we found:

• CRUD endpoints for user data with no authentication
• Admin functionality accessible without admin role verification
• Webhook endpoints that do not verify the webhook signature
• File upload endpoints with no authentication

How to fix:

Create an auth middleware or utility function and apply it to every route:

// lib/require-auth.ts
import { createClient } from "@/lib/supabase/server";

export async function requireAuth() {
  const supabase = await createClient();
  const { data: { user }, error } = await supabase.auth.getUser();

  if (error || !user) {
    throw new Response(JSON.stringify({ error: "Unauthorized" }), {
      status: 401,
      headers: { "Content-Type": "application/json" },
    });
  }

  return user;
}

// app/api/projects/route.ts
import { requireAuth } from "@/lib/require-auth";

export async function GET() {
  const user = await requireAuth();

  const projects = await db.project.findMany({
    where: { userId: user.id },
  });

  return Response.json(projects);
}

---

Vulnerability 6: CORS Allow-All Configuration

Prevalence: 40% of apps

During development, AI builders set CORS to accept requests from any origin. This configuration persists to production.

What we found:

// Generated code pattern
headers: {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "GET, POST, PUT, DELETE, OPTIONS",
  "Access-Control-Allow-Headers": "*",
}

The risk: With Access-Control-Allow-Origin: *, any website can make JavaScript requests to your API. If your API uses cookies for authentication, this creates a direct path for cross-origin data theft. An attacker's site can call your API endpoints, and if the user is logged into your app, the browser attaches their session.

How to fix:

Restrict CORS to your actual frontend domains:

// next.config.js
const nextConfig = {
  async headers() {
    return [
      {
        source: "/api/:path*",
        headers: [
          {
            key: "Access-Control-Allow-Origin",
            value: process.env.NEXT_PUBLIC_APP_URL || "https://yourdomain.com",
          },
          {
            key: "Access-Control-Allow-Methods",
            value: "GET, POST, PUT, DELETE, OPTIONS",
          },
          {
            key: "Access-Control-Allow-Headers",
            value: "Content-Type, Authorization",
          },
        ],
      },
    ];
  },
};

---

Vulnerability 7: No Rate Limiting

Prevalence: 58% of apps

None of the applications in the affected group had any form of rate limiting on any endpoint. This includes authentication endpoints, AI proxy endpoints, payment endpoints, and data-fetching APIs.

Real-world consequences:

• Login endpoints can be brute-forced at thousands of requests per second
• AI endpoints (proxying OpenAI/Anthropic) can rack up hundreds of dollars in minutes
• Data export endpoints can be used to scrape entire databases
• Contact form endpoints become spam cannons

The fix for this was covered in our Next.js security checklist -- use Upstash, Vercel WAF, or Cloudflare rate limiting rules. Any form of rate limiting is better than none.

---

Vulnerability 8: Debug Mode in Production

Prevalence: 33% of apps

AI-generated applications frequently ship with development-mode configurations that expose internal state:

• Detailed error stack traces returned to the client
• Source maps enabled in production builds
• Console logging of sensitive data (auth tokens, user objects, API responses)
• Development database URLs pointing to localhost or unprotected instances
• Next.js reactStrictMode errors visible in production console

The risk: Debug information gives attackers a detailed map of your application internals. Stack traces reveal file paths, dependency versions, and database query structures. Source maps expose your entire codebase.

---

What Built-In Security Checks Miss

Both Lovable and Bolt have made improvements to their security posture. Lovable added Supabase RLS reminders. Bolt improved its environment variable handling. These are positive steps, but they address symptoms rather than the systemic issue.

What their built-in checks currently do not cover:

1. Runtime behavior: Static code generation cannot test how the deployed application behaves under adversarial conditions. A RLS policy that exists syntactically may be logically flawed.

2. Configuration drift: The generated app may be secure at creation time, but edits by the developer (or further AI-assisted edits) can regress security settings.

3. Infrastructure-level issues: SSL configuration, HTTP header security, DNS misconfiguration, and exposed admin panels are deployment concerns outside the builder's scope.

4. Business logic flaws: AI builders generate CRUD operations, but cannot reason about application-specific abuse scenarios like price manipulation, race conditions in booking systems, or coupon stacking.

5. Third-party integration security: Whether a Stripe webhook verifies signatures, whether an OAuth flow validates state parameters, or whether a file upload checks content types requires integration-specific security knowledge.

---

How to Secure Your AI-Generated App

If you have built an application with Lovable, Bolt, or any AI app builder, here is a prioritized remediation plan:

Immediate (Do Today)

1. Audit your client-side bundles for exposed API keys. Search your deployed JavaScript for any secret key patterns.
2. Enable Supabase RLS on every table. If you are using Firebase, review your security rules.
3. Remove Access-Control-Allow-Origin: * and set it to your actual domain.

This Week

4. Add authentication checks to every API endpoint and Server Action. Create a reusable auth middleware.
5. Add Zod validation to every endpoint that accepts user input.
6. Add rate limiting to authentication endpoints and any AI-proxying routes.

This Month

7. Implement security headers (CSP, HSTS, X-Frame-Options).
8. Disable source maps and debug output in production.
9. Set up automated security scanning to catch regressions as you continue building.

Ongoing

10. Run a security scan after every major feature addition. AI-assisted development moves fast, and each new feature is an opportunity to introduce new vulnerabilities.

---

The Broader Problem

AI app builders are democratizing software development. That is genuinely valuable. But they are also creating thousands of production applications that lack basic security hardening. The developers using these tools are often non-technical founders or early-stage teams who do not have the security expertise to audit the generated code.

The solution is not to stop using AI builders. It is to pair them with automated security testing that can catch the gaps. Build fast with Lovable or Bolt, then validate the result before real users depend on it.

PreBreach was built specifically for this use case. Our scanner understands the architectures these tools generate (Supabase, Firebase, Vercel, Next.js) and tests for the exact vulnerability patterns described in this post. A scan takes 30-60 minutes, with plans starting at $29/month.

Scan your AI-built app now.