SecurityRLSSupabaseIncident ReportAnalysis

Three Days to Shutdown: what Moltbook teaches about Row-Level Security

Veröffentlicht am 7. April 2026 · 6 min Lesezeit · von Torben Schwellnus

Three Days to Shutdown

What Moltbook teaches about Row-Level Security — and why I've made this exact mistake myself

In February 2026, Moltbook went live — an AI-driven social network where agents interact with each other and exchange messages. Fully vibe-coded, launched with significant marketing push and a small but vocal beta community.

Three days later, it was over.

A security researcher had pulled every record through the app's public API: 1.5 million authentication tokens, 35,000 email addresses, private messages between users. Anyone with the public API key — which is embedded in the frontend on Supabase apps almost by definition, and therefore readable globally — could read, write, and modify the entire database.

The cause wasn't a sophisticated vulnerability, no zero-day, no nested auth bypass. It was a single, very simple configuration setting that was never turned on: Row-Level Security on the Supabase database.

This incident matters because it exposes a pattern that vibe-coding platforms' marketing language carefully avoids: the default configuration of their recommended backends is not secure. It's easy — which is something different. And the transition from "easy enough to start with" to "secure enough for production" is no one's responsibility but yours.

If you're building on Supabase, Firebase, or any similar Backend-as-a-Service, you're structurally exposed to the same trap as Moltbook. Here's why.

How Supabase actually works

Supabase is a wonderful platform. It gives you a PostgreSQL database, a REST API, auth, storage, and more — all configured in minutes. If you're building on Lovable, Replit, or Bolt and you need a database, Supabase is often the first and most obvious choice. The vibe-coding platforms recommend it by default.

The problem: Supabase's default configuration trusts the frontend. Every query against the API authenticates via what's called the "anon key" — a key that's explicitly meant to be embedded in the frontend and therefore readable by anyone in their browser. In its default setting, this key has read and write access to all tables.

For this to work without making your entire database public, you have to explicitly configure Row-Level Security (RLS). RLS policies live directly in PostgreSQL and decide, for each row: is the current user allowed to see, modify, or delete this?

If RLS is disabled and you embed the anon key in the frontend, your database is public on the internet. Not "in the worst case" or "if an attacker finds a bug" — but structurally, by design, documented.

⚠️ Beware the tech: how RLS in Supabase actually works

Default behavior in Supabase: every new table has RLS disabled. With RLS off and an anon key embedded in the frontend, anyone on the internet can:

read every record in that table (SELECT * FROM users)

insert their own records (INSERT INTO users)

modify existing records (UPDATE users SET ...)

delete every record (DELETE FROM users)

Turning it on is trivial: a toggle in the Supabase UI or a single SQL statement. But after enabling it, you also need to write policies — otherwise you lock yourself out. A correct policy for "users can only read their own data" looks like this:
CREATE POLICY "users_own_data"
ON users FOR SELECT
USING (auth.uid() = user_id);
That sounds simple — and it is, if you know SQL and understand PostgreSQL auth concepts. But when you're vibe coding, you're at a completely different point in your workflow: you're building a feature, you want to test it, you want the data to flow. RLS is the friction sitting between "idea" and "it works."

I've done this myself

I know this moment from personal experience. A few months ago I built a prototype on Lovable. I'd hooked up Supabase — the natural path, because Lovable suggests it that way. But every attempt to set up Row-Level Security correctly went sideways. Policies weren't being enforced, the login session was suddenly empty, or a query that worked in the SQL editor returned no rows when called through the API.

After an afternoon of getting nowhere, I disabled RLS entirely. Just briefly, I thought, just to keep moving.

My prototype never went public — that was the deal I had with myself from the start. There was nothing sensitive in it, nothing GDPR-relevant, and no one but me knew the URL. But that was the exact moment I understood why Moltbook and so many other apps end up live with RLS disabled.

The friction is real. The frustration is real. And the step from "let me just turn this off to keep moving" to "I forgot to turn it back on, because nothing tells me it's still off" is very small. When you deploy two weeks later, no platform asks you: "by the way, RLS is disabled on four tables — are you sure you want to go live like this?"

This isn't a developer error. It's a platform error. The system permits a state in which the only remaining layer between your user data and the public internet is a configuration option you toggled off in a frustrated moment and never consciously checked again.

Why the pattern is everywhere

If you Google "Supabase RLS not working," you'll find thousands of Stack Overflow posts, Reddit threads, and Discord discussions. Same pattern every time: someone wants to enable RLS, write a policy, test a query — and it doesn't work as expected. Data doesn't come through. Login breaks. Build fails.

Standard answers in those discussions: "You have to configure this and that for that." "Did you use the service role key instead of the anon key?" "Do you have auth.uid() in your policy?" "Wait an hour for the cache to invalidate and try again." For every step you have to understand before RLS works, there are vibe coders who give up and disable it instead — explicitly, or via workarounds like USING (true) policies that protect exactly nothing.

The platforms make this worse. Lovable and Replit mention RLS in their AI-generated guidance sometimes, but not consistently. They don't test whether it's enabled. They don't warn you when your app goes live with RLS disabled. They don't distinguish between prototype and production.

This leaves the risk entirely with the builder — meaning the person with the least experience in database security, because they specifically chose a platform that promised to spare them that experience. It's a responsibility allocation that doesn't work.

The numbers confirm it. A Q1 2026 study of over 200 vibe-coded applications found that more than 60% of them expose API keys or database credentials in public repositories or frontend bundles. A broad scan of 5,600 publicly accessible vibe-coded apps found 2,000 high-criticality vulnerabilities, 400 exposed secrets, and 175 cases of leaked personal data — including health and payment information.

This isn't an anti-pattern. It's the default behavior.

What would have saved Moltbook

Not an audit after the incident. Not even an audit a week before launch — by then RLS was already absent from the architecture, and no one noticed.

What would have saved Moltbook is a routine: an automated pre-launch check that verifies exactly one thing — "are all tables in the connected Supabase instance configured with active RLS and at least one meaningful policy?" A checklist that runs for every vibe-coded app before go-live. Three minutes of work, a clear red/green report.

That's exactly what we do at Lastable. Our Full Technical Health Check inspects RLS status, storage bucket security, exposed keys in the frontend, and missing auth configuration on standard endpoints.

If you're about to put a Lovable, Replit, or Bolt app into production and you're not 100% certain whether RLS or equivalent mechanisms are active, the Quickscan at lastable.dev takes 30 seconds for a first read. The only price: you might need to spend three hours afterward fixing what it finds.

But that's cheaper than three days.

Start your Quickscan →