Agentes que pagam APIs precisam de autorização, não só de uma carteira

Uma revisão da V12 encontrou 25 problemas no x402, incluindo três classificados pela empresa como críticos e corrigidos em versões de 18 de agosto.[6] A reportagem destaca que faltava comunicação específica de segurança e que verificações de npm e PyPI não alertavam para as últimas versões anteriores aos ajustes.[6] Um resultado limpo no scanner, portanto, não encerrava a avaliação desse caso.

O que muda para quem desenvolve

O primeiro problema envolvia clientes configurados para assinar pagamentos automaticamente sem orçamento definido pela aplicação: uma API maliciosa poderia solicitar até o saldo inteiro de um token suportado.[6] As correções adicionaram controles que limitam por padrão cada pagamento a US$ 1 e restringem tokens a stablecoins em dólar reconhecidas pelo SDK.[6]

Minha leitura é que um limite por operação resolve apenas uma parte da autorização. Um produto precisa decidir também quanto pode gastar no total, durante quanto tempo e com quais destinatários. Não delegue essas decisões ao texto retornado pela API que receberá o dinheiro.

O segundo problema permitia ao SDK TypeScript aceitar, em Solana, uma transação sem transferência de tokens.[6] O terceiro envolvia SIWx: um servidor poderia encaminhar uma mensagem de login de outro site e obter a assinatura da carteira para aquele destino.[6] São fronteiras distintas: comprovar pagamento e comprovar a identidade do serviço que solicita autenticação.

Como aplicar

Proponho três testes de contrato em ambiente isolado, com carteiras de teste e sem dinheiro real:

1. Um servidor solicita valor acima do orçamento por operação. A assinatura deve ser recusada.
2. Várias solicitações pequenas ultrapassam o orçamento acumulado. O conjunto deve ser bloqueado.
3. Uma mensagem de login declara origem diferente da resposta recebida. Nenhuma assinatura deve ser produzida.

Acrescente um teste no facilitador para garantir que uma transação sem a transferência esperada não libere o recurso pago.

Na chamada direta a createSIWxPayload em TypeScript, a correção exige fornecer a URL da resposta após redirecionamentos; os wrappers de fetch e axios fazem esse encaminhamento.[6] Revise o caminho efetivamente utilizado, em vez de assumir que todo uso do SDK percorre o wrapper.

Cuidados e limites

A reportagem identifica a proteção de validação Solana em @x402/svm a partir de 2.23.0 e sua ausência entre 2.0.0 e 2.22.0.[6] Não extrapole essa faixa para todos os problemas ou linguagens.

Não havia ataques públicos reportados pela V12 ou pela fundação mantenedora.[6] A resposta adequada é corrigir e testar os controles, preservando essa distinção entre vulnerabilidade demonstrada e prejuízo observado.

Fonte

[6] Fonte: The Hacker News