Lovable Leaks Source Code: The $6.6B BOLA Vulnerability

You type a prompt. The AI generates a full-stack React application with a connected database. You deploy it with one click. That is the promise of Lovable, an AI app builder with 8 million users and a $6.6 billion valuation.

But abstraction comes with a cost.

The Breach Nobody Owned

A security researcher operating as @weezerOSINT recently proved that anyone could access a Lovable user's source code, database credentials, and AI chat histories. They did not use an advanced zero-day exploit. They created a brand new free account and made five basic API calls.

This exposure leaked real user data. Names, job titles, and LinkedIn profiles from apps built on the platform were laid completely bare.

The worst part is not the vulnerability itself. It is how the company handled it.

48 Days of Denial

The researcher reported the vulnerability to Lovable on March 3. The company ignored it for 48 days.

When the exploit finally went public on Twitter, Lovable panicked. Their story changed three times in under 24 hours:

1. First claim: They did not suffer a data breach. They attempted to spin the exposure as "intentional behavior" and blamed "unclear documentation."
2. Developer pushback: The community immediately called out the absurdity of classifying leaked database credentials as a documentation issue.
3. Blame shift: Lovable shifted responsibility to HackerOne, their bug bounty partner, claiming they misunderstood the severity and closed the ticket as intended behavior.
4. Finally, the truth: The company admitted a backend permissions rewrite accidentally disabled access controls. Public projects created before the patch were fully exposed.

This pattern tells you everything. When a $6.6 billion platform fumbles for 48 days, then pivots through three different narratives instead of owning the mistake, you know something is structurally broken.

Understanding BOLA: The Most Critical API Flaw

The vulnerability at the heart of this is called Broken Object Level Authorization (BOLA). It is consistently ranked as the most critical API security risk in the industry by OWASP.

BOLA happens when an API endpoint takes an ID from a client request and returns data without checking if the user actually owns that data.

The Vulnerable Pattern

Here is what a broken endpoint looks like in code:

# Vulnerable BOLA Endpoint
@app.get("/api/projects/{project_id}")
async def get_project(project_id: int, user: User = Depends(get_current_user)):
    # Flaw: We check if the user is logged in, but not if they own the project.
    project = db.query(Project).filter(Project.id == project_id).first()
    return project

If you log in and request /api/projects/123, you get your project. But if you change the request to /api/projects/124, the server just hands over the next user's project. No brute-forcing is required. You just change an ID in the network tab of your browser.

Authentication is not enough. Checking whether you are logged in means nothing if the backend does not verify you own the resource.

The Fix: Object-Level Authorization

A secure backend enforces object-level authorization by explicitly filtering queries against the authenticated user's ID.

# Secure Endpoint
@app.get("/api/projects/{project_id}")
async def get_project(project_id: int, user: User = Depends(get_current_user)):
    # Fix: Enforce object-level authorization by filtering on owner_id.
    project = db.query(Project).filter(
        Project.id == project_id,
        Project.owner_id == user.id
    ).first()
    
    if not project:
        raise HTTPException(status_code=404, detail="Project not found")
    return project

Every single query must be scoped to the authenticated user. This is not optional. This is baseline security.

When an AI builder abstracts away your backend code, you assume these checks are happening natively. As Lovable proved, that is a dangerous assumption.

The Pattern: Third Major Disaster

This incident is not an isolated mistake. It is Lovable's third major security disaster in recent memory.

Previous Incidents

Incident 1: Row Level Security (RLS) misconfiguration - A researcher found missing RLS policies that exposed private data across 170 different Lovable apps. Because Lovable relies heavily on Supabase, this meant anyone could query the database directly.

Incident 2: Backward authentication logic - Another researcher found an AI-generated EdTech app that exposed 18,000 student records. The authentication logic was wired entirely backward. It blocked logged-in users and allowed anonymous users full access.

Incident 3: The BOLA exposure - Leaked source code, credentials, and chat histories across all public projects built before the patch.

This is not bad luck. This is a pattern.

Lovable claims to see 100,000 new projects built every single day. When a platform controls the code generation, the hosting, and the database infrastructure, a single misconfiguration creates an instant, massive blast radius.

The Vibe Coding Trap

The industry calls this new paradigm vibe coding. You describe a workflow, and the AI handles the implementation details.

It is a massive productivity accelerator. I use AI to write code every day. But here is the dirty truth: AI models optimize for functionality, not security. The model wants the app to compile and run so you feel successful. Adding strict Row Level Security, setting up JWT validation, and testing edge cases introduces friction. So the AI simply skips it.

The platform is supposed to catch these gaps. But when the platform itself pushes an update that breaks authorization, you are left holding the bag.

You cannot outsource your security posture to a language model. A $6.6 billion platform valuation does not protect your users from a broken API endpoint. If you let an AI write your backend, you still own the technical debt.

What to Do If You Built on Lovable

If you deployed a project on Lovable prior to this fix, you must act under the assumption that your environment is compromised.

Immediate Actions

1. Rotate credentials: Change your database passwords immediately. Invalidate every API key stored in your environment variables.

2. Check the logs: Look for unauthorized access or unusual query patterns matching the timeframe of the vulnerability (before the patch was applied).

3. Audit Row Level Security: If you use Supabase or PostgreSQL directly, verify that your Row Level Security policies explicitly restrict access to auth.uid().

Example of a secure RLS policy:

ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

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

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

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

4. Notify users: If your app stores user data, inform them of the potential exposure and recommend password resets.

5. Consider migration: Evaluate whether your architecture needs to move off a platform with this track record.

The Bigger Picture

AI app builders are phenomenal for rapid prototyping. They unlock productivity for founders and developers who do not have the time or budget to build from scratch. But they are not a replacement for understanding your security model.

The promise of "one-click deployment" is seductive. The reality is that you are still responsible for what goes into production.

Ship fast. But never deploy a backend you do not fundamentally understand.