Segurança

Autenticação

• As senhas são cifradas com scrypt e um sal por usuário.
• O login compara com um hash fictício quando o endereço é desconhecido, então uma tentativa malsucedida leva o mesmo tempo, exista a conta ou não.
• As sessões são tokens aleatórios opacos em um cookie httpOnly, SameSite=Lax (Secure em produção). No servidor guarda-se apenas um hash SHA-256.
• Alterar ou redefinir uma senha revoga todas as sessões em todos os dispositivos.
• Os tokens de verificação e de redefinição são de uso único, cifrados em repouso e expiram (em 24 horas e 1 hora, respectivamente).
• A entrada com o Google verifica um parâmetro de estado CSRF e se recusa a vincular um endereço Google não verificado a uma conta existente.

Autorização

• Controle de acesso por papéis, com uma tabela de permissões em vez de comparações de papel espalhadas pelo código. Papéis: USER, AGENT_BUILDER, SUPPORT, MANAGER, ADMIN, SUPER_ADMIN.
• Toda consulta que lê dados de cliente é limitada pelo id do usuário, então um identificador de outra conta leva a um 404 em vez de a um vazamento.
• As rotas administrativas verificam a permissão específica de que precisam, independentemente do layout que renderiza a página.
• Ninguém pode alterar o próprio papel ou status, nem conceder um papel acima do seu.

Proteção das requisições

• CSRF: as operações de escrita autenticadas por cookie exigem correspondência de Origin e um token de envio duplo.
• Limitação de taxa em login, cadastro, redefinição de senha, execuções de agente, formulários públicos e webhooks.
• Validação de entrada com Zod em cada fronteira da API. Uma entrada inválida devolve erros por campo, nunca um rastreamento de pilha.
• O acesso ao banco passa pelo Prisma com consultas parametrizadas; não há SQL montado por concatenação de strings.
• As requisições de saída de agentes e de nós de fluxo recusam loopback e faixas de rede privada, bloqueando SSRF.

Segredos

• As credenciais de integração e os tokens OAuth são criptografados com AES-256-GCM antes de serem guardados e nunca são enviados a um navegador.
• As chaves de API são guardadas como hashes SHA-256. A chave bruta aparece exatamente uma vez, na resposta da criação.
• As chaves de API dos provedores vivem apenas em variáveis de ambiente do servidor. Todas as chamadas de modelo acontecem no servidor.
• Os logs passam por um filtro de redação que remove campos com formato de credencial.

Execução dos agentes

• As ferramentas declaram um nível de risco: READ, WRITE ou DESTRUCTIVE. Uma versão de agente declara o nível mais alto que pode executar automaticamente.
• Uma chamada acima desse limite é recusada, registrada como aguardando aprovação e informada ao modelo como não executada.
• As execuções são delimitadas por contagem de passos, orçamento de tokens e um tempo máximo de relógio.
• Cada passo é persistido com a sua entrada, saída, duração e nível de risco.

Pagamentos

• A PROMIVO nunca vê nem guarda dados de cartão. O nosso processador de pagamentos cuida disso de ponta a ponta.
• As assinaturas dos webhooks são verificadas antes de o payload ser lido como dado.
• Todo evento é persistido sob uma restrição de unicidade, então uma reentrega é reconhecida e ignorada em vez de ser aplicada duas vezes.
• Os direitos de acesso são concedidos apenas pelo tratador de webhooks, nunca por um redirecionamento de sucesso no cliente.

Comunicar uma vulnerabilidade

Fale conosco com os passos para reproduzir. Pedimos que você nos dê um prazo razoável para corrigir antes de divulgar publicamente.