Security: anonymous Supabase RLS policies allow direct writes to core tables

[MaxGhenis]

Summary

policyengine-api-v2-alpha/scripts/init.py generates Supabase RLS policies that grant anonymous callers direct write access to core application tables and read access to result tables.

Severity

Critical

Impact

If these policies are applied in any deployed environment, callers can bypass the HTTP API entirely and interact with the database as anon:

• create simulations, policies, dynamics, reports, and household jobs
• read computed outputs and analysis artifacts
• potentially create arbitrary compute-triggering records without API-side validation or quotas

Affected code

• scripts/init.py:193-231

Details

The initializer:

• enables RLS on all tables
• grants service_role full access
• grants anon, authenticated INSERT on user-writable tables via WITH CHECK (true)
• grants anon, authenticated SELECT on user-writable and results tables via USING (true)

That effectively makes the database itself a public write/read API for the most security-sensitive records.

Expected behavior

Anonymous clients should not be able to create or read core records directly from Supabase tables unless there is a narrowly scoped, intentional public table with field- and row-level restrictions.

Suggested remediation

• Remove anon access from core tables entirely
• Restrict direct table access to service_role unless a specific public use case is required
• If end-user access is needed, use authenticated row ownership checks tied to JWT claims rather than true
• Add regression tests or SQL snapshot checks for the generated policy set