Offering three small RLS fixes in apps/studio (defaults, templates, grants)

[IshwaryaSuresh]

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.

[cekuu35]

)
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