This was supposedly fixed on October 30, but there are reports floating around that for existing projects, the defaults still apply.
Lovable deserves some heat for using this, but this was a choice that was made by Supabase many years ago to support making it easier to onboard potential customers, a deliberate tradeoff of less onboarding pain for less security.
For example, if you try to access a table named "secret" that doesn’t exist, Supabase might return a hint saying, "Perhaps you meant the table 'public.super_secret'."
Thanks for volunteering that information, I guess.
[−]doctorpangloss · 2026-11-14 Sat 21:56 UTC ·
link
The hint is not a problem if you use the PostgreSQL default of deny for every table, Supabase is migrating to this default https://github.com/orgs/supabase/discussions/45329. If the defaults are in place even if you see the table name on the hint it will be inaccessible (fails immediately before RLS checks).
Note that the hint is added by PostgREST and it was introduced at a time where users manually typed table names, causing them to report malfunctions on typos. These hints are not as necessary anymore so they're usually disabled via config[1] and will likely be dropped on a next version.
If your goal is to onboard nontechnical users quickly and not have to deal with them churning because they have to deal with thinking about those pesky "security rules" before they can get a working app, it totally makes sense that you would do this, especially if you just drop a get out of jail free "well, it's the end user's fault for not configuring their app securely" in your T&C.
Somehow it's okay to simultaneously set a golden path to less secure software to support your hockey stick growth model and then turn around and blame end users when it all goes wrong.
[−]reassess_blind · 2026-11-14 Sat 23:03 UTC ·
link
The idea was that RLS (Row-level security) would be enabled on any tables exposed to the data API, and RLS was “heavily encouraged” to be turned on by default in the dashboard, and RLS was on by default since at least 2025. Tables require explicit RLS policies to be accessible by the data API, so by default it’s not open like that anymore.
In practice it’s an absolutely stupid design. If you create tables without using their dashboard, like with an ORM or with SQL directly, it’s incredibly easy to have them not use RLS and be wide open to the public.
Taking a step back, the whole “query the database straight from the frontend” is a terrible design in general. For example, they still don’t offer rate limiting! Even if the tables data is secured, there’s nothing stopping someone from hammering the database directly with reads/writes until it overloads it, as there’s no application level rate limiting in the middle. Bonkers.
I think the idea is to use edge functions against the database with RLS helping with low level access control, but it's still a tough design pattern to hold people accountable to. May as well as write the whole thing in a backend and just skip Supabase's API/RLS entirely.
[−]reassess_blind · 2026-11-15 Sun 06:17 UTC ·
link
The whole proposed benefit of their "query the database from the client" concept was the speed and ease of development. If you need edge functions (cost per invocation too, mind you) to make this happen, it's just a terrible design in general.
I agree. If AI agents are doing all the code anyway, as is the case with Lovable, just turn off the Data API entirely and access the DB from the backend only like a typical Postgres setup.
Have you looked at PocketBase? If I understand correctly it solves both of these to some degree and from my perspective pretty cleanly. Building a self-hosted, OS version of Firebase and SupaBase was the inspiration I believe.
[−]weird-eye-issue · 2026-11-15 Sun 04:10 UTC ·
link
There is nothing wrong with this. It's no different from unauthenticated API routes to get public information. The issue is when somebody doesn't use RLS correctly.
You have called out the issue precisely! The problem is that Supabase, and Lovable, market this product to people who are basically guaranteed to not know how to use RLS correctly. And that the defaults set are insecure - precisely because they know that if they set the security settings to be secure by default, that their end users would churn because... they don't know how to configure RLS. Then they turn around and say "Well, it's YOUR fault if you didn't know how to configure it properly, even though we marketed this to you as being approachable as a layman"
If I had a multi tool that I sold to the masses that required solving a simple math proof to operate or else there was a chance the product would explode in my hand, would it be my fault or the customers fault if it started exploding in the customer's hands, because I marketed it to everyone instead of just mathemeticians, and included no warning label? I can't require that people solve the math proof first and show they can solve math proofs in order to use the product because then they'll just return the product, because the vast majority of people I'm marketing to... can't solve math proofs.
I do, however, have an easy solution here! I can bury "user operates the multi tool at their own risk" in the T&C and now all sorts of hand explosions can happen and it's not my fault!
Any tables created before the defaults put in place are of course still subject to the wide open previous default configuration, because they would risk break existing users apps if they back-ported those.
The amount of misconfigured supabase out there is astounding. And I'm not just talking about your mom's friend who wants a mahjong social network site. Companies backed by sand hill road VCs to the tunes of 10s of millions of dollars expose keys, don't have rls, set anon envs that are really full admin keys, don't rotate keys, etc.. the list goes on. It's wild.
It's a shame that making things easy to use has typically meant the user gives up control/hosting capabilities and generally gets less security out of the box. You're probably right about Supabase, that they made that tradeoff explicitly, but they have more demand than they keep up with now and finally seem to be course correcting toward more secure defaults. They apparently believe this will make onboarding their users more difficult (this is a false dilemma IMO).
People who don't get Postgres and RLS implement it sloppily and you inevitably get cases like this. You can put that on the user but I think platforms have a higher bar here to create experiences or interfaces where the easy path is the most secure one. There are obviously other parts of the process that can be leaky beyond beyond just the database config so the app architecture needs to make the system cohere together securely and I just don't feel like the existing platforms are fully up to the task.
The vibecoding tools like Lovable, bolt, v0, replit, base44 don't really attempt to be overtly transparent because that's not the point. They all sell the idea of a concierge service but that only works if the experience is actually "luxury" which in this case means you can trust in a guaranteed basic level of data privacy.
This was supposedly fixed on October 30, but there are reports floating around that for existing projects, the defaults still apply.
Lovable deserves some heat for using this, but this was a choice that was made by Supabase many years ago to support making it easier to onboard potential customers, a deliberate tradeoff of less onboarding pain for less security.
https://docs.postgrest.org/en/latest/references/errors.html
For example, if you try to access a table named "secret" that doesn’t exist, Supabase might return a hint saying, "Perhaps you meant the table 'public.super_secret'."
Thanks for volunteering that information, I guess.
Note that the hint is added by PostgREST and it was introduced at a time where users manually typed table names, causing them to report malfunctions on typos. These hints are not as necessary anymore so they're usually disabled via config[1] and will likely be dropped on a next version.
[1]: https://docs.postgrest.org/en/v16/references/configuration.h...
I can't believe someone actually made this by design
Somehow it's okay to simultaneously set a golden path to less secure software to support your hockey stick growth model and then turn around and blame end users when it all goes wrong.
In practice it’s an absolutely stupid design. If you create tables without using their dashboard, like with an ORM or with SQL directly, it’s incredibly easy to have them not use RLS and be wide open to the public.
Taking a step back, the whole “query the database straight from the frontend” is a terrible design in general. For example, they still don’t offer rate limiting! Even if the tables data is secured, there’s nothing stopping someone from hammering the database directly with reads/writes until it overloads it, as there’s no application level rate limiting in the middle. Bonkers.
I agree. If AI agents are doing all the code anyway, as is the case with Lovable, just turn off the Data API entirely and access the DB from the backend only like a typical Postgres setup.
https://pocketbase.io/
True, but I've seen staff+ level developers get bit by this. What hope do vibe coders have?
If I had a multi tool that I sold to the masses that required solving a simple math proof to operate or else there was a chance the product would explode in my hand, would it be my fault or the customers fault if it started exploding in the customer's hands, because I marketed it to everyone instead of just mathemeticians, and included no warning label? I can't require that people solve the math proof first and show they can solve math proofs in order to use the product because then they'll just return the product, because the vast majority of people I'm marketing to... can't solve math proofs.
I do, however, have an easy solution here! I can bury "user operates the multi tool at their own risk" in the T&C and now all sorts of hand explosions can happen and it's not my fault!
Any tables created before the defaults put in place are of course still subject to the wide open previous default configuration, because they would risk break existing users apps if they back-ported those.
People who don't get Postgres and RLS implement it sloppily and you inevitably get cases like this. You can put that on the user but I think platforms have a higher bar here to create experiences or interfaces where the easy path is the most secure one. There are obviously other parts of the process that can be leaky beyond beyond just the database config so the app architecture needs to make the system cohere together securely and I just don't feel like the existing platforms are fully up to the task.
The vibecoding tools like Lovable, bolt, v0, replit, base44 don't really attempt to be overtly transparent because that's not the point. They all sell the idea of a concierge service but that only works if the experience is actually "luxury" which in this case means you can trust in a guaranteed basic level of data privacy.