qzl/social-app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(security): enforce defensive RLS for agent chat tables

Browse Source 
Close Supabase advisor findings by enabling RLS and deny-by-default policies on new public agent-chat tables. Clarify backend RLS governance and incident runbook steps to prevent config-drift regressions.
This commit is contained in:
qzl
2026-02-25 18:04:05 +08:00
parent a88e42babd
commit 443977be9b
3 changed files with 107 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backend/AGENTS.md
+17 -5
View File
@@ -104,8 +104,20 @@ Use `schemas / repository / service` pattern:
- Migrations must be reversible; no reliance on generated IDs
### RLS Guidance
- Backend does not rely on RLS for correctness (uses service_role)
- **Backend-only tables**: RLS optional (skip to reduce maintenance)
- **Client-direct tables**: must enable RLS with policies covering select/insert/update/delete
- `alembic_version` must not be exposed to anonymous clients (revoke anon access)
- Business tables that may be exposed to clients should enable defensive RLS even if the backend does not depend on it
- Backend does not rely on RLS for correctness (uses service_role), but RLS is mandatory as a defensive boundary for tables in PostgREST-exposed schemas.
- **Mandatory default**: any new business table in `public` must enable RLS in the same Alembic migration.
- The same migration must create policies covering `SELECT/INSERT/UPDATE/DELETE` (minimum requirement).
- Recommended default policy set for `anon, authenticated`: deny all operations first, then open explicit access only when required.
- `alembic_version` must not be exposed to `anon` or `authenticated`.
#### Exemption Rule (strict)
- Exemptions are allowed only when a new `public` table is guaranteed not to be exposed to PostgREST clients.
- Exemptions must be explicit in the migration file with rationale and verification notes (why safe, how exposure is prevented).
- If exposure is uncertain, do not exempt: enable defensive RLS by default.
#### Migration Acceptance Checklist (RLS)
- [ ] New `public` business table has `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` in migration
- [ ] Policies for `SELECT/INSERT/UPDATE/DELETE` are present in migration
- [ ] Policy target roles are explicit (`anon`, `authenticated`, or both)
- [ ] Downgrade path is reversible and does not silently weaken intended production security
- [ ] Any exemption is documented with clear non-exposure evidence