Revisão de segurança no vibe coding: o que testar antes de lançar

Um login que funciona e um pagamento de teste aprovado podem dar a impressão de que tudo está pronto. Os bugs de segurança costumam aparecer nas solicitações que deveriam falhar. Esta é uma revisão prática antes do lançamento, não um substituto para uma avaliação profissional de segurança.

Execute testes ativos somente em ambientes de staging que pertençam a você ou para os quais tenha permissão explícita. Use o modo de teste do provedor de pagamentos.

Verifique se segredos do servidor chegaram ao navegador

Abra o site implantado e inspecione Sources, Network e Storage nas ferramentas do desenvolvedor do navegador. Alguns valores, como uma chave publicável do Supabase, são feitos para serem públicos. sb_secret_..., service_role legado, sk_live_... e whsec_... do Stripe, e chaves privadas nunca devem estar presentes no navegador.

No Next.js, um valor referenciado estaticamente, como process.env.NEXT_PUBLIC_NAME, é incorporado ao bundle do navegador durante o next build. Ele permanece fixo se esse build for promovido depois para outro ambiente. Uma consulta dinâmica, como process.env[varName], não é incorporada automaticamente, mas isso não é uma forma segura de ocultar um segredo. Não use o prefixo NEXT_PUBLIC_ em valores exclusivos do servidor e leia-os somente no código do servidor.

A ausência de um arquivo .env no diretório atual prova muito pouco. Pesquise no código-fonte, pacotes gerados, histórico do Git, variáveis de ambiente do CI/CD, variáveis de ambiente da plataforma de implantação e logs. Esse padrão é apenas um ponto de partida; use um scanner de segredos dedicado e alertas do GitHub também.

rg -l --hidden --glob '!.git/**' --glob '!node_modules/**' \
  '(sb_secret_|SUPABASE_SERVICE_ROLE_KEY|service_role|sk_(live|test)_|sk-proj-|gh[pousr]_|github_pat_|AKIA[0-9A-Z]{16}|whsec_|BEGIN ([A-Z ]+ )?PRIVATE KEY)' .

Esse comando verifica apenas o checkout atual e informa nomes de arquivos, não os valores encontrados. Examine separadamente todo o histórico do Git com uma ferramenta que não imprima valores brutos, ou use a varredura de segredos do GitHub. Se um segredo real vazar, revogue-o antes de fazer qualquer limpeza: crie um substituto, migre todos os consumidores, desative a credencial antiga e só então trate o histórico do repositório. Nunca cole um segredo completo em um relatório de busca ou em um chamado.

Teste a fronteira de autorização com dois usuários

Crie contas de teste A e B, depois compare:

• uma solicitação sem autenticação e uma solicitação com um token inválido
• a conta A solicitando seu próprio recurso
• a conta A colocando o ID do recurso da conta B na URL ou no corpo da solicitação
• um usuário comum solicitando um campo ou ação exclusiva do administrador

Esconder um botão não é autorização. O servidor e o banco de dados devem validar a sessão, o papel e a propriedade do objeto em cada solicitação.

No Supabase, revise em conjunto a exposição da Data API, os privilégios GRANT dos papéis anon e authenticated e todas as políticas RLS existentes. O RLS seleciona as linhas permitidas; ele não oculta colunas. Proteja endereços de e-mail, notas internas e outros campos restritos com privilégios de coluna, uma view segura que exponha apenas os campos necessários ou uma API no servidor. Políticas permissivas existentes podem ser combinadas com as novas por meio de OR; por isso, procure também regras amplas como using (true).

Revise CORS e CSRF separadamente

O CORS controla como o navegador pode ler uma resposta de outra origem. Ele não é um mecanismo de autenticação ou autorização e não impede o envio de todas as solicitações. Retorne Access-Control-Allow-Origin somente quando o Origin corresponder exatamente à sua lista de permissões. Use Access-Control-Allow-Credentials: true apenas quando cookies forem necessários. Se os cabeçalhos da resposta variarem conforme a origem, envie Vary: Origin para evitar que caches misturem respostas de origens diferentes.

Para solicitações POST, PUT, PATCH e DELETE autenticadas por cookie, use a proteção CSRF do framework ou um padrão comprovado de token CSRF, e valide Origin. Um GET somente leitura não deve alterar o estado. Secure, HttpOnly e uma configuração apropriada de SameSite fortalecem um cookie de sessão, mas geralmente não substituem um token CSRF.

Um endpoint externamente chamado, como um webhook do Stripe, pode ser excluído da verificação normal do token CSRF. Mantenha essa exceção limitada e exija a verificação de assinatura válida do Stripe na rota.

Valide a entrada ao recebê-la e ao exibi-la

Armazenar a string literal <script> não prova por si só uma vulnerabilidade. Valide o comprimento, o tipo, o formato e a faixa no servidor, depois codifique os valores armazenados de acordo com o contexto de saída — HTML, URL, JavaScript ou outro destino.

No staging, envie caracteres especiais, valores muito grandes e valores nos limites permitidos. Verifique que eles permaneçam como texto inerte em todos os lugares onde aparecem. Também verifique que respostas de erro não divulguem SQL, caminhos de arquivos internos ou rastreamentos de pilha.

Teste os pagamentos desde o corpo bruto do webhook até a entrega duplicada

Um usuário pode alterar os valores de preço e quantidade enviados pelo navegador. Recalcule ambos no servidor a partir de um ID de produto confiável e imponha ali as quantidades permitidas. Altere o status do pedido somente depois de validar o webhook do provedor de pagamento, nunca apenas porque o navegador exibiu uma mensagem de sucesso.

A verificação da assinatura do Stripe exige o corpo bruto da solicitação, antes de qualquer parsing ou resserialização, além do cabeçalho Stripe-Signature e do segredo de assinatura daquele endpoint. Confirme que nenhum parser JSON global altere o corpo antes de ele chegar à rota do webhook.

Retorne um 2xx rapidamente depois do mínimo de trabalho síncrono, como verificar a assinatura e inserir a tarefa na fila. Transfira o processamento demorado para uma tarefa assíncrona. Webhooks podem ser entregues mais de uma vez. Registre os valores event.id processados; como eventos separados ainda podem se referir ao mesmo objeto, também inspecione event.type e data.object.id. Use restrições de unicidade e transações no banco de dados para que uma atualização de ordem ou pagamento tenha um único efeito mesmo que execute novamente. Se o servidor repetir uma solicitação POST à API do Stripe, reutilize a mesma chave de idempotência para a mesma operação.

No modo de teste, simule um valor alterado, uma assinatura inválida, o reenvio do mesmo evento, a entrega fora de ordem e uma nova tentativa depois de uma falha no processamento posterior.

Limite ações sensíveis e armazene senhas deliberadamente

Cadastro, login, redefinição de senha, códigos de verificação e APIs pagas precisam de limitação de frequência. Um limite apenas por IP não lida bem com redes compartilhadas ou ataques distribuídos. Projete limites por conta, IP e operação, depois verifique a resposta 429 e a mensagem de erro para o usuário.

Se você precisar armazenar senhas sozinho, a primeira escolha do OWASP é Argon2id. Considere scrypt onde Argon2id não estiver disponível; reserve bcrypt para compatibilidade com sistemas legados. Senhas em texto plano, criptografadas reversivelmente e hashes gerais rápidos não são apropriados. A autenticação gerenciada ainda deixa a autorização da aplicação, a expiração da sessão e as configurações de redirecionamento de login para você revisar.

Mantenha sinais de investigação, não segredos, nos logs

Procure nos consoles do navegador e nos logs do servidor por cabeçalhos Authorization e Cookie, tokens de acesso e de atualização, IDs de sessão, senhas, strings de conexão com o banco de dados, chaves privadas e dados de cartão. Não registre esses valores. Mascare os identificadores ou armazene seu hash quando precisar de uma referência estável. Para dados pessoais, como endereços de e-mail, defina a necessidade operacional, o prazo de retenção e o controle de acesso, e mantenha somente o necessário.

Registre de forma consistente as falhas de autenticação, as negações de autorização, as mudanças de chaves ou permissões e as transições de status dos pagamentos. Horário, resultado e um ID interno de usuário ou solicitação podem formar uma trilha de auditoria sem expor credenciais. Revise quem pode ler os logs e por quanto tempo eles são mantidos.

Repita as mesmas solicitações que falharam após a correção

Um segredo vazado deve ser revogado imediatamente. Mudanças que precisam ser publicadas juntas — RLS, GRANT e código da aplicação, por exemplo — exigem um lançamento mais controlado. Valide o conjunto no staging, documente uma sequência de implantação curta e prepare um caminho para rollback.

Depois da implantação, repita o caso sem login, os testes com as contas A e B, as verificações de CSRF e os fluxos de pagamento concluídos, falhos e duplicados. Passar por toda a lista não prova que o produto esteja livre de vulnerabilidades. Se um serviço público processa dados pessoais ou pagamentos, contrate uma revisão independente com escopo definido.