Платёжная безопасность при вибкодинге: две уязвимости, которые ИИ пропускает всегда

No Habr, foi publicado um artigo prático sobre segurança de pagamentos em produtos construídos com IA: o autor — um vibe coder sem experiência profissional em desenvolvimento — analisou duas vulnerabilidades que o código de redes neurais reproduz de forma garantida e descreveu cinco níveis de proteção que alcançou por conta própria.

Por que o código de IA em pagamentos é mais perigoso do que um bug óbvio

A tese central do artigo: a rede neural não escreve código ruim — ela escreve código que parece funcionar. Esta é uma diferença fundamental. O cenário básico funciona: o usuário clica em "pagar", o dinheiro chega, o teste fica verde. A vulnerabilidade permanece invisível até que um agente mal-intencionado a encontre — não o desenvolvedor.

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

Habr.

É exatamente por isso que o módulo de pagamento é uma zona de risco especial: um erro oculto aqui não significa falha do aplicativo, mas perdas financeiras diretas — do produto ou dos usuários.

Dois buracos que a rede neural reproduz sistematicamente

O autor identifica dois falhos característicos especificamente do código de pagamento gerado por IA:

• Substituição de preço — o servidor aceita o valor do corpo da requisição do cliente sem verificar com o preço real no banco de dados. Um agente mal-intencionado altera o valor no DevTools e paga pelo produto qualquer valor arbitrário — até 1 rublo.
• Ausência de verificação de webhooks — o servidor aceita notificações de pagamento sem verificar a assinatura do sistema de pagamento. Isso permite enviar uma confirmação de transação fictícia e obter acesso ao produto sem um pagamento real.
• Ambos os padrões são reproduzidos regularmente pelos assistentes de IA: nos dados de treinamento, essas verificações frequentemente parecem "detalhes de implementação" e são omitidas.

Segundo o autor, nenhuma dessas vulnerabilidades é fechada automaticamente pela rede neural — é necessário solicitar explicitamente ou verificar manualmente após a geração do código.

Como verificar o produto antes do lançamento

O autor descreve uma técnica concreta: antes de entregar, abrir o produto no modo anônimo — sem tokens salvos, cookies ou autorização — e tentar processar um pagamento com parâmetros de requisição modificados. O objetivo é imitar as ações de um agente mal-intencionado enquanto ainda há tempo para corrigir o código.

Para um vibe coder sem equipe ou code review, essa técnica substitui tanto a auditoria de segurança quanto 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, todos os cinco são omitidos pela IA na primeira geração — sem uma solicitação explícita no prompt ou 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 server-side dos dados de entrada, proteção contra requisições repetidas e auditoria de eventos de pagamento.

O que isso significa

O vibe coding reduziu a barreira de entrada no desenvolvimento, mas não alterou 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 sistematicamente deixa passar a proteção na fronteira entre cliente e servidor. Quem constrói produtos com redes neurais precisa de um checklist explícito para pontos críticos — ou de uma lição cara 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 sistematicamente omitidos: substituição do valor do pagamento no lado do cliente (o servidor aceita o preço da requisição sem verificar com o banco de dados) e ausência de verificação de assinatura do webhook do sistema de pagamento. Ambos permitem realizar uma transação sem um pagamento real.

Como um vibe coder pode verificar a segurança dos pagamentos antes do

lançamento?

O autor recomenda a técnica de sessão limpa: abrir o produto no modo anônimo sem autorização e tentar processar um pagamento com parâmetros modificados. Isso simula as ações de um agente mal-intencionado e permite identificar vulnerabilidades antes de ir para produção — sem equipe ou code review.