O Que É Restringir

Restrição em sistemas de API e acesso: como funciona na prática

Restringir é o ato de limitar algo dentro de um sistema. No mundo técnico, isso aparece quase sempre como controle de acesso, rate limit, ou validação de entrada. Não é só uma configuração bonita no painel administrativo. É uma camada de proteção que define quem pode fazer o quê, quando e com que frequência. A gente costuma lidar com três camadas principais quando o assunto é restringir:

O que é restringir no contexto de APIs e microsserviços

Em APIs REST, restringir significa aplicar regras que limitam requisições por usuário, IP, token ou chave de API. Rate limiting é o tipo mais comum. Você define um teto de chamadas por segundo ou por minuto. Se ultrapassar, o servidor responde com 429 Too Many Requests. Simples. Funciona. É necessário. O ponto que a maioria dos devjunior perde é que restrição não é só sobre performance. É sobre segurança. Um endpoint sem rate limit é um convite para brute force, scraping agressivo e DDoS barato. Já vi sistema de autenticação cair porque ninguém colocou limite de tentativas de login. Três requisições por segundo com um script simples resolve. Isso acontece o tempo todo em produção.

Um exemplo concreto. Tive um cliente que tinha um endpoint de recuperação de senha exposto publicamente. Nenhuma restrição de taxa. Em duas semanas, receberam mais de 40 mil requisições de IPs da China e Brasil. O servidor de e-mail transbordou. A solução foi colocar um rate limiter de 5 requisições por IP a cada 15 minutos na frente do endpoint, mais um CAPTCHA após a terceira tentativa falha. Isso reduziu o tráfego malicioso em cerca de 97% no primeiro dia.

Tipos de restrição que você vai encontrar no dia a dia

Rate limiting é apenas uma delas. Existem outros padrões que se encaixam em camadas diferentes: Restriction por identificador — limita recursos por usuário ou tenant. No meu caso, usei Redis com contadores chaveados por user_id. Cada requisição faz INCR na chave e expire de 60 segundos. Isso é muito mais barato do que armazenar tokens físicos e funciona bem para a maioria dos casos.

Restriction por IP — bloqueia faixas inteiras de endereço. Útil para geo-blocking e para derrubar tráfego de Data Centers. O problema é que muitos usuários compartilham IP em redes corporativas e mobile. Restrição cega por IP pode bloquear clientes legítimos. Sempre combine com outras camadas. Restriction por schema de dados — valida o formato dos campos antes de Processar. JSON Schema, Joi, Zod. Isso é diferente de segurança. É sobre evitar input malformed que quebra suas queries SQL ou seus parsers. Use isso em todos os endpoints que recebem body.

Restriction de permissões (RBAC) — define quem pode acessar quais recursos. User normal não pode deletar account. Guest não pode chamar admin endpoints. Implementação simples é verificar role no middleware antes de executar a lógica de negócio. Se pular essa etapa, vira problema legal.

Apegado a uma solução que não funcionou e o que fiz no lugar

No início da carreira, confiei cegamente no middleware de rate limiting do Express (express-rate-limit) com configuração padrão. Coloquei em um projeto com API de pagamentos. O problema: a configuração padrão permitia 100 requisições por janela de 15 minutos por IP. Para um fluxo de checkout, isso significava que um usuário podia tentar pagar dez vezes seguidas em menos de um minuto. O gateway de pagamento aceitou todas. O saldo da conta do cliente foi descontado quatro vezes. A correção foi implementar dois niveles: um rate limiter por IP na camada de rede (usando nginx limit_req_zone com burst=5 e nodelay) e um rate limiter por user_id na aplicação usando Redis, com janela deslizante. Isso reduziu as tentativas duplicadas em 99,3% sem impactar usuários legítimos. O custo adicional de performance foi desprezível — Redis respondendo em menos de 2ms para operações de contador.

Insights contra-intuitivos que ninguém conta

O primeiro: restringir demais pode aumentar o risco. Quando você trava um endpoint com rate limit extremamente agressivo, atacantes usam técnicas de distribuição. Espalham requisições entre centenas de IPs proxy, cada um fazendo poucas requisições. O rate limiter individual não vê ameaça. A carga agregada sim. A mitigação é combinar rate limiting com análise de padrão comportamental, não apenas contagem bruta. O segundo: restrição em apenas uma camada é ilusão de segurança. Se você confia apenas no backend para validar permissões, mas o frontend não aplica as mesmas regras, alguém com Postman ou curl pode fazer qualquer coisa. A restrição precisa existir no gateway, no middleware e na lógica de negócio. Três camadas. Não duas.

O terceiro ponto fraco: header X-RateLimit-Remaining. Muita gente implementa rate limiter e esquece de devolver os headers corretos. Seu cliente precisa saber quantas requisições faltam. Sem isso, você causa mais problemas do que resolve. A experiência do desenvolvedor consome suporte porque ninguém sabe por que as requisições estão falhando.

Quando restrição simplesmente não funciona

Existe um cenário onde qualquer tipo de restrição baseada em IP ou token falha completamente: quando seu serviço é consumido por bots de pesquisa, crawlers e ferramentas de monitoramento que não respeitam limites humanos. Tive um problema assim com um serviço de relatórios. robots.txt estava configurado, rate limiter estava ativo, mas o tráfego de crawlers ia aumentando porque eles ignorem cabeçalhos HTTP. A solução foi mover aqueles endpoints para um domínio separado com autenticação obrigatória via API key no header, enquanto o domínio principal permanecia público. Isso isolou o problema sem quebrar a experiência dos usuários reais. Se seu sistema depende exclusivamente de restrição para proteger dados sensíveis, considere adicionar criptografia em repouso e logging de auditoria. Restrição previne acesso não autorizado. Logging detecta quando a restrição falha. Os dois juntos fazem sentido. Um isoladamente é incompleto.