The four, as the researchers reported them

Moltbook, 31 January. A social network for AI agents, built, by its creator's own account, with AI rather than hand-written code. Wiz Research found the Supabase public key in the site's client-side JavaScript. That on its own is normal. What was missing was row level security, so the key gave anyone full read and write access to the production database: around 1.5 million API authentication tokens, 35,000 email addresses, and private messages between agents, some of which contained other people's API keys in plain text. The team secured the tables within hours of Wiz making contact. Even after the first fix, write access to public tables was still open for a while.

Chat & Ask AI, February. A chat app with more than fifty million installs on iOS and Android. An independent researcher found its Firebase backend with security rules set to public, which meant anyone with the project URL could read, modify or delete the data. Around 300 million messages from more than 25 million users were exposed: entire chat histories. The developer fixed it across all of its apps within hours of disclosure. The same researcher reported that about half of the 200 iOS apps they scanned had the same problem.

Lovable, March to April. A researcher reported a broken object-level authorisation flaw in the platform's API on 3 March and published on 20 April: any free account could, in a handful of API calls, read another user's profile, project source code and database credentials. Projects had hardcoded Supabase credentials in their exposed source. The platform first said there had been no breach and that the exposure was intended behaviour, then partly apologised. In a separate case in February, an entrepreneur found an education app featured on the platform's own showcase page with inverted authentication logic: anonymous users had full access, signed-in users were blocked.

The RedAccess scan, May. A security firm researching unauthorised AI tool use inside companies found about 380,000 publicly accessible applications and assets built with Lovable, Base44, Replit and Netlify, and around 5,000 of them exposing sensitive corporate or personal information: vessel schedules, internal bank finances, unredacted customer service conversations, patient conversations from a care facility. Axios verified several. The platforms disputed the framing, saying public apps are expected behaviour. The cause, as RedAccess put it, was that privacy settings on some tools made apps public by default, and users had to change them manually.

The one control

Strip the names away and the four incidents are the same incident. A backend that trusted the client.

In each case the data store would do whatever the thing in front of it asked, because the layer that was supposed to say no had never been switched on, or had been written backwards, or had a policy that amounted to allow everything. Row level security off. Firebase rules public. Authorisation checked on the wrong side. Project visibility set to public by the platform and never changed by the builder. The key in the browser was never the flaw. The key is designed to be in the browser. It is safe exactly as long as the database enforces its own rules, and not one second longer.

No decision was taken badly. In most of these cases, no decision was taken at all. The builder did not know there was a decision to make, because the tool made the app work without it, and a working app looks finished.

Why vibe-coded apps hit this one in particular

Three reasons, none of them about the quality of the generated code.

First, the defaults. Tables created through SQL or migrations, which is how generated code usually creates them, do not get row level security switched on. A platform that makes every project public unless told otherwise is behaving as designed. The defaults are tuned for the app to work on the first try, and they do.

Second, the feedback. Every screen works. The owner can see their data, the test user can see theirs, the demo runs. The flaw only shows up when someone tries to be a different user, and the builder has no reason to try that, because they were shipping.

Third, the handover that never happens. In a company with an engineering team, a security review sits between "it works" and "customers use it". For a founder who built the product in a weekend, there is no between. The prototype becomes the product by acquiring customers, one at a time, with the settings exactly as they were.

What to check tonight

  1. Be someone else. Open a private browser window, sign in as a second test user, or do not sign in at all, and try to read the first user's data through the API the app already uses. If you can, stop here and fix that first.
  2. Row level security on every table. On Supabase, run the Security Advisor and read what it says. Every table that holds user data has RLS enabled and a policy that names the user. A policy of using (true) is RLS switched off with extra steps. Our row level security mistakes post has the full list.
  3. Rules on every bucket and every Firebase path. Storage is where the file uploads live and it is the part most often left open. Firebase rules are the whole control; "allow read, write: if true" is a public database with a login page in front of it.
  4. No secret key in a public variable. Anything in a VITE_ or NEXT_PUBLIC_ variable is shipped to every browser. A service role key there bypasses every policy you just wrote. If one has ever been there, rotate it.
  5. Project visibility. Open the platform's settings and read what "public" means for your project: the app, the source, the chat history, or all three. Set it on purpose.
  6. Authorisation on the server, not the screen. Hiding a button is not a control. The API has to refuse. Test it with the wrong user, not the right one.

Then the part that does not fit in an evening: someone has to keep checking, because the next table gets created next week, by the same tool, with the same defaults. The production security checklist for AI-built apps is the longer version of this list.

Where we fit

Critical Cloud takes AI-built apps into production and keeps them there. Critical Launch starts with a Launch Check that reviews exactly these controls on the stack you built with, fixes what it finds, and then hands the app into production support: monitoring, incident response, security review after every change, and backups that have been restored. You keep the code, the product and the decisions. We do not rebuild it and we will not ask you to change tools.

We are the wrong choice for a prototype nobody uses yet. Keep building. Talk to us when someone else's data is in it.

Frequently asked questions

Is the Supabase public key being visible in the browser a security flaw?

Not on its own. The public key is designed to be shipped to the browser and is safe when row level security is enabled and the policies are correct, because the database then enforces who can read and write each row. The flaw in the Moltbook case, as Wiz described it, was that row level security was missing, so the public key granted full read and write access to every table. The same shape applies to Firebase: the rules, not the key, are the control.

What should I check first on an AI-built app before customers use it?

From an anonymous browser session, try to read another user's data through the API. Then check that row level security or security rules are enabled on every table and bucket, with no policy that amounts to allow everything. Then check that no secret key is in a public environment variable. Then check the project's visibility setting on the platform you built it with. Those four checks cover the cause of every incident in this article.

Will Critical Cloud review an app built with Lovable, Replit or Claude Code?

Yes. Critical Launch starts with a Launch Check that reviews exactly these controls on the stack you built with, then fixes what it finds, then hands the app into production support with monitoring, incident response and backups. You keep the code, the product and the decisions. We do not rebuild it and we do not ask you to change tools.

Sources