[BUG] Endpoint CNPJ retorna 403 (x-vercel-mitigated: deny) para o User-Agent padrão do Node ("node")

Descrição

O endpoint GET /api/cnpj/v1/:cnpj retorna 403 Forbidden quando a requisição é feita com o User-Agent padrão do fetch/undici do Node.js (node). Isso quebra consultas a partir de funções serverless (no nosso caso, funções Node em produção na Vercel), enquanto a mesma consulta funciona normalmente a partir do curl/navegador local.

A causa não é o CNPJ, nem rate limit, nem dados — é puramente o User-Agent da requisição.

Quem bloqueia

A resposta 403 vem do edge da própria BrasilAPI (hospedada na Vercel, com Cloudflare como CDN na frente). O header de resposta confirma que é a mitigação de bot da Vercel:

x-vercel-mitigated: deny
server: cloudflare

Reprodução

Testado contra um CNPJ válido (46333915000110), determinístico, 5/5 em cada caso:

# 403
curl -s -o /dev/null -w "%{http_code}\n" -A "node" \
  https://brasilapi.com.br/api/cnpj/v1/46333915000110
# 200
curl -s -o /dev/null -w "%{http_code}\n" -A "meu-app/1.0" \
  https://brasilapi.com.br/api/cnpj/v1/46333915000110

Impacto

Qualquer cliente Node usando o fetch global (undici) sem definir um User-Agent explícito recebe 403 em produção. Como o UA padrão do undici é interpretado como bot, integrações serverless quebram de forma silenciosa e difícil de diagnosticar (o 403 não distingue de outros erros).

Relacionado

Mesmo mecanismo já relatado em #339 (2021, na época via Cloudflare): requisições feitas diretamente pelo node eram bloqueadas. Hoje o bloqueio aparece como x-vercel-mitigated: deny.

Sugestões

• Documentar que um User-Agent explícito é necessário, ou
• Ajustar a regra de mitigação para não tratar o UA padrão do Node como bot no endpoint público.

Workaround atual

Definir um User-Agent explícito na requisição resolve o 403.