Sua aplicação aguenta?
Você desenvolve sua aplicação com todo carinho e vontade, faz o deploy e fica todo orgulhoso de ver o seu trabalho no ar. As pessoas começam usar e parece que está tudo bem. De repente, um usuário malicioso com um simples script, derruba sua aplicação deixando-a indisponível :(
É aí que entra Rate Limit, uma lógica de controle para limitarmos a quantidade de vezes que um usuário pode fazer requisições para nossa aplicação em um determinado período. Aí você me pergunta, e por que eu iria querer limitar as requisições do meu usuário? Afinal, se eu coloquei no ar, é por que eu quero que usem certo? O problema não é usar e sim como usam. Abaixo mostro alguns dos motivos por que ter um Rate Limit.
Negação de Serviço (DoS): Por mais parrudo que seja o servidor onde hospedamos nossa aplicação, ele tem um limite de hardware, RAM, CPU etc. Um usuário malicioso pode fazer um monte de requisições simultâneas e rapidamente consumir todos recursos de hardware do nosso servidor, deixando assim nossa aplicação indisponível. Quando esse ataque é feito por vários dispositivos (bot farm), ele passa se chamar Ataque de Negação de Serviço Distribuído, o famoso DDoS.
Database Spam: Um atacante pode criar milhões de usuários falsos em poucos minutos e estourar o armazenamento do nosso banco de dados.
Brute Force: Outro tipo de ataque bem famoso é o brute force, onde o atacante na tentativa e erro pode conseguir entrar na sua conta tentando milhares de combinações por segundo até encontrar a correta.
Evitar custos excessivos: muitas requisições, por usar muitos recurso do servidor, podem aumentar custos da nossa infraestrutura.
Controlar uso da aplicação: algumas APIs usam rate limit para monetização e controle. Por exemplo, usuários premium podem fazer 1000 req/min, usuários do plano free podem fazer apenas 100 req/min.
E como funciona?
Assim que a requisição chega, pegamos o IP no header da requisição, verificamos o número de requisições já feitas por aquele IP e o tempo de expiração. E de acordo com o contador de requisições nos nossos registros, permitimos a requisição ou não.
Exemplo:
Se contador < limite de req/min, aumenta o contador em +1 e permite a requisição. Se contador >= limite de req/min, interrompe a requisição ali mesmo e devolve o erro 429 – Too many requests.
Muito fácil né? Só que não.
E se o atacante usar uma bot farm para fazer as requisições? dessa maneira cada bot tem seu próprio IP. Então se cada IP pode fazer 100 req/min, 1 milhão de bots fariam 100 milhões req/mim. Aí entra outras estratégias de rate limit, como por exemplo usar API Key ou JWT para identificar não apenas de onde é a requisição, mas também quem está fazendo a requisição.
Rate Limit é um assunto que renderia muitas páginas de conteúdo, então vou parar por aqui mesmo. Poder pesquisar, estudar e aprender mais sobre rate limit, quais os tipos, vantagens e desvantagens de cada um é muito interessante e útil, recomendo.
Conclusão
Rate Limit, serve para segurança, evitar ataques, proteger performance, reduzir custos, impedir spam entre outras coisas. Mas apesar de ajudar muito, não é uma solução completa e sim uma camada extra de proteção, sendo necessário somar com outras soluções, como por exemplo WAF (Web Application Firewall).