Skip to content

Supabase RLS

Supabase tables and storage buckets must be explicitly exposed.

  • Grant schema and table privileges intentionally.
  • Revoke public default table and sequence privileges from Data API roles.
  • Revoke Sanmopia table access from anon unless a contract explicitly names public read access.
  • Enable RLS before user-facing access.
  • For UPDATE access, provide both SELECT visibility and UPDATE USING / WITH CHECK policies.
  • Add RLS policies as database safety rails, not as Sanmopia RBAC authority.
  • Do not use Supabase app_metadata, profile member_role columns, or RLS policy predicates as application RBAC/ReBAC authority.
  • Supabase session/app metadata may carry non-authoritative identity hints only; backend APIs must re-check business actions through SpiceDB and, where needed, OPA.
  • Supabase stores identity, business rows, audit rows, storage grants, and relationship facts for sync/replay.
  • SpiceDB owns RBAC/ReBAC permission evaluation for application actions such as reservation view, charge finalization, care delivery recording, caregiver payout, branch settlement, HQ review, and finance close.
  • Branch membership rows must sync into SpiceDB relationships through the sanmopia_spicedb_relationships queue payload before operator APIs trust them.
  • Keep private storage bucket access under SQL-managed policies with SELECT, INSERT, and UPDATE for upsert.
  • Keep Supabase client access in adapters.