LOVABLE VS BOLT VS CURSOR: SAME SPEC, THREE APPS, THREE PROFILES

This is a controlled experiment. One spec, three platforms, three deployed apps, one scan. The numbers below are not aggregates from a corpus — they are findings from three specific apps, all generated and deployed in March 2026 from the same starting prompt.

The point is to show that “is platform X secure” is a question with a structurally different answer for each platform, even when the spec is identical.

The spec

Verbatim, given as the first message to each platform’s generator:

Build a SaaS web app for freelancers to send invoices. Users sign up with email + password. Each user can create invoices with line items, tax, and a due date. Invoices can be marked sent, paid, or overdue. Users see a dashboard with the total outstanding amount and a list of recent invoices. Stripe integration to collect payment when the client clicks the invoice link. Use a backend so I can add features later.

We accepted the first deployable build on each platform. No follow-up prompts, no refactoring, no manual edits.

Results — total findings

Total counts are within noise of each other. The story is in the distribution.

Critical findings, side by side

Three completely different failure profiles emerge from the same spec.

Failure profile by platform

Lovable

Concentration: database authorization. All four critical findings are RLS gaps. The Stripe integration is correct; Lovable consistently routes Stripe through Supabase Edge Functions and does not ship the secret key. The auth flow is correct; users are authenticated via Supabase Auth.

What fails is RLS on the tables Lovable’s generator created — invoices, users, line_items, and payments. None had policies. The dashboard shows them as RLS-disabled.

Modal failure mode. Permissive policy or policy missing entirely.

Single-line fix per table. Add using (auth.uid() = user_id) to a select policy on each.

Bolt.new

Concentration: secret handling. Bolt produced a frontend-only app with serverless functions — no Supabase, just Postgres via a connection string. The connection string ended up in the frontend bundle. The Stripe sk_live_ key, also in the bundle. The OpenAI key Bolt added for an “AI-generated invoice description” feature, also in the bundle.

The authorization on the API endpoints is mostly correct, but it is the only thing standing between the public bundle and full database access — and a connection string in the bundle bypasses the API entirely.

Modal failure mode. Secrets shipped to the browser via VITE_* environment variables.

Single-line fix per secret. Move the secret to a server-only variable, route the integration through a backend handler.

Cursor

Concentration: custom API authorization. Cursor produced the most architecturally clean app — Next.js with API routes, JWT-based auth, environment-variable secrets. The secrets are correctly server-only. The auth flow is correct.

What fails is the authorization logic in the API routes. Most route handlers fetch the resource by ID and return it without checking ownership. Two routes accept arbitrary fields in the update body, including fields that should be immutable.

Modal failure mode. Missing ownership check in route handlers.

Single-line fix per route. Add if (resource.user_id !== session.user.id) return new Response(null, { status: 404 }).

What this means for the “is X safe” question

The three apps produced from the same spec have:

• Comparable total finding counts (24, 26, 29)
• Three completely different concentrations of critical findings
• Three completely different audit checklists for the builder

A founder reading “is Lovable safe” and getting a generic answer will not realize that the Lovable-specific audit is different from the Bolt-specific audit which is different from the Cursor-specific audit. Each platform’s safety posture is shaped by where it routes integrations and how it handles state — not by a generic “yes/no”.

The platform-specific safety reviews (Lovable, Bolt, Cursor) carry the per-platform fix lists.

CWE / OWASP profile per platform

The same total finding count, three completely different CWE distributions. Each platform’s “modal failure” maps to a different fix surface.

The Lovable and Cursor profiles overlap on OWASP API1 (BOLA) but the layer differs — Lovable’s BOLA lives in the database via missing RLS, Cursor’s lives in the application via missing checks in the route handler. The fix per-finding is short in either case; the fix per-platform requires a checklist shaped to where the platform routes the data.

Pattern walkthroughs per failure profile

Each modal failure surfaced in this experiment has a companion pattern walkthrough that shows the bug on a live URL and walks the fix per stack:

• Lovable shape — The Supabase service-role key in your frontend bundle and BOLA in AI-generated CRUD (when RLS is bypassed via service-role)
• Bolt shape — The Supabase service-role key in your frontend bundle (same root pattern: secrets in the bundle) and Source maps and .git in production
• Cursor shape — BOLA in AI-generated CRUD and Mass assignment
• Shared baseline — CORS = * with credentials = true, Stripe webhook trust, and the auth-flow gaps in Magic links, OTP, and password resets

What was the same

All three apps:

• Allowed CSRF on state-changing endpoints (no platform added CSRF protection by default)
• Shipped without rate limits on signup or login
• Returned verbose error messages including stack traces in development mode (still on at deploy time)
• Lacked HSTS headers
• Lacked Content-Security-Policy headers

These five items are the platform-independent baseline failures of vibe-coded apps. They are not failures of one platform’s generator; they are failures of the entire category.

Methodology

Builds. Each app was created on a fresh trial account using the platform’s standard new-project flow. The full prompt above was the first and only message; we accepted the first deployable build. No iterations, no follow-ups, no manual edits. All three were built within a 48-hour window in March 2026.

Scan. Identical scan run against each deployed URL. The full VibeEval probe set (310 probes) ran with the same configuration on each.

Reproducibility. The prompt is reproducible. The artifacts are not — AI builders are non-deterministic. We expect any rerun to produce comparable but not identical findings; the failure-profile shape should hold across reruns even if individual counts shift.

Vendor outreach. Lovable, StackBlitz (Bolt.new), and Anysphere (Cursor) were notified 30 days before publication. Responses included where provided.

Calibration via gapbench equivalents. Each per-platform modal failure has a matched scenario on gapbench.vibe-eval.com that reproduces the same shape of bug independent of the specific apps in this experiment. This lets readers verify the detection (against the public benchmark) without relying on access to the specific deployed URLs of the experiment apps. Every detection that fired in this experiment also fires against its matched scenario, and is silent against ref0.

Reproduce on the public benchmark

The deployed experiment apps are not public — they were built on platform trial accounts, and re-publishing the URLs would surface user PII the platforms generated as test data. The reproducibility anchor for this study is the matched gapbench scenarios:

Vendor responses

[Reserved for vendor responses received during the disclosure window. None received as of publication. We will append responses below as they arrive.]

Citations

VibeEval. Lovable vs Bolt vs Cursor: Same Spec, Three Apps, Three Security Profiles. May 2026. https://vibe-eval.com/data-studies/lovable-bolt-cursor-same-spec/

Related

• Pattern walkthrough: The Supabase service-role key in your frontend bundle — Lovable + Bolt root pattern
• Pattern walkthrough: BOLA in AI-generated CRUD — Cursor root pattern
• Pattern walkthrough: Mass assignment — the self-editable role finding
• Pattern walkthrough: CORS = * with credentials = true — shared baseline failure
• Data study: 2026 AI App Security Benchmark
• Data study: Supabase RLS in the Wild
• Data study: Lovable Regression Longitudinal Study — what happens to the Lovable app after this snapshot
• Comparison: Best Security Scanner for AI-Generated Apps
• Safety reviews: Is Lovable Safe? · Is Bolt Safe? · Is Cursor Safe?