The Lovable BOLA Breach: 48 Days of Exposed Vibe-Coded Projects

What Actually Happened

The vulnerability was a textbook BOLA, sometimes called IDOR (Insecure Direct Object Reference). According to The Next Web and Metamindz's writeup, the API trusted the object ID in a request without checking whether the caller was allowed to see that object. A free account could walk other users' profiles, public projects, source code, and hardcoded Supabase database credentials.

The reported timeline: a researcher disclosed it to the bug bounty program on 3 March 2026, it became public on 20 April 2026, and the window of exposure was 48 days. The data reachable through the flaw included source code, Supabase credentials, names, job titles, LinkedIn profiles, Stripe customer IDs, and in some cases student accounts belonging to minors. Affected records reportedly traced back to employees at Accenture Denmark, Copenhagen Business School, and individuals at large tech firms. This was not a theoretical exposure of "some test apps." It was production data for real businesses built on the platform.

BOLA in Plain Terms

BOLA is what happens when your API checks who you are (authentication) but forgets to check what you are allowed to touch (authorization). The request is from a logged-in user, so it looks legitimate. The bug is that the server never asks "does this record belong to this user?"

// ❌ BAD - the BOLA pattern. Logged in, but no ownership check.
// pages/api/projects/[id].ts
export default async function handler(req, res) {
  const { id } = req.query;
  // Any authenticated user can pass any id and read the row.
  const project = await db.project.findUnique({ where: { id } });
  return res.json(project);
}

An attacker does not need to "hack" anything here. They log in with their own free account, then change the id in the URL to someone else's. OWASP has ranked Broken Access Control as the number one web application risk since 2021, precisely because this mistake is so easy to make and so hard to see in a code review.

Why Vibe-Coded Apps Are Uniquely Exposed

AI coding tools are very good at producing an endpoint that works for the happy path: fetch the record, return it. They are far less reliable at adding the ownership filter, because nothing in the prompt "build me a projects API" forces them to. The Cloud Security Alliance's 2026 research note on AI-generated code cites Veracode testing that roughly 45% of AI-generated code samples introduce an OWASP Top 10 weakness, with access-control and injection flaws prominent among them.

There is a second multiplier specific to platforms like Lovable, Bolt, and v0: they generate the database layer too, often wiring a Supabase service-role key directly into the app. So a single access-control miss does not just leak one record. It can leak the credentials that unlock the entire database. The blast radius of one BOLA bug becomes "everything," which is exactly what the Lovable disclosure described.

Why Your Existing Tooling Stayed Silent

The uncomfortable part of this story is that none of the standard "is my app secure" tools would have flagged it. Dependency scanners answer a different question.

A BOLA bug has no CVE, because it is your code, not a library. It produces no console error, no failed build, no slow page. It passes every green checkmark while quietly serving other people's data. That invisibility is the whole problem.

How to Fix It and What to Check This Week

The fix is to scope every object lookup to the authenticated user, in the query itself, not in an if statement you might forget.

// ✅ GOOD - ownership is enforced inside the query.
export default async function handler(req, res) {
  const user = await requireUser(req);            // 401 if not logged in
  const project = await db.project.findFirst({
    where: { id: req.query.id, ownerId: user.id }, // attacker's id never matches
  });
  if (!project) return res.status(404).end();      // do not even leak existence
  return res.json(project);
}

1. Audit every route that reads a record by ID. For each one, confirm the database query filters by the current user, team, or tenant. This is the single highest-value review you can do on an AI-built app.
2. Get database keys out of the codebase. A Supabase service-role key in your repo or bundle is a master key. Move it to a server-only environment variable and rotate it.
3. Return 404, not 403, for objects the user cannot see. A 403 confirms the record exists, which helps an attacker enumerate.
4. Scan before you ship. Tools like VibeDoctor (vibedoctor.io) automatically scan your codebase for unprotected API routes, missing authorization checks, and hardcoded database credentials, and flag the specific file paths and line numbers. It is the class of bug that broke Lovable and it is checked by default. Free to sign up.
5. Test it like an attacker. Log in as user A, grab an object ID, then try to fetch it while logged in as user B. If it returns data, you have a BOLA.

FAQ