2 min read
|
Saved February 14, 2026
|
Copied!
Do you care about this?
The article discusses the frequent issue of unsecured Supabase databases, where developers mistakenly leave user tables public without proper Row-Level Security (RLS). The author highlights how easy it is to access sensitive information using the public anon key and suggests that Supabase could implement better warnings to prevent this oversight.
If you do, here's more
The author recounts an experience where they discovered a friend's SaaS project built on Supabase, a backend-as-a-service platform. Upon inspecting the site, they found an exposed Supabase URL and an anonymous API key, allowing unfettered access to the database. This isn't an isolated incident; the author notes similar vulnerabilities in other projects, including a seed-stage startup. With simple curl commands, they accessed user data, revealing a pattern where developers fail to set proper Row Level Security (RLS) on their databases.
The author raises a critical point about the design of Supabase. While the platform makes it easy to create public tables, it lacks sufficient warnings for developers about the risks associated with exposing sensitive information. The author suggests that a simple alert should trigger when a users table is created without RLS enabled, emphasizing that the anon key can become a security loophole. They compare this to Pocketbase, which implements more robust access controls by default, making it harder for developers to unintentionally compromise their data.
The potential scale of the issue is alarming. With over 100,000 projects created daily on platforms like Lovable, many could be unknowingly exposing their databases. The author questions whether this is merely a skill issue among developers or if the tools they use should offer better safeguards against such common mistakes. The lack of built-in protections in Supabase raises concerns about data security across numerous projects.
Questions about this article
No questions yet.