Supabase service role bypasses RLS

Problem

The backend uses SUPABASE_SERVICE_ROLE_KEY, which explicitly bypasses Supabase row-level security.

This can be acceptable if FastAPI is the trusted authorization boundary. At the moment, backend endpoints are not consistently enforcing authentication or ownership, so the service-role client amplifies missing backend auth checks.

Risk

If FastAPI does not enforce auth/ownership correctly, database RLS will not provide a second layer of protection for service-role queries.

Expected behavior

Either FastAPI must be a complete and tested auth boundary for all service-role access, or the backend should avoid service-role access where user-scoped RLS is expected to protect data.

Acceptance criteria

• Document which backend code paths are allowed to use the service-role Supabase client and why.
• Ensure every service-role query path has explicit FastAPI auth and ownership checks before database access.
• Consider separate Supabase clients for privileged admin/server tasks versus user-scoped reads/writes.
• Add regression tests for auth/ownership checks around service-role-backed endpoints.

Start by locating FastAPI endpoints that use SUPABASE_SERVICE_ROLE_KEY and trace each service-role query to its authentication and ownership checks. Document permitted privileged paths, separate admin/server access from user-scoped access where needed, and add regression tests showing that unauthorized or incorrectly owned requests are rejected before database access.