anon-harden: least-privilege anon/authenticated grants + scoped storefront policies

[snackman]

Finding (verified against the live DB via PostgREST with the anon/public key)

1. Over-broad anon GRANTs — the anon role held effectively ALL privileges (SELECT/INSERT/UPDATE/DELETE/TRUNCATE/TRIGGER/REFERENCES) on essentially every public table (orders, payments, customers, memberships, audit_log, staff, subscriptions, …). RLS still gated rows, but a blanket grant to the public role is a serious footgun.
2. Registry enumeration — tenants_public_select (anon, qual=true) and locations_public_select (anon, qual=true) let the public read the ENTIRE tenant + location registry of ALL tenants. The storefront only needs to resolve ONE location/menu by slug.
3. authenticated over-broad — also held TRUNCATE/TRIGGER/REFERENCES; trimmed to least-privilege DML.

Fix — supabase/migrations/20260605000200_least_privilege_grants.sql

• REVOKE ALL ON ALL TABLES/SEQUENCES/FUNCTIONS IN SCHEMA public FROM anon, then GRANT USAGE ON SCHEMA + GRANT SELECT to anon on the storefront-public surface only: menu_categories, menu_items, item_sizes, modifier_groups, modifiers, item_modifier_groups, location_menu_overrides, store_settings, locations. anon loses all access to tenants, orders, payments, customers, memberships, staff, subscriptions, audit_log, etc. (denied at the grant layer, independent of RLS).
• REVOKE ALL ... FROM authenticated, then GRANT SELECT, INSERT, UPDATE, DELETE (no TRUNCATE/TRIGGER/REFERENCES) on the tenancy + domain operational tables. Rows stay RLS-gated.
• DROP POLICY tenants_public_select — no more anon tenant-registry read. The member/admin tenants_select from the tenancy core is untouched.
• Replace locations_public_select with for select to anon using (public.is_active_tenant(locations.tenant_id)) — a new SECURITY DEFINER helper, so anon resolves a location by slug only for an active tenant and never reads tenants directly (anon has no grant there).
• Menu / store_settings using(true) SELECT policies are intentionally kept.

Decision on anon menu read: KEPT (narrow), app path is server-side

The app's real data path is server-side via the service_role key (readSupabaseConfig() prefers it; src/lib/db/supabase.ts filters every query by tenant_id/location_id). The /shop RSC + /api/shop/* routes resolve the location/menu/settings server-side through getPosDriver() and never use the anon role. So tightening anon cannot break the app. We keep a narrow anon SELECT on the storefront-public surface so the menu could be read client-side with the anon key later without re-granting — but it is not on the current app path. The service-role path is confirmed unaffected.

Tests — supabase/tests/rls_isolation.sql (extended)

As anon: CAN read both menus / categories / store settings / a location-by-slug; CANNOT read tenants, orders, payments, customers, staff, memberships (permission-denied or 0 rows). Kept anon-cannot-write-menu and all authenticated cross-tenant assertions. Added customers/staff/store_settings fixtures. Runs in the optional non-blocking Postgres rls-isolation CI job (the auth_shim creates the anon/authenticated/service_role roles).

Verification

• Local, zero env vars: typecheck, lint, build, test:run (106 tests) — all green.
• No app/UI/behavior changes; package.json/lockfile untouched.

Files changed

• supabase/migrations/20260605000200_least_privilege_grants.sql (new)
• supabase/tests/rls_isolation.sql
• supabase/README.md, docs/PRODUCTION_READINESS.md
• plans/anon-harden-least-privilege.md (new)

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
pos	Ready	Preview, Comment	Jun 5, 2026 5:42pm