Executando verificação de segurança...
Em resposta a Eu estava sendo atacado por bots... então criei minha própria API de antifraude
1
23423526546245634564653456

delegar rate limit para uma api é de uma limitação intelectual bem grande, de fato a unica informação que o cliente não pode manipular é seu ip e fazer o rate limit dependendo do endpoint é função do propio app não precisa de um serviço externo para isso.

Bloquear bots é complexo. rate limit por ip é o minimo, rate limit por sessão autenticada é o minimo, captcha é o minimo.

só criar contas para email de provedores confiaveis @gmail.com é basico, você delega o anti bot pro google. validar email ou usar login com google é basico.

validar numero de telefone começa a ser mais intermadiario. custa dinheiro. mas se sua api usa ia tu vai querer proteger esse recurso.

fazendo o minimo e o basico ja fica dificil de abusaem da sua api se a lógica de negocio fizer sentido

muitas veses o "login com google" é a melhor opção, é transparente para o usuario e ja permite que tu use o reCaptcha mais avançado de graça. (o login com google ja valida que não é um robô e usa o melhor captcha do google que ja valida ip dispositivo comportamento e coisas que você nem sonha que o google sabe dos usuarios)

mesmo depois do login teu app tem que ter limites que fazem sentido, e usar mais captchas se for pra fazer algo sem limite mesmo logado.

Carregando publicação patrocinada...
1
vultus

Faz sentido o que você falou — e eu concordo com quase tudo.

Rate limit básico, login com Google, validação de email/telefone… isso já resolve uma boa parte do problema mesmo.

Mas foi exatamente depois de implementar esse “mínimo bem feito” que eu comecei a ver onde ainda tinha buraco.

Principalmente em dois cenários:

  • APIs públicas (sem autenticação forte)
  • endpoints que precisam ficar abertos (ex: criação de conta, reset de senha, etc)

Nesses casos, mesmo com:

  • rate limit por IP
  • captcha
  • login social

ainda passa bastante coisa:

  • tráfego vindo de datacenter (IPs rotativos)
  • bots que simulam browser (headless)
  • abuso distribuído (não estoura rate limit simples)

A ideia da API não é substituir o básico — é ser uma camada a mais.

Tipo:

  • o app continua com rate limit
  • continua com autenticação
  • continua com captcha

Mas antes de decidir “aceito ou não essa request”, você tem um score:

«“isso aqui parece humano ou não?”»

Sobre “delegar rate limit pra API externa”:

concordo que delegar tudo não faz sentido.

Mas o que estou tentando fazer não é só rate limit — é:

  • comportamento (frequência ao longo do tempo)
  • tipo de IP (datacenter/VPN)
  • padrão de acesso

Sobre login com Google:

isso resolve MUITO bem pra apps fechados.

Mas tem alguns casos onde não encaixa:

  • APIs B2B
  • serviços que precisam aceitar qualquer cliente
  • sistemas onde você não quer forçar login

No fim, minha hipótese é:

«o básico resolve 80%, mas os 20% restantes ainda dão dor dependendo do tipo de sistema»

E é nesses 20% que estou tentando atuar.

Mas esse ponto que você trouxe é exatamente o tipo de feedback que eu queria:

se na prática o “mínimo bem feito” já resolve pra maioria dos casos, talvez minha ideia já não faz sentido, precise focar melhor no nicho certo.

Você já teve problema real com abuso mesmo depois dessas proteções?