A nova era da gestão
imobiliária e fintech.

PROJETO AUDITADO: ECOSSISTEMA MORAR BEM BRASIL / DIAMOND TIPO DE EXECUÇÃO: SEGUNDA AUDITORIA TÉCNICA INDEPENDENTE ESCOPO EXCLUSIVO: 1. Segurança; 2. Autenticação; 3. Autorização; 4. Multitenancy; 5. RBAC; 6. RLS; 7. Banco de dados; 8. Storage privado; 9. Integridade referencial; 10. Ledger financeiro; 11. Wallets; 12. Cashback; 13. Caução de manutenção; 14. Saques; 15. Split financeiro; 16. Repasses; 17. Comissões; 18. Recebíveis; 19. Antecipações; 20. Estornos; 21. Idempotência; 22. Concorrência; 23. Audit Logs; 24. Webhooks financeiros; 25. Conciliação; 26. Integridade das funções backend. ============================================================ 0. RESTRIÇÃO ABSOLUTA DESTA AUDITORIA ============================================================ NÃO ALTERAR: - layout; - identidade visual; - cores; - tipografia; - sidebar; - menu; - cards; - dashboard; - espaçamento; - responsividade; - design system; - componentes visuais; - organização estética das páginas; - textos comerciais; - landing page; - UX existente. Esta auditoria NÃO é uma auditoria visual. Não redesenhar nenhuma tela. Não refatorar frontend por preferência estética. Não substituir componentes que estejam funcionando. Somente alterações de frontend estritamente necessárias para: - bloquear acesso indevido; - corrigir exposição de dados; - impedir ação financeira inválida; - remover segredo exposto; - corrigir permissão; - corrigir autenticação; - impedir vulnerabilidade. O foco desta execução é: BACKEND + DATABASE + SECURITY + FINANCIAL INTEGRITY. ============================================================ 1. PAPEL DO AUDITOR ============================================================ Atue como uma equipe independente formada por: - Security Architect; - Application Security Engineer; - PostgreSQL DBA; - Especialista Supabase; - Especialista RLS; - Especialista Multitenancy; - Especialista IAM/RBAC; - Engenheiro Backend Sênior; - Especialista Fintech; - Especialista em Double-Entry Ledger; - Especialista em sistemas transacionais; - Especialista em prevenção de fraude; - Especialista em conciliação financeira; - Engenheiro de testes; - Auditor de sistemas financeiros; - Especialista em logs e rastreabilidade. Assuma postura de auditoria independente. NÃO confiar na implementação existente. NÃO presumir que uma função está correta porque possui o nome correto. NÃO presumir que RLS está funcionando porque RLS está habilitado. NÃO presumir que saldo está correto porque o dashboard apresenta determinado número. COMPROVAR. ============================================================ 2. PRINCÍPIO DE ZERO CONFIANÇA ============================================================ Tratar como potencialmente malicioso: - frontend; - navegador; - usuário; - payload; - query string; - route params; - localStorage; - sessionStorage; - headers enviados pelo cliente; - IDs enviados pelo usuário; - valores monetários enviados pelo frontend; - role enviada pelo frontend; - organization_id enviado pelo frontend. O backend deverá recalcular ou validar informações sensíveis. O frontend nunca poderá ser autoridade para: role; tenant; saldo; cashback; limite de saque; split; comissão; caução; permissão; aprovação; organization_id; parent organization. ============================================================ 3. METODOLOGIA ============================================================ Executar: MAPEAR → TESTAR → TENTAR QUEBRAR → IDENTIFICAR → CLASSIFICAR → CORRIGIR → RETESTAR → DOCUMENTAR. Não encerrar após gerar relatório. Corrigir tecnicamente tudo que puder ser corrigido internamente. ============================================================ 4. CLASSIFICAÇÃO DE RESULTADOS ============================================================ Usar: ✅ CONFORME ⚠️ PARCIALMENTE CONFORME ❌ NÃO CONFORME 🚨 CRÍTICO 🔌 DEPENDÊNCIA EXTERNA Para vulnerabilidades utilizar severidade: P0 — CRÍTICA P1 — ALTA P2 — MÉDIA P3 — BAIXA P0 ou P1 impedem aprovação final. ============================================================ 5. INVENTÁRIO DO BANCO ============================================================ Mapear o PostgreSQL real. Listar: schemas; tables; views; materialized views; functions; procedures; RPCs; triggers; sequences; indexes; constraints; foreign keys; policies; storage buckets; extensions. Para cada tabela informar: Tabela Finalidade RLS Policies FKs Indexes Triggers Dados sensíveis? Dados financeiros? ============================================================ 6. INVENTÁRIO DAS MIGRATIONS ============================================================ Auditar todas as migrations. Verificar: ordem; dependências; repetições; migrações quebradas; migrações destrutivas; DROP; ALTER; dados históricos; constraints ausentes. Não editar migration histórica já executada como solução rápida. Criar migrations incrementais corretivas. ============================================================ 7. AUDITORIA DE AUTH ============================================================ Auditar Supabase Auth. Testar: login; logout; refresh; token expirado; refresh token inválido; usuário bloqueado; usuário desativado; reset de senha; verificação de e-mail; sessões paralelas; token revogado. Nenhum usuário desativado deverá continuar operando através de token antigo indevidamente. ============================================================ 8. ESCALADA DE PRIVILÉGIOS ============================================================ Executar testes tentando: Associado → Associação Associado → Federação Associado → Admin Global Parceiro → Global Associação → Federação Federação → Global. Testar via: URL; RPC; REST Supabase; query; mutation; payload modificado. Resultado esperado: NEGADO NO BACKEND. ============================================================ 9. ROLE TAMPERING ============================================================ Modificar manualmente no request: role = admin role = global role = treasury. Sistema deverá ignorar role declarada pelo cliente. Role válida deverá ser resolvida server-side. ============================================================ 10. ORGANIZATION_ID TAMPERING ============================================================ Associado da Associação A envia: organization_id = Associação B. Resultado esperado: backend rejeita ou ignora. Nunca confiar em organization_id enviado pelo frontend. ============================================================ 11. MULTITENANCY ============================================================ Validar hierarquia: GLOBAL ↓ FEDERAÇÃO ↓ ASSOCIAÇÃO ↓ ASSOCIADO. Também: PARCEIRO como tenant isolado apropriado. Criar massa de teste: Federação A Federação B Associação A1 Associação A2 Associação B1 Associado A1-1 Associado A2-1 Associado B1-1. ============================================================ 12. TESTE CRÍTICO DE ISOLAMENTO ============================================================ Login: Federação A. Executar consulta manual buscando: Associação B1. ESPERADO: 0 registros. Não aceitar apenas: "item escondido na UI". ============================================================ 13. ISOLAMENTO DE ASSOCIAÇÃO ============================================================ Login: Associação A1. Consultar diretamente: Associado A2-1. Esperado: NEGADO. Consultar: Associado B1-1. Esperado: NEGADO. ============================================================ 14. ISOLAMENTO DE PARCEIRO ============================================================ Parceiro A tenta acessar: partner_id do Parceiro B; receivables do Parceiro B; wallet do Parceiro B; transações do Parceiro B; clientes do Parceiro B. Tudo deverá ser negado. ============================================================ 15. ISOLAMENTO DO ASSOCIADO ============================================================ Associado A tenta consultar: profile de Associado B; wallet; document; credit_application; contract; transaction; notification. Tudo deverá ser negado. ============================================================ 16. AUDITORIA COMPLETA DE RLS ============================================================ Para TODAS as tabelas acessíveis pelo frontend: verificar: ENABLE ROW LEVEL SECURITY. Listar policies: SELECT INSERT UPDATE DELETE. Não aceitar tabela sensível com: RLS OFF. ============================================================ 17. TABELAS RLS CRÍTICAS ============================================================ Auditar obrigatoriamente: profiles organizations organization_memberships documents credit_applications credit_evaluations external_credit_checks crm_leads crm_stage_history properties property_matches property_offers contracts contract_parties contract_signatures wallets financial_accounts ledger_transactions ledger_entries payments cashback_events withdrawals split_rules split_rule_recipients split_executions receivables anticipation_requests partners partner_services notifications consents audit_logs. ============================================================ 18. POLICIES PERMISSIVAS ============================================================ Pesquisar policies como: USING (true) WITH CHECK (true) auth.role() = 'authenticated' sem escopo adicional. Verificar se permitem acesso excessivo. Qualquer policy excessivamente ampla deverá ser corrigida. ============================================================ 19. BYPASS RLS ============================================================ Pesquisar onde: service_role ou funções SECURITY DEFINER podem bypassar RLS. Para cada SECURITY DEFINER: auditar. Verificar: search_path seguro; parâmetros; validações; ownership; quem pode executar; tenant validation. ============================================================ 20. RPC SECURITY ============================================================ Listar todas as RPCs. Testar chamadas manuais. Uma RPC financeira nunca deverá confiar em: user_id recebido; organization_id; balance; commission; cashback; role. Resolver informações no servidor sempre que possível. ============================================================ 21. SECURITY DEFINER HARDENING ============================================================ Funções SECURITY DEFINER deverão: definir search_path explicitamente; validar auth.uid(); validar permissão; validar tenant; validar parâmetros; não permitir SQL dinâmico inseguro. ============================================================ 22. STORAGE ============================================================ Auditar buckets. Documentos sensíveis deverão estar: PRIVATE. Verificar: CNH; RG; CPF; IR; comprovantes; holerites; extratos; contratos. Nenhum deverá possuir URL pública permanente. ============================================================ 23. TESTE STORAGE IDOR ============================================================ Associado A solicita signed URL para documento do Associado B. ESPERADO: NEGADO. Federação tenta abrir IR de associado sem permissão específica. ESPERADO: NEGADO. ============================================================ 24. SIGNED URL ============================================================ Validar: expiração; autorização; bucket; path; ownership. Não gerar signed URL apenas porque o cliente conhece storage_path. ============================================================ 25. SERVICE ROLE ============================================================ Pesquisar integralmente: SUPABASE_SERVICE_ROLE_KEY service_role SERVICE_KEY. Jamais poderá existir no bundle frontend. Se encontrada: P0 — CRÍTICO. Remover imediatamente. Rotacionar segredo se necessário. ============================================================ 26. ENVIRONMENT SECRETS ============================================================ Pesquisar: API keys; JWT secrets; payment keys; Serasa keys; SPC keys; webhook secrets; private keys; database credentials. Confirmar armazenamento seguro. Não versionar secrets. ============================================================ 27. MASS ASSIGNMENT ============================================================ Tentar enviar campos adicionais: role; approved_limit; wallet_balance; cashback_balance; organization_id; status=approved; commission; is_admin. Backend deverá impedir alteração não autorizada. ============================================================ 28. BANCO — CONSTRAINTS ============================================================ Auditar: PRIMARY KEY FOREIGN KEY UNIQUE CHECK NOT NULL. Não depender exclusivamente de validação Typescript. ============================================================ 29. DADOS MONETÁRIOS ============================================================ Verificar tipos. Valores monetários deverão utilizar: NUMERIC / DECIMAL. Não utilizar: FLOAT REAL DOUBLE PRECISION para cálculos financeiros críticos. ============================================================ 30. SALDOS NEGATIVOS ============================================================ Verificar possibilidade de: wallet < 0; cashback < 0; reserve < 0. Bloquear onde não permitido. ============================================================ 31. DOUBLE-ENTRY LEDGER ============================================================ Auditar se a arquitetura financeira utiliza ledger de dupla entrada. Obrigatório: financial_accounts ledger_transactions ledger_entries ou estrutura equivalente tecnicamente válida. Saldo não deverá depender apenas de: wallet.balance = wallet.balance + amount. ============================================================ 32. PRINCÍPIO CONTÁBIL ============================================================ Para toda ledger_transaction: SOMA DOS DÉBITOS = SOMA DOS CRÉDITOS. Criar query automática de auditoria. Nenhuma exceção permitida. Se existir divergência: P0 — CRÍTICO. ============================================================ 33. QUERY DE INTEGRIDADE DO LEDGER ============================================================ Executar varredura em TODAS as ledger_transactions. Identificar qualquer: out-of-balance transaction. Resultado esperado: ZERO. ============================================================ 34. LEDGER IMUTÁVEL ============================================================ Transação financeira liquidada NÃO deverá ser editada. Correção deverá ocorrer através de: reversal; adjustment; compensating entry. Não permitir UPDATE destrutivo de transação histórica liquidada. ============================================================ 35. DELETE FINANCEIRO ============================================================ Verificar permissões DELETE. Usuário comum nunca deverá deletar: ledger_entries; payments; cashback_events; withdrawals; split_executions; audit_logs. ============================================================ 36. WALLET ============================================================ Confirmar que wallet apresenta uma projeção/resumo. Validar: saldo total; saldo disponível; cashback; saldo bloqueado; caução; recebível. Cada conceito deverá ser independente. ============================================================ 37. RECONCILIAÇÃO WALLET X LEDGER ============================================================ Recalcular saldo pelo ledger. Comparar com wallet. Resultado esperado: DIFERENÇA = R$ 0,00. Se wallet estiver divergente: investigar origem e corrigir. ============================================================ 38. CAUÇÃO OBRIGATÓRIA ============================================================ Regra: R$ 50,00. Validar criação da conta do Associado. A caução deverá estar em estrutura contabilmente identificável. Exemplo: maintenance_reserve. ============================================================ 39. CAUÇÃO NÃO SACÁVEL ============================================================ Tentar saque da caução por: UI; RPC; REST; payload modificado. Saque comum deverá ser bloqueado. ============================================================ 40. CASHBACK ============================================================ Auditar cálculo. Verificar: origem; regra; percentual; amount; status; availability; reversal. Não permitir gerar cashback sem transação origem válida. ============================================================ 41. CASHBACK DUPLICADO ============================================================ Reexecutar processamento do mesmo pagamento. Resultado esperado: cashback criado apenas uma vez. ============================================================ 42. CASHBACK REVERTIDO ============================================================ Executar compra. Gerar cashback. Depois estornar compra. Resultado esperado: cashback correspondente também deve ser: reversed ou compensado adequadamente. Não poderá permanecer disponível para saque. ============================================================ 43. REGRA DE SAQUE ============================================================ REGRA: cashback_available < 100 → bloqueado. cashback_available >= 100 → permitido mantendo R$ 50. Fórmula: max_withdrawable = cashback_available - 50 quando elegível. ============================================================ 44. MATRIZ DE TESTE DE SAQUE ============================================================ Executar: Cashback R$ 0 → R$ 0. R$ 49 → R$ 0. R$ 50 → R$ 0. R$ 99 → R$ 0. R$ 100 → R$ 50. R$ 101 → R$ 51. R$ 150 → R$ 100. R$ 500 → R$ 450. Registrar resultados. ============================================================ 45. BACKEND AUTHORITATIVE WITHDRAWAL ============================================================ Frontend nunca define: max_withdrawable. Backend deverá calcular novamente. Modificar DOM e enviar valor superior. Resultado esperado: REJEITADO. ============================================================ 46. DOUBLE WITHDRAWAL ATTACK ============================================================ Enviar simultaneamente duas solicitações de saque. Exemplo: cashback = R$ 150. Enviar: saque R$ 100 + saque R$ 100 simultaneamente. O sistema jamais poderá aprovar ambos. Usar: transaction; locking; serializable/advisory lock ou mecanismo equivalente. ============================================================ 47. WITHDRAWAL IDEMPOTENCY ============================================================ Reenviar mesma solicitação com: idempotency_key idêntica. Resultado: uma única operação. ============================================================ 48. ENCERRAMENTO DA CONTA ============================================================ Retirada dos R$ 50 não é saque comum. Verificar: account_closure_request. Tentar usar RPC de saque comum para retirar reserve. Resultado: NEGADO. ============================================================ 49. SPLIT ENGINE ============================================================ Auditar: split_rules split_rule_recipients split_executions. Percentuais deverão ser dados parametrizados. Não hardcoded. ============================================================ 50. SOMA DO SPLIT ============================================================ Executar query buscando regras onde: SUM(percent) != 100%. Resultado esperado: ZERO regras ativas inválidas. Adicionar constraint ou validação transacional adequada. ============================================================ 51. DESTINATÁRIOS ============================================================ Validar destinos possíveis: partner platform associate_cashback association federation reserve quando aplicável. ============================================================ 52. HIERARQUIA DO SPLIT ============================================================ Associado pertence: Associação A → Federação A. Pagamento deve distribuir comissão somente: Associação A Federação A. Nunca outra organização. Resolver hierarquia no backend. ============================================================ 53. TESTE FINANCEIRO DE SPLIT ============================================================ Criar pagamento: R$ 1.000,00. Executar split. Auditar: valor bruto; participantes; percentuais; valores; arredondamentos; cashback; ledger; audit log. A soma final deverá ser exactly: R$ 1.000,00. ============================================================ 54. ARREDONDAMENTO ============================================================ Testar: R$ 10,00 R$ 10,01 R$ 99,99 R$ 100,00 R$ 1.000,01. Garantir distribuição correta dos centavos. Nenhum centavo poderá: sumir; duplicar; ficar sem contabilização. ============================================================ 55. ROUNDING RESIDUAL ============================================================ Definir estratégia explícita para centavos residuais. Exemplo: largest remainder ou destinatário residual configurado. Não utilizar arredondamento independente que altere o total. ============================================================ 56. PAYMENT IDEMPOTENCY ============================================================ Todo pagamento deverá possuir: idempotency_key UNIQUE. Reprocessar mesmo evento. Resultado: sem duplicação. ============================================================ 57. WEBHOOK DUPLICADO ============================================================ Simular provider enviando webhook três vezes. Resultado: um processamento financeiro. Os demais deverão ser reconhecidos como duplicados. ============================================================ 58. WEBHOOK SECURITY ============================================================ Se existirem webhooks reais: validar assinatura; timestamp; replay protection; provider; event_id. Não aceitar webhook financeiro simplesmente por endpoint público. ============================================================ 59. PAYMENT STATUS TRANSITIONS ============================================================ Validar transições. Exemplo: pending → confirmed → settled. Evitar transições inválidas como: failed → settled sem regra explícita. ============================================================ 60. ESTORNO ============================================================ Testar: pagamento → split → cashback → comissão. Depois: REFUND. Sistema deverá gerar lançamentos de compensação apropriados. Não simplesmente apagar transação original. ============================================================ 61. PARTIAL REFUND ============================================================ Testar estorno parcial. Exemplo: pagamento R$ 1.000. estorno R$ 250. Distribuir reversões proporcionalmente ou conforme regra definida. Ledger deverá continuar balanceado. ============================================================ 62. RECEBÍVEIS ============================================================ Auditar: partner_receivables / receivables. Verificar: gross_amount; fees; net_amount; available_at; status. Não permitir antecipação de valor inexistente. ============================================================ 63. ANTECIPAÇÃO ============================================================ Testar: recebível R$ 1.000. Antecipação com taxa configurada. Validar: bruto; taxa; líquido; ledger; status; recebível residual. ============================================================ 64. DUPLA ANTECIPAÇÃO ============================================================ Tentar antecipar o mesmo recebível duas vezes simultaneamente. Resultado esperado: uma única aprovação. ============================================================ 65. COMMISSION ENGINE ============================================================ Auditar comissões: Federação; Associação; Plataforma; Parceiro. Verificar: regra; vigência; versionamento; origem; transaction_id. ============================================================ 66. ALTERAÇÃO DE SPLIT ============================================================ Quando percentual futuro for alterado: não recalcular transações históricas. Regra aplicada deverá ficar versionada ou registrada no split_execution. ============================================================ 67. CONCILIAÇÃO ============================================================ Criar auditoria comparando: payments ↔ ledger ↔ split ↔ cashback ↔ wallet ↔ receivables. Detectar: pagamento sem ledger; ledger sem pagamento; cashback sem pagamento; split sem ledger; recebível inconsistente. ============================================================ 68. TRANSAÇÕES ÓRFÃS ============================================================ Pesquisar: ledger_entries sem ledger_transaction; cashback_event sem payment; withdrawal sem ledger; split sem payment; receivable sem source. Resultado esperado: ZERO. ============================================================ 69. FOREIGN KEYS ============================================================ Verificar integridade referencial física. Não depender apenas de UUIDs relacionados logicamente. Criar FKs onde apropriado. ============================================================ 70. AUDIT LOGS ============================================================ Auditar: audit_logs. Deverá registrar ações críticas. ============================================================ 71. AUDIT LOG FINANCEIRO ============================================================ Registrar: pagamento; split; cashback; saque; estorno; antecipação; alteração de regra; ajuste; encerramento. ============================================================ 72. AUDIT LOG DE SEGURANÇA ============================================================ Registrar: alteração de role; alteração de membership; bloqueio de usuário; falha de autorização crítica; acesso a documento sensível; alteração de policy administrativa quando aplicável. ============================================================ 73. AUDIT LOG APPEND-ONLY ============================================================ Usuário comum: não pode UPDATE. não pode DELETE. Administradores comuns tampouco deverão poder reescrever trilha histórica sem mecanismo especial auditado. ============================================================ 74. LOGS E DADOS SENSÍVEIS ============================================================ Pesquisar logs contendo: CPF integral; documentos; senhas; tokens; chaves; dados clínicos; payload financeiro desnecessário. Remover informações sensíveis dos logs. ============================================================ 75. SQL INJECTION ============================================================ Pesquisar: SQL dinâmico; EXECUTE; string concatenation; raw SQL. Verificar sanitização. ============================================================ 76. IDOR ============================================================ Testar manipulação de IDs em: /users/:id /documents/:id /contracts/:id /payments/:id /wallets/:id /withdrawals/:id /partners/:id. A existência de UUID não substitui autorização. ============================================================ 77. RATE LIMITING ============================================================ Verificar endpoints sensíveis: login; password reset; document signed URL; credit check; withdrawal; payment; webhook. Implementar proteção quando apropriado. ============================================================ 78. BRUTE FORCE ============================================================ Auditar proteção do login e fluxos sensíveis contra abuso. ============================================================ 79. REPLAY ATTACK ============================================================ Testar repetição de: pagamento; saque; webhook; split; antecipação. Idempotência deverá bloquear duplicação. ============================================================ 80. RACE CONDITIONS ============================================================ Executar testes concorrentes sobre: saque; pagamento; split; cashback; antecipação. Detectar: lost updates; double spend; double payout. ============================================================ 81. TRANSACTION BOUNDARIES ============================================================ Operações financeiras multi-etapa deverão ocorrer em transação ACID. Exemplo: Pagamento + Ledger + Split + Cashback + Recebível. If etapa crítica falhar: ROLLBACK. ============================================================ 82. TESTE DE ROLLBACK ============================================================ Forçar falha durante processamento de pagamento. Verificar se sistema deixa: saldo atualizado parcialmente; cashback sem split; split sem ledger. Resultado esperado: nenhum efeito parcial. ============================================================ 83. CHECK CONSTRAINTS FINANCEIRAS ============================================================ Criar/revisar CHECKS para impedir: amount <= 0; percent < 0; percent > 100; cashback negativo; withdrawal negativo; saldo inválido. ============================================================ 84. TRANSACTION STATUS MACHINE ============================================================ Auditar estados e transições. Não aceitar alteração arbitrária por update direto. ============================================================ 85. RESTRIÇÃO DE UPDATE ============================================================ Tentar editar diretamente via Supabase client: wallet.balance; cashback_balance; approved_limit; withdrawal.status; payment.status. Usuário sem permissão deve ser bloqueado. ============================================================ 86. ADMIN GLOBAL ============================================================ Mesmo Admin Global deverá utilizar operações financeiras controladas. Admin Global não deve possuir botão/API: "editar saldo livremente" sem criar ajuste financeiro auditado. ============================================================ 87. AJUSTE MANUAL ============================================================ Se existir ajuste administrativo de saldo: exigir: reason; actor; timestamp; approval; ledger transaction; audit log. Nunca UPDATE direto. ============================================================ 88. LGPD E DADOS FINANCEIROS ============================================================ Garantir princípio de menor acesso. Federação não deve receber dados financeiros individuais detalhados por padrão. Associação também não. O acesso deve refletir finalidade e permissão. ============================================================ 89. CREDIT DATA SECURITY ============================================================ Resultados SPC/Serasa/consultas externas: não deverão estar acessíveis a perfis não autorizados. Auditar RLS das tabelas de credit checks. ============================================================ 90. SECURITY HEADERS E CORS ============================================================ Auditar configurações aplicáveis: CORS; CSP; HSTS; X-Content-Type-Options; frame protection; referrer policy. Sem alterar layout. ============================================================ 91. DEPENDÊNCIAS ============================================================ Auditar pacotes críticos. Verificar dependências: desatualizadas; vulneráveis; abandonadas. Não atualizar major version indiscriminadamente. Corrigir apenas com avaliação de impacto. ============================================================ 92. SUPABASE SECURITY ============================================================ Verificar: Anon key uso correto; service role; RLS; storage; functions; JWT; auth claims; database roles. ============================================================ 93. SEARCH_PATH ============================================================ Auditar functions PostgreSQL. Evitar search_path manipulável em SECURITY DEFINER. ============================================================ 94. PERMISSION ON FUNCTIONS ============================================================ Verificar GRANT EXECUTE. RPC sensível não deverá ser executável por perfil inadequado. ============================================================ 95. DATABASE FUNCTION OWNERS ============================================================ Auditar ownership de funções críticas. Reduzir privilégios desnecessários. ============================================================ 96. EXPOSED TABLES ============================================================ Identificar tabelas expostas à API Supabase. Verificar se deveriam estar expostas. Estruturas internas do ledger podem precisar de acesso apenas através de RPC segura. ============================================================ 97. PII MASKING ============================================================ Listagens devem utilizar dados mascarados quando apropriado. Mascaramento frontend não substitui controle de acesso. ============================================================ 98. BACKUP / RECOVERY ============================================================ Verificar configuração disponível do backend. Documentar: backup; restore; PITR quando disponível; procedimentos de recuperação. Não alterar plano/infra sem autorização, apenas auditar e documentar. ============================================================ 99. TESTES AUTOMATIZADOS DE RLS ============================================================ Criar testes automatizados. Cobrir: Global; Federação A; Federação B; Associação A1; Associação B1; Parceiro A; Parceiro B; Associado A; Associado B. ============================================================ 100. TESTES AUTOMATIZADOS FINANCEIROS ============================================================ Cobrir: Ledger; Split; Cashback; Caução; Saque; Estorno; Antecipação; Idempotência; Concorrência; Arredondamento. ============================================================ 101. TESTES DE PROPRIEDADES INVARIANTES ============================================================ Criar invariantes: INVARIANTE 1 ledger debits = credits. INVARIANTE 2 split total = payment total. INVARIANTE 3 cashback nunca duplicado. INVARIANTE 4 maintenance reserve não entra em saque comum. INVARIANTE 5 wallet projected balance = ledger balance. INVARIANTE 6 tenant nunca acessa tenant externo. ============================================================ 102. FUZZ TESTING FINANCEIRO ============================================================ Quando viável, gerar diversos valores aleatórios. Exemplo: R$ 0,01 até R$ 1.000.000. Validar split e arredondamento. Nenhuma operação deve produzir inconsistência. ============================================================ 103. VALORES EXTREMOS ============================================================ Testar: 0 0,01 0,10 99,99 100 999999999. Validar limites de numeric e regras. ============================================================ 104. PROTEÇÃO CONTRA OVERFLOW ============================================================ Verificar precision/scale dos campos financeiros. Exemplo recomendado conforme necessidade: NUMERIC(18,2) ou estrutura equivalente devidamente dimensionada. ============================================================ 105. TIMESTAMPS ============================================================ Padronizar armazenamento temporal. Preferencialmente: timestamptz. Exibição local poderá ocorrer no frontend. Não alterar layout. ============================================================ 106. TIME-BASED RULES ============================================================ Se cashback, recebível ou contrato possuir data futura: validar no backend usando tempo confiável. Não confiar na data do navegador. ============================================================ 107. SOFT DELETE ============================================================ Auditar entidades onde soft-delete for necessário. Operações financeiras não devem simplesmente desaparecer. ============================================================ 108. DATA RETENTION ============================================================ Documentar regras para: documents; logs; financial records; credit checks. Não apagar registros exigidos para rastreabilidade sem política definida. ============================================================ 109. OBSERVABILIDADE ============================================================ Verificar existência de: request_id; correlation_id; transaction_id; integration_event_id. Uma operação financeira deverá poder ser rastreada ponta a ponta. ============================================================ 110. ERROR HANDLING ============================================================ Erros internos não deverão expor: SQL; secrets; stack trace; estrutura interna sensível. ============================================================ 111. FAIL CLOSED ============================================================ Na dúvida de permissão: NEGAR. Não utilizar: "se não encontrou role, liberar". ============================================================ 112. FALLBACKS ============================================================ Falha do SPC/Serasa/provider não deverá resultar automaticamente em: crédito aprovado. Status deve permanecer: consulta indisponível; análise pendente; provider error. ============================================================ 113. FRAUD RESILIENCE ============================================================ Auditar possibilidade de usuário: alterar cashback; simular pagamento; aprovar próprio crédito; aprovar próprio saque; alterar associação; alterar split. Tudo deverá ser bloqueado conforme perfil. ============================================================ 114. FOUR-EYES PRINCIPLE ============================================================ Avaliar operações de alto risco que podem exigir: solicitante != aprovador. Exemplo: ajustes extraordinários; antecipações de grande valor; mudança crítica de split; encerramentos especiais. Não criar burocracia indiscriminada. Documentar recomendações. ============================================================ 115. BANCO — DUPLICIDADES ============================================================ Pesquisar duplicidade em: cpf; email; external payment id; idempotency_key; contract id; wallet por user; membership. Criar UNIQUE adequado quando necessário. ============================================================ 116. UMA WALLET POR ESCOPO ============================================================ Se regra funcional determinar uma carteira por usuário: garantir UNIQUE(user_id). Se houver múltiplas carteiras por finalidade: modelar explicitamente. ============================================================ 117. CONSISTÊNCIA CPF/CNPJ ============================================================ Validar armazenamento e normalização. Evitar: 123.456.789-00 e 12345678900 como dois usuários distintos. ============================================================ 118. MATRIZ DE ACESSO FINAL ============================================================ Criar matriz: RECURSO GLOBAL FEDERAÇÃO ASSOCIAÇÃO PARCEIRO ASSOCIADO Operações: SELECT INSERT UPDATE DELETE EXECUTE. Gerar a matriz com base na implementação REAL. ============================================================ 119. MATRIZ FINANCEIRA ============================================================ Mapear: Evento Trigger Function Ledger Split Wallet Audit Idempotency. Exemplo: Payment Confirmed → process_payment() → ledger → split → cashback → receivable → audit. ============================================================ 120. GATES DE APROVAÇÃO ============================================================ GATE A — RLS ZERO vazamento entre tenants. GATE B — AUTH ZERO escalada de privilégio. GATE C — STORAGE ZERO documento sensível público. GATE D — SECRETS ZERO segredo crítico no frontend. GATE E — LEDGER ZERO transação desbalanceada. GATE F — WALLET ZERO divergência wallet x ledger. GATE G — CASHBACK ZERO duplicação. GATE H — SAQUE ZERO saque acima do permitido. GATE I — CAUÇÃO ZERO retirada via saque comum. GATE J — SPLIT 100% do valor contabilizado. GATE K — IDEMPOTÊNCIA ZERO duplicação por retry. GATE L — CONCORRÊNCIA ZERO double-spend. ============================================================ 121. CORREÇÃO OBRIGATÓRIA ============================================================ Após encontrar não conformidade: corrigir. Para banco: criar migration incremental. Para RLS: criar/alterar policy corretamente. Para functions: corrigir implementação. Para financeiro: preservar histórico. Não utilizar solução destrutiva. ============================================================ 122. NÃO RECRIAR BANCO SEM NECESSIDADE ============================================================ Não: DROP DATABASE; resetar produção; apagar tabelas; apagar histórico. Corrigir incrementalmente. ============================================================ 123. REGRESSÃO ============================================================ Após cada grupo de correções: executar novamente: RLS tests; ledger tests; split tests; cashback tests; withdrawal tests; idempotency tests. ============================================================ 124. NÃO ALTERAR VISUAL ============================================================ Reforço: É PROIBIDO aproveitar esta auditoria para: redesenhar dashboard; trocar cores; mudar cards; mudar menus; alterar sidebar; alterar tipografia; reorganizar páginas; "melhorar UX". Apenas segurança/backend/banco/financeiro. ============================================================ 125. RELATÓRIO FINAL ============================================================ Gerar: SEGUNDA AUDITORIA INDEPENDENTE MORAR BEM BRASIL / DIAMOND SEÇÕES: 1. Resumo executivo; 2. Arquitetura de segurança; 3. Banco; 4. RLS; 5. Multitenancy; 6. Storage; 7. Auth; 8. Secrets; 9. Ledger; 10. Wallet; 11. Cashback; 12. Caução; 13. Saque; 14. Split; 15. Estornos; 16. Recebíveis; 17. Antecipações; 18. Idempotência; 19. Concorrência; 20. Audit logs; 21. Correções realizadas; 22. Retestes; 23. Pendências externas; 24. Riscos residuais. ============================================================ 126. FORMATO DE CADA ACHADO ============================================================ SEC-001 TÍTULO: [...] SEVERIDADE: P0/P1/P2/P3 STATUS: ✅ / ⚠️ / ❌ / 🚨 RECURSO: [...] TABELA/FUNCTION/POLICY: [...] PROBLEMA: [...] RISCO: [...] TESTE: [...] RESULTADO: [...] CORREÇÃO APLICADA: [...] MIGRATION: [...] RETESTE: [...] RESULTADO FINAL: [...] ============================================================ 127. SCORE ============================================================ Gerar notas: SEGURANÇA: /100 AUTH: /100 RBAC: /100 RLS: /100 MULTITENANCY: /100 BANCO: /100 STORAGE: /100 LEDGER: /100 WALLET: /100 CASHBACK: /100 SAQUE: /100 SPLIT: /100 IDEMPOTÊNCIA: /100 CONCORRÊNCIA: /100 AUDITORIA: /100 INTEGRIDADE FINANCEIRA: /100. ============================================================ 128. APROVAÇÃO ============================================================ Somente escrever: "SEGUNDA AUDITORIA TÉCNICA APROVADA" se: P0 = 0 P1 = 0 RLS leaks = 0 Tenant leaks = 0 Exposed sensitive storage = 0 Secrets exposed = 0 Unbalanced ledger = 0 Wallet discrepancies = 0 Duplicate cashback = 0 Unauthorized withdrawals = 0 Invalid split rules = 0 Duplicate payment processing = 0 Double-spend scenarios = 0. ============================================================ 129. SE NÃO PASSAR ============================================================ Si qualquer GATE falhar: não declarar sistema aprovado. Informar: "SEGUNDA AUDITORIA TÉCNICA NÃO APROVADA." Corrigir. Retestar. Repetir até: P0 = ZERO P1 = ZERO. ============================================================ 130. COMANDO FINAL ============================================================ INICIE AGORA. 1. Não altere o layout. 2. Faça inventário real do backend e banco. 3. Audite Auth. 4. Audite RBAC. 5. Audite Multitenancy. 6. Audite todas as RLS. 7. Execute testes de isolamento. 8. Audite Storage. 9. Procure secrets. 10. Audite Ledger. 11. Recalcule os saldos. 12. Compare Wallet x Ledger. 13. Teste Caução. 14. Teste Cashback. 15. Teste todos os limites de Saque. 16. Teste Split. 17. Teste arredondamentos. 18. Teste estornos. 19. Teste idempotência. 20. Teste concorrência. 21. Teste double-spend. 22. Teste recebíveis. 23. Teste antecipações. 24. Audite Audit Logs. 25. Corrija não conformidades. 26. Crie migrations incrementais. 27. Reteste tudo. 28. Gere relatório com evidências. NÃO faça apenas uma análise conceitual. NÃO responda apenas dizendo que o código parece correto. EXECUTE consultas, testes e validações sempre que tecnicamente possível. O objetivo desta auditoria é provar que nenhum usuário consegue acessar aquilo que não deveria e que nenhum centavo pode ser criado, perdido, duplicado, transferido ou sacado incorretamente. A prioridade absoluta é: SEGURANÇA + ISOLAMENTO + RASTREABILIDADE + INTEGRIDADE FINANCEIRA. NÃO ALTERAR O LAYOUT EXISTENTE.