RLS policies use unconditional using (true), may not actually restrict anon/authenticated access #41

What I noticed

Every RLS policy in backend/migrations/schema.sql (and duplicated in 004_code_review_engineer.sql) is written as:

create policy "Service role full access on <table>" on <table> for all using (true);

Despite the name, using (true) isn't scoped to the service role at all - it's unconditionally true for any role RLS evaluates. The comment above these policies says:

The backend uses the service-role key, which bypasses RLS. These policies keep anon/authenticated access closed by default.

But the service-role key already bypasses RLS regardless of any policy, so it never needed one. If anon/authenticated have any base table access in this Supabase project (their default grants, if not explicitly revoked), this using (true) policy would hand them full read/write access to every table here - the opposite of the comment's stated intent.

What needs to happen

1. Check the actual Supabase table grants for anon/authenticated on these tables - if they have none, this may be moot in practice.
2. If they do have base access, either tighten these policies (e.g. using (auth.role() = 'service_role')) or explicitly revoke anon/authenticated grants on these tables.

Not confirmed as an active vulnerability yet - just an inconsistency between the comment's stated intent and what the SQL actually enforces, worth verifying and fixing if real.