Lovable-built apps and Moltbook leaked through database rules that were missing or wrong

On these apps the access control lives in the database. The browser talks to the hosted database directly, so the page has to carry a key ^[5]. In Supabase that publishable, or anon, key is meant to be public ^[5]. The lock is a Row Level Security policy on the database that says which rows a given user may read ^[6]. If the policy is missing or wrong, the public key opens the whole table to anyone without a login, and nothing on screen looks different ^[7].

Wiz's Moltbook write-up, by Gal Nagli, is careful on exactly this point ^[19]. It says exposing a publishable key "does not automatically indicate a security failure" ^[17]. The researchers found the key in the site's client-side JavaScript within minutes ^[16], while "simply browsing like normal users," they wrote ^[15]. A publishable key belongs there ^[5]. The site's founder had said publicly that he vibe-coded it ^[14].

Veracode's pass rate needs the same care before it transfers to anyone else's app. Its tests used no security-specific prompting and ran on raw models, not on agents, guardrailed tools or code a human had reviewed, and Veracode says so ^[3]. Under those conditions 44% of tasks failed on average ^[1]. The best model on its summer leaderboard still failed nearly one in three ^[2]. The dev.to post that collected these cases reads the figure narrowly: code nobody asked about security, and nobody reviewed, passes security checks about half the time ^[4]. For that to describe a given internal tool, the tool has to have been built the same way. Lovable is itself an AI app builder ^[8], and output from a builder like it falls outside the raw-model population Veracode tested ^[3].

For builder-made apps the closest measured rate is Palmer's, with two caveats. He works in developer relations at Replit, which builds a competing AI app builder ^[8]. His script never logged in and never went past the homepage, and the post's authors call the count a floor ^[11]. The method is published and simple. The script loaded each showcase homepage, captured the page's own database request, and re-sent it asking for everything ^[9]. Palmer also wrote, as of May 2025, that Lovable's later security scan checked that a Row Level Security policy existed, not whether it was correct ^[13].

In my view the pre-launch review for an AI-built internal app follows from the two cases, in this order:

1. A logged-out load of the app, capturing every request the page sends to the database. 2. A replay of each request asking for all rows, as in Palmer's scan ^[9]. 3. A logged-in request for rows that belong to a different user. This tests whether the policy is correct as well as present ^[6].

A table that answers the second step is open to anyone who can load the page ^[7].