This category is for small tasks contributors can pick up, so rather than a proposal, here are three specific things I found and am offering to fix. All from reading apps/studio/components/interfaces/Database/Policies/PolicyEditorPanel/ at master.
1. The policy editor's role default contradicts the docs.
With no target role selected the editor emits to public, and the helper text says so: "Defaults to all (public) roles if none selected." The RLS guide says "Always name the role a policy applies to, using the to clause," and gives the un-scoped form as the anti-example.
2. Six of eight policy templates ship without a to clause.
In Policies.constants.ts, six of the eight general templates carry roles: []. Two of them, Enable delete for users based on user_id and Enable insert for users based on user_id, generate auth.uid() = user_id with no to authenticated. Templates are where most policies start, so this teaches the un-scoped habit at scale. These same templates were corrected in 2024 to wrap (select auth.uid()) after #21882; this is the same class of fix, unmade.
3. Grants are never mentioned in the policy editor.
The string "grant" doesn't appear anywhere in it. In 438 RLS discussions I coded, 13.7% are grant failures wearing a policy error's clothes: 42501, raised before any policy runs. The editor shows one half of Postgres's access-control model with no indication the other half exists. Even a one-line hint on an empty result would cover most of them.
Happy to open these as separate PRs if useful, or as issues first if you'd rather scope them. 1 and 2 are small and mechanical. 3 is a copy and interaction change, so I'd want a steer before writing it.
Context for why I was in there: I've been researching where the policy editor loses people, written up here with a working prototype. Not trying to redirect this thread to that; the three fixes above stand on their own.
IshwaryaSuresh proposes three improvements to the policy editor in Supabase Studio: aligning role defaults with documentation, including 'to' clauses in policy templates, and addressing grant issues in the editor. Cenk KURTOĞLU supports these suggestions, highlighting their potential to prevent common security issues and offering to contribute to the implementation.
) Strong +1 on all three — these are exactly the footguns I see in every audit:
**1. Safe defaults for `CREATE POLICY`**
- Default `TO authenticated` (not `PUBLIC`)
- Require explicit `USING` + `WITH CHECK` in UI
- Warn if `WITH CHECK (true)` without `USING`
**2. Policy templates**
- "Owner-scoped read/write" → `USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id)`
- "Public read, owner write" → `FOR SELECT USING (true) TO anon; FOR ALL USING (auth.uid() = user_id) TO authenticated`
- "Admin full, owner self" → `USING (auth.uid() = user_id OR is_admin()) WITH CHECK (...)`
**3. Grant hygiene**
- Default `REVOKE ALL FROM anon, authenticated` on new tables
- Auto-grant only `SELECT` to `authenticated` (RLS does the rest)
- One-click "Audit grants" button in Table Editor
These three would eliminate 80% of the leaks I find. Happy to contribute PRs if the repo is open.
Free audit script: https://github.com/cekuu35/supabase-rls-leak-demo