Segurança em pagamentos no vibe coding: duas vulnerabilidades que a IA sempre deixa passar

O Habr publicou um artigo prático sobre segurança de pagamentos em produtos criados com ajuda de IA. O autor, um praticante de vibe coding sem experiência profissional em desenvolvimento, analisou duas vulnerabilidades que o código gerado por redes neurais reproduz com certeza e descreveu cinco níveis de proteção a que chegou na própria experiência.

Por que o código de IA em pagamentos é mais perigoso que um bug explícito

A tese central do artigo: a rede neural não escreve código ruim, ela escreve código que parece funcionar. A diferença é fundamental. O cenário básico funciona: o usuário clica em "pagar", o dinheiro entra, o teste fica verde. A vulnerabilidade permanece invisível até o momento em que um invasor a encontra, e não o desenvolvedor.

"O erro mais caro nesse tipo de trabalho não é a rede neural escrever código ruim, e sim ela escrever código que parece funcionar", escreve o autor no artigo do

Habr.

Por isso o módulo de pagamento é uma zona de risco especial: um erro oculto aqui não significa a queda do aplicativo, mas perdas financeiras diretas, para o produto ou para os usuários.

Duas brechas que a rede neural reproduz de forma sistemática

O autor destaca duas falhas típicas do código de pagamento gerado por IA:

• Adulteração de preço: o servidor aceita o valor enviado no corpo da requisição do cliente, sem conferir com o preço real no banco de dados. O invasor altera o valor no DevTools e paga pelo produto a quantia que quiser, até 1 rublo.
• Falta de verificação de webhooks: o servidor aceita notificações de pagamento sem checar a assinatura do sistema de pagamento. Isso permite enviar uma confirmação fictícia de transação e obter acesso ao produto sem pagamento real.
• Os assistentes de IA reproduzem os dois padrões com regularidade: nos dados de treinamento, essas verificações costumam aparecer como "detalhes de implementação" e são omitidas.

Segundo o autor, a rede neural não fecha nenhuma dessas vulnerabilidades automaticamente. É preciso pedi-lo de forma explícita ou conferir manualmente depois que o código é gerado.

Como testar o produto antes do lançamento

O autor descreve uma técnica concreta: antes de entregar o produto, abri-lo em modo anônimo, sem tokens, cookies e autenticação salvos, e tentar fazer um pagamento com parâmetros de requisição alterados. O objetivo é simular as ações de um invasor enquanto ainda há tempo de corrigir o código.

Para o praticante de vibe coding que trabalha sem equipe e sem code review, essa técnica substitui ao mesmo tempo a auditoria de segurança e os testes: a única barreira real é o próprio olhar do ponto de vista do atacante.

Cinco níveis de proteção

O artigo descreve cinco níveis de proteção do módulo de pagamento que o autor desenvolveu na prática. Segundo ele, a IA ignora os cinco na primeira geração: sem um pedido explícito no prompt ou uma verificação manual, eles não estarão no código. Os detalhes de cada nível estão no texto completo. De acordo com o artigo, eles cobrem a validação dos dados recebidos no servidor, a proteção contra requisições repetidas e a auditoria dos eventos de pagamento.

O que isso significa

O vibe coding reduziu a barreira de entrada no desenvolvimento, mas não mudou os requisitos de segurança que o mundo real impõe a produtos com pagamentos. A IA gera com confiança a lógica básica dos fluxos, mas ignora de forma sistemática a proteção na fronteira entre cliente e servidor. Quem constrói produtos com redes neurais precisa de um checklist explícito para os pontos críticos, ou vai pagar caro por uma lição em produção.

Perguntas frequentes

Quais vulnerabilidades a rede neural deixa passar no código de pagamento?

Segundo o autor do artigo no Habr, dois padrões são omitidos de forma sistemática: a adulteração do valor do pagamento no lado do cliente (o servidor aceita o preço da requisição sem conferir com o banco de dados) e a falta de verificação da assinatura do webhook do sistema de pagamento. Ambos permitem concluir uma transação sem pagamento real.

Como o praticante de vibe coding pode verificar a segurança dos

pagamentos antes do lançamento?

O autor recomenda a técnica da sessão limpa: abrir o produto em modo anônimo, sem autenticação, e tentar fazer um pagamento com parâmetros alterados. Isso simula as ações de um invasor e permite identificar a vulnerabilidade antes de ir para produção, sem equipe e sem code review.