Exposed Moltbook Database Let Anyone Take Control of Any AI Agent on the Site(404media.co)
404media.co
Exposed Moltbook Database Let Anyone Take Control of Any AI Agent on the Site
https://www.404media.co/exposed-moltbook-database-let-anyone-take-control-of-any-ai-agent-on-the-site/
8 comments
You hit the nail on the head.
> But those things are exactly things that LLMs already solve, especially for vibecoders who don't even know what the code is doing. For them it'd be so much better if the LLM just went with the standard SQL setup rather than Supabase/RLS.
This is precisely the approach we are taking for Specific (https://specific.dev). We believe you can move just as fast as you can with Supabase (whether you're a developer or not) if you just let coding agents code. What they are missing is the infrastructure parts, which we provide, like a private Postgres database that a backend can be built around (and which can't just be publicly exposed).
> But those things are exactly things that LLMs already solve, especially for vibecoders who don't even know what the code is doing. For them it'd be so much better if the LLM just went with the standard SQL setup rather than Supabase/RLS.
This is precisely the approach we are taking for Specific (https://specific.dev). We believe you can move just as fast as you can with Supabase (whether you're a developer or not) if you just let coding agents code. What they are missing is the infrastructure parts, which we provide, like a private Postgres database that a backend can be built around (and which can't just be publicly exposed).
[deleted]
RLS on Postgres is fine — I use it in production for tenant isolation and it works great. The problem is that Supabase puts it as the only thing standing between the public internet and your data. PostgREST translates HTTP straight into SQL, so if you get a policy wrong (or forget one), game over. Behind a normal backend, a bad RLS policy is a defense-in-depth failure. In Supabase's model, it's a breach. That's a huge difference, and it gets worse when LLMs are writing the code because they'll happily scaffold a full app without ever thinking about access control.
> PostgREST translates HTTP straight into SQL, so if you get a policy wrong (or forget one), game over
Do note that by default in PostgreSQL/PostgREST, RLS is the third layer of AuthZ defense, you have table and column level security before and these are closed by default.
> In Supabase's model, it's a breach.
Supabase is currently working on being closed by default.
Do note that by default in PostgreSQL/PostgREST, RLS is the third layer of AuthZ defense, you have table and column level security before and these are closed by default.
> In Supabase's model, it's a breach.
Supabase is currently working on being closed by default.
You're right, the GRANT layer is closed by default in PostgreSQL and PostgREST respects that. But in practice with Supabase, the very first thing you do is `GRANT ALL ON table TO authenticated` (and often `anon`) because nothing works through the client SDK without it. Every tutorial does this, every LLM-generated scaffold does this. At that point the first two layers are effectively gone and RLS is what's left. That's what I meant — not that PostgreSQL lacks defense in depth, but that Supabase's typical workflow collapses it down to one layer pretty quickly.
Good to hear they're working on closed-by-default though. Kind of proves the point that the current model has been a problem in practice.
I find it kinda amusing that the only two times I've heard Supabase mentioned on here was the time that someone let Cursor delete their prod DB and this.
I understand it's some kind of RAD framework for JavaScript people?
I feel I might be showing my age here, but I don't understand how securing your production database is a challenge all of a sudden. (My hot take of the day)
I understand it's some kind of RAD framework for JavaScript people?
I feel I might be showing my age here, but I don't understand how securing your production database is a challenge all of a sudden. (My hot take of the day)
- RLS asks for way more discipline to use securely than the bog-standard "client+API+SQL db"
- Supabase has spent all of its marketing budget on beginners (pre-LLMs) and completely non-technical users (post-LLMs)
This combination is always going to lead to complete trainwrecks. It's like marketing angle grinders to people who have never learnt to use a saw.
The chance of Supabase ever changing from RLS-first to RLS-last is near zero as well as it's too core to their brand. As long as it's RLS-first it doesn't matter how many "barriers" and "checks" they put up either. They will never put up enough to slow adoption, which is what would be needed.
It would be much better for everyone if the standard vibe coding stack was based on, for example, Cloudflare. Pages/Workers/D1 or something. Not that I'm a fan of CF (and there may be better alternatives) but at least it would cut these cases of "entire DB exposed" at least in half.
Another bit of irony is that the whole selling point of Supabase has been "time from zero to one", "less code/boilerplate required", "I'm a frontend developer and don't want to learn backend". But those things are exactly things that LLMs already solve, especially for vibecoders who don't even know what the code is doing. For them it'd be so much better if the LLM just went with the standard SQL setup rather than Supabase/RLS.