Honestly the problem is more that Supabase, in the interest of making it easier to onboard to their product, leaves several important Postgres security features in a suboptimal configuration by default in their product. In particular the settings around how auth and RLS are configured are not optimized for security, but rather to remove roadblocks that devs might encounter the first time they set up the project.
One particular example of this is that anonymous access, as hinted in the article, is turned on by default and it’s not straightforward to just disable it, it requires some in depth knowledge around how the Postgres security model works to do it correctly.
That isn't true representative of Supabase. Tables respect RLS by default, unless turned off. This is how Supabase works. Views are not, and that is due to multiple reasons which Supabase documents. Supabase also warns the user of this and asks them to configure RLS properly for views by first changing the invoker. They also report the same issue to the user on their Security Advisor. The fix is as easy as running the SQL statement in the SQL Editor. Supabase also offers "Autofix" next to the warning, which tells the user exactly how to modify the CREATE VIEW statement to enable RLS.
It is a problem with Supabase as it's a problem inherent to RLS, and Supabase pushes very hard for RLS to increase adoption by non-technical users like the person who this article is about. You're right that they give lots of warnings to mitigate the issue but the people who they're targeting with RLS are exactly those who ignore them - see this post. This is nothing new and not a consequence of vibe coding. It's the contradiction between RLS being a technology that requires much more discipline to use securely compared to its alternative (a layer inbetween client and DB), yet is marketed and most used by beginners who lack the ability to maintain this.
> pushes very hard for RLS to increase adoption by non-technical users
We are tailoring what we're doing for this audience. The challenge is that they appeared out of nowhere about 6 months ago and the LLMs that are used by this audience is trained on 5 years of content tailored for developers
this is not an excuse, I'm just adding color. We've made a lot of changes with tools, alerts, email warnings etc. We are in planning-mode for changing defaults and working with the AI Builder platforms. We will likely change the schema configuration and advocate for Edge Functions (serverside Typescript) where appropriate.
One particular example of this is that anonymous access, as hinted in the article, is turned on by default and it’s not straightforward to just disable it, it requires some in depth knowledge around how the Postgres security model works to do it correctly.