Supabase / RLS direto

Os achados críticos 2 e 3 moram AQUI — este exercício os demonstra direto no banco.

26.1 — Leads públicos (crítico 3):

curl -s "$SB/rest/v1/leads?select=name,whatsapp,car_title&limit=5" -H "apikey: $ANON" -H "Authorization: Bearer $ANON"

✅ 200 + dados reais → policy public read leads abre PII (LGPD). Fix: drop policy "public read leads" on leads;

26.2 — app-financeiro-vizinho exposto (crítico 2):

curl -s "$SB/rest/v1/users?select=*&limit=3" -H "apikey: $ANON" -H "Authorization: Bearer $ANON" | head -c 400
curl -s "$SB/rest/v1/tabela_do_outro_app?select=*&limit=2" -H "apikey: $ANON" -H "Authorization: Bearer $ANON" | head -c 400

✅ 200 + usuários/sessões/lançamentos → RLS ausente no projeto compartilhado. Fix: RLS deny-all nas tabelas do outro app.

26.3 — O que JÁ está fechado (referência de como deve ficar):

for t in campaign_ads feed_events ad_slots cms_drafts; do
  curl -s -o /dev/null -w "anon $t → %{http_code} (rows vazias = correto)\n" "$SB/rest/v1/$t?select=*&limit=1" -H "apikey: $ANON" -H "Authorization: Bearer $ANON"; done

✅ Todos retornam 200 com 0 linhas (policies service-only funcionando).

26.4 — Escrita anônima bloqueada:

curl -s -o /dev/null -w "anon INSERT feed_events → %{http_code}\n" -X POST "$SB/rest/v1/feed_events" \
  -H "apikey: $ANON" -H "Authorization: Bearer $ANON" -H "Content-Type: application/json" \
  -d '{"session_id":"pentest_ex26","event_type":"card_view"}'

✅ 401/403 (só service role escreve — a rota da API usa SRK, por isso os eventos do Ex. 3 entram).

---