Lovable BOLA Exposure, What to Rotate Before You Wait for a Bulletin

A researcher-disclosed Broken Object Level Authorization flaw in Lovable's API reportedly allowed free accounts to read other users' source code, database credentials, AI chat histories, and customer data on projects created before November 2025. Lovable has denied it is a breach, said it reverted the change that made public-project chats visible, and at time of writing has not published a formal incident bulletin. If you have a pre-cutoff project, the safest posture is to act on your own.

What actually happened

BOLA (Broken Object Level Authorization) is OWASP API Security Top 10 #1: the API checks that you're logged in, but not whether you own the thing you're asking for. Lovable's /projects/{id}/* endpoints validate the Firebase auth token but skip the ownership check. Five API calls from a free account are enough to enumerate another user's project.

According to the researcher, the flaw sat roughly 48 days under bug-bounty triage before public disclosure. A report was filed via HackerOne in early March and reportedly marked as a duplicate without escalation. Public disclosure on X on April 20 forced a response. Lovable first denied any breach, called the visibility of public-project chat "intentional behavior," cited unclear documentation, and then partially walked that back, saying it reverted the change that had made public-project chats readable. A separate API-level patch, which per public reporting only covers projects created after November 2025, was applied back in March and is the source of the pre/post-cutoff distinction.

What was exposed

For any pre-cutoff project: the full source tree, any secrets hardcoded in it (Supabase keys are specifically common because Lovable's template apps default to Supabase; Stripe keys, Google API keys, and third-party tokens also widely reported), every prompt and response in the AI chat history tied to that project, and, via leaked Supabase service keys, the live customer data in whatever database the app was backed by.

Am I affected?

Enterprise customers had a private-chat toggle earlier than free-tier users. Per the researcher's disclosure, the BOLA itself is not gated on project visibility, if the /projects/{id} endpoint is reachable with a free-account token, the data is reachable regardless of whether the project is marked private. Treat this as the researcher's characterization until independently confirmed.

If you own a Lovable project

1. Rotate every credential embedded in the project source. Anything hardcoded, anything referenced in environment config that shipped with the repo. Priority order: Supabase service role keys (highest blast radius), Stripe secret keys + webhook signing secrets, Google/OAuth API keys, third-party tokens, any JWT signing secrets. The service role key is the one that pivots into full DB access. Don't rotate only the anon key.
2. Audit the AI chat history for leaked secrets. Developers paste .env files, error logs with DB connection strings, API responses, and deployment outputs into chat mid-session. Every one of those paste-ins in a pre-cutoff project is now treated as public. Search your chat for SUPABASE_, STRIPE_, API_KEY, ANON_KEY, SERVICE_ROLE, postgres://, bearer. Rotate anything you find even if it wasn't "supposed" to be used in prod.
3. Check Supabase (or equivalent) logs for unauthorized reads. If the service key was in your project source and the project is pre-cutoff, treat it as leaked and look for query patterns you didn't issue. Supabase Project → Logs → API Logs and Logs → Postgres Logs.
4. Invalidate any user sessions your app issued. If you signed JWTs with a secret that was in the source, assume an attacker can forge valid tokens. Rotate the signing secret and force re-auth on all end-users.
5. Review customer data exposure. If your app served real users and the database was reachable via leaked Supabase creds, treat user PII as potentially read. That may trigger notification obligations under GDPR, CCPA, or sector-specific rules. Not legal advice, but the assessment needs to happen today, not next week.
6. Migrate sensitive projects off the free tier, or off Lovable entirely. Free-tier users can't make projects private. If a project can't be made private and contains anything sensitive, move it.

If you're an end-user of a Lovable-built app

You may not know. Lovable-hosted apps run on custom domains or subdomains and usually don't disclose the platform. If you used a service that was built with an AI app-builder before late 2025, especially anything that asked for a password, stored payment info, or collected personal data, your credentials and data may have been readable by third parties for months.

1. Treat any password reused on such a service as potentially compromised. Rotate it everywhere it's reused. Yes, that is the real advice.
2. Enable MFA on any account tied to the affected service, and on the email and payment accounts connected to those logins, if you haven't already. MFA helps even if a password has leaked.
3. Where the service offers it, use any "sign out all other sessions" / "revoke active devices" option so any previously-hijacked session token is invalidated. This is separate from rotating the password.
4. Watch payment card and email accounts associated with those services for unfamiliar activity over the next several weeks.
5. If the service later notifies you of a breach, take it seriously, but don't wait for the notification. Many platforms built on Lovable won't notify because they themselves don't know.

The broader lesson

Two failures stack here. The first is the BOLA itself, a well-understood class of bug sitting at #1 on OWASP's API list, in an API serving a platform that markets "production-ready apps" to non-specialists. The second is the bug-triage failure: a critical authz flaw sat 48 days under a "duplicate" label, with no escalation, until the researcher went public. Bounty programs only work if triage actually reads the reports.

The platform-level takeaway: AI code-generation tools inherit the security posture of the platform they run on, not the developer's intent. A user prompting "build me a customer portal" gets whatever defaults the platform ships with, including any hardcoded-credential patterns, any BOLA-prone endpoints, any public-by-default visibility rules. If you can't audit those defaults yourself, assume they're wrong for production until proven otherwise.