consent_logs tablosu anon-key ile publicly readable buldum — Supabase RLS eksiği (PR #616 EEE F3)

Ankara Cukurambar da 37 yaslarinda bagimsiz GDPR + privacy consultant Selma (@selma_privsec), 9 yillik consultancy Türkiye + AB SaaS vendor Schrems II + GDPR Article 32 + KVKK audit. Pazar gecesi thMenu open-source repo migration history review. supabase/migrations/20260520000002_consent_logs.sql cookie consent banner event track tablosu. Schema: id, user_id, scope (marketing/analytics/functional), accepted, app, device_hash, ip_hash, accepted_at, user_agent_hash. Migration da bir sey eksik: **ALTER TABLE consent_logs ENABLE ROW LEVEL SECURITY ifadesi yok**. Supabase default li tablo ENABLE RLS yapilmazsa anon-key + authenticated her ikisi de SELECT/INSERT yapabilir. DevTools, affiliate JWT (test account readonly): GET /rest/v1/consent_logs?select=*&limit=10000 → **10,000 row consent event tüm restaurants + customers + affiliates + visitors**. accepted_at + device_hash + user_agent_hash + ip_hash visible. Selma "GDPR Article 5(1)(f) integrity + confidentiality breach + Article 32 inappropriate access controls" writeup security@thmenu.com a. **4 attack surface**: (1) user_id PII linkage authenticated session auth.uid() identifier joinable; (2) device_hash + ip_hash + user_agent_hash correlation gun ici cross-app; (3) per-app accept rates aggregate intel competitor SaaS marketing efficiency tahmin; (4) behavioral pattern "always accepts" / "always rejects" privacy-conscious profil. Engineering 1 saat reproduce + severity MEDIUM/HIGH. Migration inspect: CREATE TABLE consent_logs (...) — RLS yok. **Mirror of PR #603 BBB F1**: affiliate_postback_log + affiliate_tier_events + affiliate_1099_alerts ayni RLS-omission pattern PR #603 fix. consent_logs ayrı RLS-at-create-time gap, yeni migration ayni hatayla shipped. **PR #616 batch EEE F3** fix sade — supabase/migrations/20260524000002_consent_logs_rls.sql: `ALTER TABLE consent_logs ENABLE ROW LEVEL SECURITY;` + NO policy = default-deny anon/authenticated, sadece service_role bypass. Writes (CookieBanner POST handler) zaten service_role kullaniyor, degisiklik gerek yok. Future DSR per-user policy hazirda (CREATE POLICY consent_logs_self_select USING (user_id = auth.uid())) henüz dashboard tarafinda implement edilmedi. **Bonus sweep**: SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = "public" AND rowsecurity = false — consent_logs + affiliate_payout_log staging + customer_preferences cache 3 tablo RLS-disabled, ayni PR da fix. 90-gun audit 0 prior exploit (migration 4 gun once shipped kisa exposure window). Selma MEDIUM/HIGH severity + €500 Wise + Hall of Fame + 1-year Pro tier. Synaltix internal GDPR DPA addendum + Schrems II audit docs guncellendi: "Supabase RLS now enforced on all PII-bearing tables + ENABLE RLS validation in PR template." Annika Köln Ehrenfeld (@annikapriv, 9 yil DACH + EU SaaS Schrems II + GDPR Article 32 audit) version ayni flow. Pattern: **Supabase yeni tablo migration inda ENABLE ROW LEVEL SECURITY mandatory + default policy "no one can read" (sadece service_role bypass). Public-readable veya per-user-readable tablolar icin EXPLICIT policy create — default-deny semantics. PR template a "Does this migration ENABLE ROW LEVEL SECURITY?" checkbox + quarterly pg_tables rowsecurity audit.** Implementation checklist: (1) ALTER TABLE ENABLE ROW LEVEL SECURITY her CREATE TABLE sonra; (2) NO SELECT policy = service_role only PUBLIC ihtiyac EXPLICIT policy; (3) per-user authenticated policy USING (user_id = auth.uid()); (4) per-tenant authenticated policy org/tenant key match; (5) PR template checklist mandatory tick; (6) quarterly pg_tables rowsecurity false sweep; (7) pentest anon-key + JWT-affiliate + JWT-customer her yeni tablo /rest/v1 enumerate empty array veya 403 expect; (8) Schrems II audit doc PII-bearing tablo RLS posture list.

İlgili makaleler