Lovable's security scanner clears an RLS policy that returns every customer's orders

Read the membership policy out loud and it asks a question about the user, never about the row. The condition is `exists (select 1 from public.memberships m where m.user_id = auth.uid())`, and nothing in it refers to a column of `orders` ^[17]. Postgres runs that test for every candidate row, gets the same answer every time, and returns the row ^[17]. One membership in one organisation is enough. The route the post describes is sign up, create your own free workspace, and read every order of every customer ^[18].

"This is the one the scanners cannot see, because structurally these are real policies," the author of the dev.to post wrote ^[14]. That is fair about what an enabled-flag check can observe: RLS is on, a policy exists, it restricts to `authenticated`, and it queries a membership table ^[17]. The author is also explicit that the generators are not the target. "None of this is a criticism of the tools. They generate working code quickly," the post says ^[20].

The blunt version of the same bug is `using (true)`, which the post says turns up when someone hits a permission error during development and asks an AI to fix it ^[15]. It does fix the error. Every logged-in user then reads every order in the system ^[15].

The failure the author ranks worst is role data in `user_metadata`. That object is writable by the user, so any logged-in account can open a browser console and run `await supabase.auth.updateUser({ data: { role: 'admin' } })` ^[8]. "If your policies trust that field, you do not have access control, you have a suggestion," the author wrote ^[9]. The suggested fix is a membership table keyed by `auth.uid()`, readable by its owner and writable by nobody from the client; `app_metadata` is the other option because it is not user-writable, and the author prefers the table as easier to reason about and to audit later ^[11].

The checks are two queries. One selects `tablename, policyname, qual, with_check` from `pg_policies` where the policy body matches `%user_meta%` or `%raw_user_meta%`, and the post treats any row returned as a critical finding ^[10]. The other reads `relrowsecurity` from `pg_class` for ordinary tables in the `public` schema, where false means the table is served to the anon key ^[13][12].

CVE-2025-48757 counted 303 vulnerable endpoints across more than 170 applications ^[2], about 1.8 endpoints per application ^[19]. That is one scan of one generator's output at one moment. The post does not disclose how many tables those applications had. For the ratio to transfer you would need the same generator, the same era of defaults, and the same habit of leaving tables in the `public` schema.

One item on the list sits oddly with the rest of it. The author writes that every pattern shown leaves RLS enabled and shows green ^[5], while the second pattern is RLS being off on some tables, which the Supabase dashboard does warn about; the author's point there is that the warning is easy to dismiss when you are shipping ^[13].