ppdr_staging RLS enabled (2026-07-22)
Supabase security advisor email (2026-07-20) flagged public.ppdr_staging as
the only table with RLS disabled — migration 024 (Desk Review Prep worklist,
2026-07-19) created it without the ENABLE ROW LEVEL SECURITY step every
other table has.
Fix: RLS enabled 2026-07-22 via Supabase MCP apply_migration
(enable_rls_ppdr_staging); repo parity file committed as
migrations/applied_out_of_band/2026-07-22_enable_rls_ppdr_staging.sql
(entirely-api 9d5f9fa, pushed). No policies created — matches the project-wide
pattern; all runtime access uses the service-role client
(services/supabase_service.get_client), which bypasses RLS.
Verified: anon-key PostgREST read returns []; service-role read returns
rows; advisor re-scan shows no ERROR-level findings.
Exposure window: ~3 days (7/19–7/22). Practical risk low — the anon key is not embedded in portal-v2 or any shipped client (portal talks to unlikely-api, never Supabase directly), so exploiting it required the key itself.
Lesson for future migrations: every CREATE TABLE in public must include
ALTER TABLE ... ENABLE ROW LEVEL SECURITY; — migration 024 is the one that
missed it.
Follow-up same day: WARN-level advisor cleanup
Pinned search_path = public, pg_temp on all 14 app-owned functions flagged
by lint 0011 (analytics_*, ss_date, extract_ss_date, search_similar,
friday_execute_sql, get_site_visits_in_range, both updated_at triggers) via
MCP migration pin_function_search_paths; repo record
2026-07-22_pin_function_search_paths.sql (entirely-api eb18db3, pushed).
Smoke-tested post-apply: date parsers, analytics SRFs, search_similar (pgvector
ops), and friday_execute_sql (kept 015 grants + timeout/work_mem) all working.
Advisor now shows zero ERROR and zero function WARNs. Accepted, not fixed:
vector and pg_trgm living in the public schema — relocating them would
break unqualified type/operator references for negligible gain.