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?