RLS bloqueia UPDATE e DELETE pela chave anônima
Envia PATCH e DELETE para cada tabela com o filtro id=eq.__veloz_audit_nonexistent__, que não corresponde a nenhuma linha, e confere se o banco recusa a operação por permissão.
Por que importa
Se a chave anônima pode alterar ou apagar linhas, qualquer visitante pode fazer o mesmo, porque a chave vai junto com o front-end. Isso acontece quando a tabela está sem RLS ou tem uma política de UPDATE ou DELETE que aceita qualquer usuário, como USING (true).
Como corrigir
Em cada tabela exposta, rode ALTER TABLE <tabela> ENABLE ROW LEVEL SECURITY e crie políticas FOR UPDATE e FOR DELETE ligadas ao dono da linha, por exemplo USING (auth.uid() = user_id).
Como conferir a correção
SB-004
# O filtro usa um id que não existe, então nenhuma linha é alterada.
# O Shield conta 401, 403 ou o código 42501 como bloqueio e 204 como operação aceita.
curl -s -w '\n%{http_code}\n' \
-X PATCH "$SUPABASE_URL/rest/v1/<tabela>?id=eq.__veloz_audit_nonexistent__" \
-H "apikey: $ANON_KEY" -H "Authorization: Bearer $ANON_KEY" \
-H 'Content-Type: application/json' \
-d '{}'