Last reviewed October 11, 2026. Disclosure: SuperApps Vibe Coding Fixes is our service. Where a number comes from a vendor’s own study or case write-up, we say so.
In April 2026, Lovable, an AI app builder, had a data exposure that the company first denied and then reversed the same day. Halborn’s analysis describes chat histories of public projects being readable by anyone with a free account. The researcher’s account, as reported by Techzine and Startup Fortune, also includes source code and database credentials. The underlying mistake is an old one: the server didn’t check whether the person asking for a record was allowed to see it. It’s easy to miss in a fast-built app, because the demo works without the check. This article lays out what’s documented, what isn’t, and what to check this week.
What happened, in order
- December 2025: Lovable says it made projects private by default on all plans and retroactively patched its API so chats on public projects could no longer be read by others.
- February 2026: While reworking permissions in its backend, Lovable says it accidentally re-enabled access to chats on public projects.
- March 3, 2026 (per the researcher): The problem is reported through Lovable’s HackerOne bug bounty program. Lovable later said HackerOne closed the reports without escalating them, judging chat visibility to be intended behavior.
- April 20, 2026: The researcher goes public. Lovable first says it “did not suffer a data breach” and calls public-project code visibility “intentional behavior,” according to The Register. Later that day it apologizes, admits the February change, and reverts it.
- April 21, 2026: A Lovable spokesperson says the company was unaware of the issue until April 20, and that chats from public projects are no longer visible to anyone.
Several outlets count 48 days from the March 3 report to the April 20 disclosure.
Where the reporting disagrees
The coverage doesn’t agree on scope, so treat the question as unresolved. Halborn describes chat histories of free-tier public projects, with enterprise projects possibly affected too. Bastion and Startup Fortune say projects created before November 2025 were affected, while Halborn says free-tier projects created after December 2025 were not. According to the researcher’s follow-up report, as relayed by Halborn and vibegraveyard, Lovable’s fix covered only new projects. We couldn’t find a Lovable statement that settles which older projects remain exposed.
If you built on Lovable and a project was ever public, rotate its database passwords and connection strings. Startup Fortune’s coverage gives the same advice.
The pattern: a check that exists on the screen, not the server
Startup Fortune describes the root cause as “missing ownership checks on API endpoints,” including endpoints keyed by project ID. Halborn attributes it to an accidental regression in backend permissions and calls it broken object level authorization (BOLA), the OWASP name for APIs that don’t check whether the caller owns the object being requested. Whatever the builder, the failure looks the same: the screen hides the record, but the server hands it over when someone asks for it directly.
Row Level Security: on isn’t the same as safe
Row Level Security (RLS) is the Postgres feature that decides which rows a logged-in user can read or change. On Supabase, it’s the database-side version of the ownership check above. It keeps one user’s data away from another’s when the app talks to the database directly. Supabase’s own guidance is to enable RLS on every table in an exposed schema, so don’t assume it’s on. Check each table. Turning RLS on isn’t enough either: a policy that lets any logged-in user read every row leaves the data open to every account. Lovable’s own scanner, shipped in April 2025, checks whether RLS is enabled, not whether the policies are correct, per Bastion.
Supabase’s changelog also changes a related default. Starting May 30, 2026, new projects default to not automatically exposing new public-schema tables through the Data API, and the change reaches existing projects on October 30, 2026. Existing tables aren’t affected. Policies still matter for any table that holds user data.
The Supabase scan: what the numbers show
Symbiotic Security, a security firm, scanned 1,072 sites that load Supabase, most of them found through search rather than a random sample. It flagged 1,046 of them (98%) with at least one security flaw. The 98% figure is the study’s extension to vibe-coded apps in general, which a sample like this can’t fully support. It also flagged 172 sites (16%) as letting anonymous users delete records. The write-up says the scanner tests with the anon key, but it doesn’t say whether it actually ran any deletes. Read the 16% as “anonymous delete access detected,” not “records wiped.”
Webhooks that return 200 and do nothing
Stripe treats a 200 response as successful delivery, and its docs recommend verifying each event’s signature and logging event IDs so duplicates aren’t processed twice. Delivery isn’t the same as doing the job. An Indie Hackers post by a Stripe audit service describes a handler for invoice.payment_failed that returned success and did nothing, so access stayed on. The author says one founder was leaking $2,300 a month for 11 months. That comes to about $25,300, a total we calculated, since the post doesn’t state one.
The Firebase and FlutterFlow test-mode trap
Firebase’s test mode opens Firestore for a fixed window. Firebase’s warning, quoted in a FlutterFlow community thread, says the rules “were configured to stop allowing requests after the first 30 days.” Until they expire, anyone who can reach the database can read or write it. FlutterFlow’s docs tell developers to remove default Firestore rules before publishing, and they show date-limited examples. We found nothing saying FlutterFlow generates expiring open rules on its own, so the warning applies to default rules and test mode either way. Before launch, review the rules on every collection, not just the ones your demo uses.
Is the AI to blame?
It’s tempting to say AI code generators default to “open” because open code runs without errors. That’s a plausible hypothesis, but the Lovable reporting doesn’t establish it. Lovable’s own account describes an accidental regression during a backend permissions change in February 2026. The lesson holds either way: a check that exists in the UI or the demo flow but not on the server stays hidden until someone asks the server directly.
A documented case: subscriptions broken for a month
GetDevDone, a development firm, published a case in which an AI-generated change to subscription buttons broke the link between Stripe and Memberstack for about a month. New subscriptions failed silently, and existing subscribers lost paid access. The firm removed the AI-generated payment logic, restored the original integration, reconciled billing records across both systems, and added payment event logging to replace what it calls a silent failure mode. It reports a cost of $2,000–$6,000 over one to four weeks. It’s the firm’s own write-up, so treat its numbers as its claims.
Imagine a SaaS whose login is checked only in the browser, and whose Stripe “integration” is a button with no backend behind it. The demo still works, nothing throws an error, and nobody tests a logged-out request. A check that lives only in the browser isn’t a security control, because anyone can skip the browser.
What to check this week
- Test your own app as a logged-out visitor, then as a second account. Can either one read or change the first account’s rows? It’s the fastest test for BOLA. Only run it against apps you own.
- Confirm RLS is enabled on every table that holds user data, and that each policy checks ownership on the server, such as requiring the row’s user ID to match the logged-in user.
- Confirm the Supabase service role key never appears in browser code. It bypasses RLS.
- Confirm payment webhooks verify Stripe’s signature, check payment status before granting access, ignore duplicate events, and log failures. Then send test events with the Stripe CLI and confirm access changes the way you expect.
- Review the rules on every Firestore collection before launch, including any test-mode defaults.
- If a project was ever public, rotate its database passwords and connection strings.
If you’d rather have someone check your app’s login, RLS, and webhook setup, SuperApps Vibe Coding Fixes does that kind of review.
Sources
- The Register: Lovable denies data leak (April 20, 2026)
- Techzine: Lovable under fire over data breach (April 21, 2026)
- Startup Fortune: Lovable’s API flaw (April 21, 2026)
- Halborn: Lovable Data Leak: BOLA Vulnerability and App Security Risks
- Bastion: Lovable April 2026 Data Breach
- vibegraveyard: Lovable BOLA API, 48 days exposed
- Symbiotic Security: We scanned 1,072 vibe-coded apps
- Indie Hackers: a founder leaking $2,300 a month
- GetDevDone: The vibe coding tax
- FlutterFlow docs: Cloud Firestore rules
- FlutterFlow community: Firebase test-mode warning
- Stripe docs: Receive events in your webhook endpoint
- Supabase docs: Row Level Security
- Supabase changelog: Tables no longer exposed to the Data and GraphQL APIs automatically
- OWASP: API1:2023 Broken Object Level Authorization
Get new posts by email
Pick the topics you care about — we only email you when something new is published in them.