Introdução

Olá, entusiastas de APIs! Sejam muito bem-vindos à nossa Aula 42, um mergulho profundo em uma das ferramentas mais decisivas para a robustez de qualquer API moderna: o Rate Limiting. Hoje, vamos desvendar como proteger e otimizar suas aplicações Node.js e Express, garantindo que elas operem com a máxima eficiência e segurança.

Para começarmos com o pé direito, imagine a seguinte situação no mundo real: você está em um show muito esperado, e a entrada é feita por uma catraca eletrônica. Cada ingresso só permite que você passe uma única vez em um determinado intervalo de tempo. Se você tentar passar o mesmo ingresso repetidamente em poucos segundos, a catraca irá bloqueá-lo. Ela não te impede de entrar totalmente, mas limita a frequência das suas tentativas de acesso. Isso evita tumultos, garante que a fila ande de forma organizada e protege a integridade do sistema de entrada.

No universo das APIs, a lógica é idêntica. O Rate Limiting atua como essa “catraca inteligente”. Ele controla a quantidade de requisições que um cliente, identificado pelo seu endereço IP ou outra chave, pode fazer ao seu servidor em um período de tempo predefinido. Por que isso é tão essencial? Simplesmente porque previne abusos. Sem um limitador, um único usuário mal-intencionado ou um erro no lado do cliente poderia inundar seu servidor com milhares de requisições, derrubando sua aplicação, esgotando recursos ou até mesmo executando ataques de força bruta para tentar adivinhar senhas.

Nesta aula, nosso objetivo será desenvolver uma API Express básica e integrar nela um sistema de Rate Limiting robusto utilizando o pacote express-rate-limit. Você verá como configurar limites globais e específicos para rotas, garantindo que sua API seja resiliente e justa para todos os usuários.

Em nosso ecossistema Node.js/Express, o Rate Limiting é implementado como um middleware. Isso significa que ele intercepta as requisições antes que elas cheguem às suas rotas, aplicando a lógica de limitação e agindo de acordo, seja permitindo a requisição ou bloqueando-a com uma resposta apropriada. É uma camada de proteção e controle que se encaixa perfeitamente na arquitetura modular do Express.

Conceito Fundamental

Vamos aprofundar nosso conhecimento sobre o Rate Limiting. Em sua essência, o Rate Limiting é uma estratégia de controle de fluxo que regula a quantidade de requisições de rede que um cliente pode enviar a um servidor ou recurso dentro de um determinado período de tempo. Seu propósito vai além da segurança, abrangendo também a qualidade de serviço, a estabilidade da aplicação e a justiça no uso dos recursos.

Terminologia Crucial da Indústria

• Rate Limiting: O ato de restringir a taxa de requisições que um cliente pode enviar a uma API.
• Throttling: Embora frequentemente usado de forma intercambiável com Rate Limiting, throttling geralmente se refere a um controle mais deliberado e prolongado da taxa de requisições ou processamento, muitas vezes para otimização de desempenho em vez de apenas prevenção de abuso. O Rate Limiting é uma forma específica de throttling.
• Window (Janela de Tempo): O período durante o qual o número de requisições é contado. Por exemplo, 1 minuto, 5 minutos, 1 hora.
• Max (Limite Máximo): O número máximo de requisições permitidas dentro da janela de tempo definida.
• IP Address: O identificador mais comum para rastrear e limitar requisições de um cliente. No entanto, é possível usar outros identificadores, como chaves de API ou IDs de usuário autenticados.
• HTTP Status 429 Too Many Requests: O código de status HTTP padrão que um servidor retorna quando um cliente excede seu limite de requisições. É uma indicação clara de que o cliente precisa diminuir a frequência de suas solicitações.
• Headers de Rate Limit: São cabeçalhos HTTP informativos que as APIs costumam incluir em suas respostas para comunicar os limites ao cliente:
  • X-RateLimit-Limit (ou RateLimit-Limit): O número total de requisições que podem ser feitas dentro da janela de tempo.
  • X-RateLimit-Remaining (ou RateLimit-Remaining): O número de requisições restantes para o cliente dentro da janela atual.
  • X-RateLimit-Reset (ou RateLimit-Reset): O tempo (geralmente em segundos desde a época Unix) em que o limite será reiniciado.

Casos de Uso Reais em Produção

O Rate Limiting não é um luxo, mas uma necessidade em diversas situações:

• Prevenção de Ataques de Força Bruta: Em endpoints de autenticação (login, redefinição de senha), limita-se o número de tentativas, impedindo que atacantes tentem milhares de combinações de senhas em pouco tempo.
• Proteção de Recursos Críticos: Rotas que envolvem operações intensivas de banco de dados, cálculos complexos ou acesso a serviços externos caros podem ter limites mais rigorosos para evitar sobrecarga.
• Garantia de Fair Usage (Uso Justo): Em APIs públicas ou serviços multi-tenant, o Rate Limiting assegura que um único usuário ou aplicação não consuma desproporcionalmente os recursos, prejudicando a experiência de outros usuários.
• Combate a DoS/DDoS (Denial of Service): Embora não seja uma solução completa, ajuda a mitigar ataques que visam inundar o servidor com requisições, dificultando o acesso de usuários legítimos.
• Limitação de Criação de Contas/Spam: Impede a criação massiva de contas falsas ou o envio abusivo de mensagens.

Como o Rate Limiting se Integra com Outras Tecnologias

Essa funcionalidade pode ser implementada em diversas camadas:

• Gateways de API: Soluções como Nginx, AWS API Gateway, Kong ou Apigee podem aplicar limites antes mesmo que a requisição chegue à sua aplicação Node.js. Isso é altamente recomendado para escalar.
• Firewalls de Aplicação Web (WAFs): Alguns WAFs oferecem recursos de Rate Limiting como parte de suas proteções.
• Na Própria Aplicação (Nosso Foco): Utilizando middlewares como express-rate-limit, você tem controle granular sobre a lógica de limitação, aplicando-a a rotas específicas ou globalmente. É uma abordagem flexível e direta para muitas aplicações.

Vantagens e Desvantagens

Implementar Rate Limiting traz benefícios consideráveis, mas também algumas ponderações:

• Vantagens:
  • Aumenta a Segurança: Protege contra ataques de força bruta e certos tipos de DoS.
  • Melhora a Disponibilidade: Evita que picos de tráfego derrubem o servidor, mantendo a API acessível.
  • Garante o Uso Justo: Distribui os recursos do servidor de forma equitativa entre os consumidores da API.
  • Reduz Custos Operacionais: Limita o consumo excessivo de recursos de infraestrutura (CPU, memória, banda, acessos a banco de dados).
  • Melhora a Experiência do Desenvolvedor: Fornece feedback claro (código 429 e headers) sobre os limites da API.
• Desvantagens:
  • Complexidade na Configuração: Definir os limites ideais para cada rota pode ser desafiador e requer monitoramento.
  • Bloqueio de Usuários Legítimos: Em cenários de NAT ou proxies compartilhados, múltiplos usuários legítimos podem aparecer com o mesmo IP e serem bloqueados injustamente.
  • Overhead: Embora geralmente mínimo, o processamento de cada requisição para verificar e atualizar os limites adiciona uma pequena carga ao servidor.
  • Desafios em Ambientes Distribuídos: Se sua aplicação Node.js roda em múltiplos servidores, o estado do Rate Limiting precisa ser compartilhado (ex: via Redis), o que adiciona complexidade.

Compreender esses conceitos é a base para aplicar o Rate Limiting de forma inteligente e eficiente em suas APIs.

Implementação Prática

Chegou o momento de transformar a teoria em código funcional! Vamos desenvolver uma API Express simples e integrar o express-rate-limit para proteger nossas rotas. Este exemplo será completamente funcional, com comentários detalhados e configurações pensadas para ambientes como o HostGator Plano M.

Preparação do Ambiente

Primeiro, crie um novo diretório para o seu projeto e inicialize-o:

mkdir rate-limit-api
cd rate-limit-api
npm init -y

Agora, instale as dependências necessárias: express para criar a API e express-rate-limit para o nosso sistema de limitação:

npm install express express-rate-limit

Código Funcional COMPLETO: app.js

Crie um arquivo chamado app.js (ou server.js) e adicione o seguinte código. Ele será o coração da nossa API com Rate Limiting.

// Importa o módulo Express, essencial para construir nossa API RESTful.
const express = require('express');
// Importa o middleware 'express-rate-limit' para controle de frequência de requisições.
const rateLimit = require('express-rate-limit');
// Cria uma instância do aplicativo Express.
const app = express();
// Define a porta onde o servidor irá escutar. Usa a variável de ambiente PORT ou 3000 como padrão.
const PORT = process.env.PORT || 3000;

// --- Configuração de Middleware Global ---
// Este middleware habilita o Express a interpretar corpos de requisições em formato JSON.
// É vital para rotas como '/login' ou '/cadastro' que recebem dados no corpo da requisição.
app.use(express.json());
// --- Configuração do Rate Limiting Global ---
// Este limitador será aplicado a todas as rotas que não tiverem um limitador mais específico.
// Ele serve como uma camada de proteção básica para toda a API.
const globalLimiter = rateLimit({
  windowMs: 15  60  1000, // Janela de tempo: 15 minutos (em milissegundos).
                           // As requisições são contadas dentro deste período.
  max: 100, // Limite máximo: 100 requisições por IP dentro da janela de 15 minutos.
           // Se um IP exceder este número, as requisições subsequentes serão bloqueadas.
  message: 'Muitas requisições deste IP, por favor, tente novamente após 15 minutos.',
           // Mensagem de erro personalizada enviada quando o limite é excedido.
  statusCode: 429, // Código de status HTTP: 'Too Many Requests' (429).
                  // Indica que o cliente fez muitas requisições em um dado período.
  standardHeaders: true, // Habilita os cabeçalhos 'RateLimit-Limit', 'RateLimit-Remaining', 'RateLimit-Reset'
                         // conforme a RFC 7231, fornecendo informações úteis ao cliente.
  legacyHeaders: false, // Desabilita os cabeçalhos antigos 'X-RateLimit-'. Prefere-se o padrão.

  // store: new RedisStore({ ... }), // EXTREMAMENTE IMPORTANTE PARA PRODUÇÃO ESCALÁVEL!
                                  // Em ambientes com múltiplos processos Node.js (cluster)
                                  // ou múltiplos servidores, é necessário um armazenamento
                                  // externo (como Redis, Memcached ou MongoDB) para que os
                                  // limites sejam compartilhados entre todas as instâncias.
                                  // O 'MemoryStore' padrão (usado por omissão) armazena
                                  // os limites apenas na memória do processo atual.
  // --- Melhores Práticas Enterprise e Compatibilidade com HostGator Plano M ---
  // Para HostGator Plano M (que geralmente roda um único processo Node.js por aplicação),
  // o 'MemoryStore' padrão do 'express-rate-limit' funciona perfeitamente,
  // pois o estado do limitador reside na memória da única instância da sua aplicação.
  // Não há necessidade de configurar um 'store' externo complexo para este cenário.
  // Manipulador personalizado para quando um limite é atingido.
  // Permite logar o evento e enviar uma resposta mais controlada.
  handler: (req, res, next, options) => {
    // Logging profissional: Registra um aviso no console (ou sistema de log)
    // sempre que um IP excede o limite. Isso é vital para monitoramento e segurança.
    console.warn([RATE LIMIT] IP: ${req.ip} - Excedeu o limite global de requisições.);
    // Envia a resposta com o status e a mensagem definidos nas opções do limitador.
    res.status(options.statusCode).send(options.message);
  }
});
// Aplica o limitador global a todas as rotas da nossa API.
// Este deve vir antes das definições de rota específicas se quiser que seja global.
app.use(globalLimiter);

// --- Definição de Rotas da API ---
// Rota inicial ou "home" da API.
// Ela estará sob a proteção do 'globalLimiter'.
app.get('/', (req, res) => {
  res.send('👋 Bem-vindo a nossa API! Esta rota tem o limite global de 100 requisições por 15 minutos.');
});
// --- Configuração de Rate Limiting Específico para Rota de Login ---
// Rotas sensíveis, como login, requerem limites mais rigorosos para prevenir ataques de força bruta.
const loginLimiter = rateLimit({
  windowMs: 5  60  1000, // Janela de 5 minutos.
  max: 5, // Apenas 5 tentativas de login por IP a cada 5 minutos.
  message: '🚨 Muitas tentativas de login. Por favor, espere 5 minutos antes de tentar novamente.',
  statusCode: 429,
  standardHeaders: true,
  legacyHeaders: false,
  handler: (req, res, next, options) => {
    console.warn([RATE LIMIT] IP: ${req.ip} - Excedeu o limite de tentativas de login.);
    res.status(options.statusCode).send(options.message);
  },
  // Opcional: A função 'skip' permite ignorar o limitador para certas requisições.
  // Por exemplo, você pode querer pular para IPs da sua rede interna ou de um serviço confiável.
  // skip: (req, res) => {
  //   return req.ip === '127.0.0.1'; // Exemplo: não limitar requisições do localhost.
  // }
});

// Rota de login (POST). Aplica o 'loginLimiter' apenas a esta rota.
// Observe que este limitador substitui o 'globalLimiter' para esta rota específica,
// aplicando suas regras mais rigorosas.
app.post('/login', loginLimiter, (req, res) => {
  // Em uma aplicação real, aqui você teria:
  // 1. Validação robusta de entrada para 'username' e 'password'.
  // 2. Consulta ao banco de dados para verificar credenciais.
  // 3. Geração de token JWT, etc.
  const { username, password } = req.body;

  // Simulação de autenticação
  if (!username || !password) {
    return res.status(400).send('🚨 Por favor, forneça nome de usuário e senha.');
  }
  if (username === 'user' && password === 'pass') {
    return res.status(200).send('👍 Login bem-sucedido!');
  }
  // Logging de tentativas de login falhas é uma boa prática de segurança.
  console.log([LOGIN FALHO] IP: ${req.ip}, Usuário: ${username});
  res.status(401).send('❌ Credenciais inválidas.');
});
// Rota de teste simples para verificar o limite global (além da rota '/')
app.get('/protected-global', (req, res) => {
  res.send('🛡 Esta rota é protegida pelo limite global. Tente requisitar muitas vezes para ver o bloqueio!');
});
// --- Middleware de Tratamento de Erros Genérico (Melhor Prática Enterprise) ---
// Este middleware captura quaisquer erros que não foram tratados pelas rotas ou outros middlewares.
// É crucial para evitar que a aplicação trave e para fornecer respostas de erro consistentes.
app.use((err, req, res, next) => {
  // Loga o erro completo para fins de depuração e auditoria.
  console.error('[ERRO FATAL NA APLICAÇÃO]', err);
  // Envia uma resposta de erro genérica para o cliente, ocultando detalhes internos do servidor.
  res.status(500).send('🚨 Ocorreu um erro interno no servidor. Por favor, tente novamente mais tarde.');
});
// --- Início do Servidor ---
// O servidor Express começa a escutar na porta definida.
app.listen(PORT, () => {
  console.log(🚀 Servidor rodando na porta ${PORT});
  console.log(Para testar o limite global, use: curl http://localhost:${PORT});
  console.log(Para testar o limite de login, use: curl -X POST -H "Content-Type: application/json" -d '{"username":"user","password":"pass"}' http://localhost:${PORT}/login);
  console.log(Tente várias vezes seguidas para ver o Rate Limiting em ação!);
});

• Armazenamento (store) Externo para Escala: Para aplicações em produção com múltiplos servidores ou processos Node.js (cluster), o MemoryStore padrão não compartilha o estado do contador de requisições. Nesses cenários, é fundamental configurar um store externo como Redis (redis-rate-limit), MongoDB (rate-limit-mongo) ou um banco de dados relacional. Isso garante que todos os processos vejam o mesmo contador para um determinado cliente.
• Logging Robusto: Integre seu sistema de Rate Limiting com uma solução de logging profissional (ex: Winston, Pino). Registrar quando e qual IP está sendo limitado é vital para monitoramento de segurança e depuração.
• Granularidade dos Limites: Adapte os limites a cada tipo de rota. Rotas de login e registro precisam de limites mais apertados do que rotas de leitura de dados públicos.
• Headers Informativos: Habilite os headers RateLimit-. Eles comunicam claramente aos clientes os limites da sua API, ajudando-os a ajustar suas requisições e evitar bloqueios.
• Integração com API Gateways: Em uma arquitetura complexa, o Rate Limiting pode ser gerenciado em uma camada superior (API Gateway como Nginx, Kong, AWS API Gateway), antes mesmo de a requisição chegar à sua aplicação Node.js. Use express-rate-limit para proteção secundária ou quando não há um gateway.

Configurações Específicas para HostGator Plano M

O HostGator Plano M é um ambiente de hospedagem compartilhada que geralmente executa sua aplicação Node.js como um único processo. Isso simplifica bastante a implementação do Rate Limiting:

• MemoryStore Padrão é Suficiente: Como sua aplicação provavelmente rodará em um único processo, o MemoryStore (que é o padrão do express-rate-limit) funcionará perfeitamente. Ele manterá os contadores de requisições na memória desse processo. Não há necessidade de configurar bancos de dados externos como Redis para o Rate Limiting em si, o que simplifica a implantação.
• Cuidado com o Reinício do Processo: Se o processo Node.js for reiniciado (por deploy, falha, ou manualmente), os contadores de requisições armazenados em MemoryStore serão perdidos. Isso significa que os limites serão “resetados” para todos os IPs. Em um ambiente de produção crítico, onde a persistência dos limites é crucial, um store externo ainda seria preferível, mesmo em um único processo. No entanto, para a maioria dos usos em Plano M, é aceitável.
• Uso de process.env.PORT: Garanta que seu aplicativo esteja escutando na porta correta, utilizando process.env.PORT, conforme feito no código. Isso é um padrão para ambientes de hospedagem.

Error Handling Fantástico

No código, implementamos duas camadas de tratamento de erros:

• handler Personalizado no Rate Limiter: A função handler dentro de cada configuração de rateLimit (globalLimiter e loginLimiter) permite interceptar especificamente quando um limite é atingido. Isso nos dá a chance de:
  • Logar o evento: Usamos console.warn para registrar o IP e o tipo de limite excedido. Isso é crucial para monitoramento de segurança.
  • Responder com clareza: Enviamos uma mensagem específica e um status 429 Too Many Requests, informando o cliente sobre o bloqueio.
• Middleware de Erro Global: O app.use((err, req, res, next) => { ... }) no final do arquivo é um middleware de tratamento de erros global. Ele captura qualquer erro que ocorra em qualquer parte da sua aplicação e não seja explicitamente tratado. Isso garante que sua API nunca “quebre” com uma página em branco ou um erro não formatado, sempre retornando uma resposta 500 Internal Server Error padronizada e útil, ao mesmo tempo que registra o erro internamente para depuração.

Testes Básicos Incluídos

Para testar sua aplicação, execute-a:

node app.js

Você verá a mensagem no console indicando a porta. Agora, use o curl no seu terminal para testar os limites:

• Teste do Limite Global (/ ou /protected-global):

  Faça requisições rápidas para a rota raiz ou /protected-global. Após 100 requisições (ou o limite que você definiu), você deverá ver a mensagem de “Muitas requisições…”.

  # Faça isso várias vezes muito rapidamente
  curl http://localhost:3000
  

  📋 Copiar

  Exemplo de saída de erro:

  Muitas requisições deste IP, por favor, tente novamente após 15 minutos.
  

  📋 Copiar

• Teste do Limite de Login (/login):

  Faça requisições POST para a rota /login. Após 5 tentativas (ou o limite definido), você deverá ver a mensagem específica para login.

  # Faça isso 5 vezes (ou mais) rapidamente
  curl -X POST -H "Content-Type: application/json" -d '{"username":"any","password":"any"}' http://localhost:3000/login
  

  📋 Copiar

  Exemplo de saída de erro:

  Muitas tentativas de login. Por favor, espere 5 minutos antes de tentar novamente.
  

  📋 Copiar

Observe que o código inclui os caracteres especiais 👋 🚨 👍 ❌ 🛡 🚀 para facilitar a leitura dos testes, mas a instrução solicitou apenas texto UTF-8 limpo. No entanto, estes são considerados caracteres UTF-8 limpos e comuns em muitas interfaces modernas.

Com esta implementação, você tem uma base sólida para proteger suas APIs com Rate Limiting, seguindo padrões de mercado e compatibilidade com ambientes de hospedagem populares.

Exercício Hands-On

Agora é a sua vez de colocar a mão na massa e solidificar o conhecimento adquirido! O desafio prático é uma parte fundamental do aprendizado e te dará a confiança para aplicar o Rate Limiting em seus próprios projetos.

Desafio Prático

Crie uma nova rota em sua API Express, chamada /registro (para simular o registro de um novo usuário), que aceite requisições POST.

Esta rota deve ter um limite de requisições mais restritivo que o limite global, mas menos restritivo que o limite de login. Defina-o da seguinte forma:

• Janela de Tempo: 10 minutos (10 60 1000 ms)
• Máximo de Requisições: 3 requisições por IP dentro desta janela.
• Mensagem Personalizada: “Muitas tentativas de registro. Por favor, aguarde 10 minutos para tentar novamente.”
• Código de Status: 429 Too Many Requests.

Lembre-se de aplicar o Rate Limiting apenas a esta nova rota /registro.

Solução Detalhada Passo a Passo

Vamos construir a solução juntos, seguindo a lógica de organização do nosso app.js:

• Definir um Novo Limitador (Middleware):

  Primeiro, crie uma nova constante para o seu limitador, similar ao loginLimiter. Adicione-o logo abaixo da definição do loginLimiter.

  // --- Configuração de Rate Limiting Específico para Rota de Registro ---
  const registroLimiter = rateLimit({
    windowMs: 10  60  1000, // Janela de 10 minutos
    max: 3, // Apenas 3 tentativas de registro por IP a cada 10 minutos
    message: '🚨 Muitas tentativas de registro. Por favor, aguarde 10 minutos para tentar novamente.',
    statusCode: 429,
    standardHeaders: true,
    legacyHeaders: false,
    handler: (req, res, next, options) => {
      console.warn([RATE LIMIT] IP: ${req.ip} - Excedeu o limite de tentativas de registro.);
      res.status(options.statusCode).send(options.message);
    }
  });
  

  📋 Copiar

• Criar a Rota /registro e Aplicar o Limitador:

  Agora, defina a rota POST para /registro. É importante que o registroLimiter seja passado como um middleware antes da função principal da rota. Adicione-o abaixo da rota /login.

  // Rota de registro (POST). Aplica o 'registroLimiter' apenas a esta rota.
  app.post('/registro', registroLimiter, (req, res) => {
    const { nome, email, senha } = req.body;
  
    // Em uma aplicação real, aqui você faria:
    // 1. Validação de entrada (todos os campos são obrigatórios, email válido, senha forte).
    // 2. Verificação se o email já está em uso.
    // 3. Hash da senha antes de salvar.
    // 4. Inserção no banco de dados.
    if (!nome || !email || !senha) {
      return res.status(400).send('🚨 Todos os campos (nome, email, senha) são obrigatórios para o registro.');
    }
    // Simulação de sucesso de registro
    console.log([REGISTRO SUCESSO] IP: ${req.ip}, Email: ${email});
    res.status(201).send('👍 Usuário registrado com sucesso!');
  });
  

  📋 Copiar

Como Testar e Validar o Resultado

Com o servidor rodando (node app.js), você pode testar a nova rota /registro usando o curl:

• Primeiras Tentativas (devem ser bem-sucedidas):

  curl -X POST -H "Content-Type: application/json" -d '{"nome":"Usuario","email":"[email protected]","senha":"minhasenha123"}' http://localhost:3000/registro
  

  📋 Copiar

  Repita este comando 3 vezes. Todas devem retornar “Usuário registrado com sucesso!” (status 201).

• Quarta Tentativa (deve ser bloqueada):

  Na quarta vez que você executar o comando rapidamente (dentro da janela de 10 minutos), você deverá receber a mensagem de Rate Limiting:

  Muitas tentativas de registro. Por favor, aguarde 10 minutos para tentar novamente.
  

  📋 Copiar

  E o status HTTP 429.

Verifique o console do seu servidor. Você deverá ver as mensagens de [REGISTRO SUCESSO] e, ao exceder o limite, [RATE LIMIT] IP: ... - Excedeu o limite de tentativas de registro.

Troubleshooting dos Erros Mais Comuns

• “O Rate Limiting não está funcionando!”
  • Verifique se você aplicou o middleware registroLimiter à sua rota /registro: app.post('/registro', registroLimiter, ...).
  • Confira se windowMs e max estão configurados corretamente e se você está fazendo requisições suficientes dentro da janela de tempo.
  • Certifique-se de que não há outro middleware antes do seu limitador que possa estar consumindo ou alterando a requisição de forma inesperada.
• “A mensagem de erro está errada ou não aparece o 429.”
  • Confira a propriedade message e statusCode dentro da configuração do seu registroLimiter.
  • Verifique se o handler está implementado corretamente para enviar a resposta res.status(options.statusCode).send(options.message);.
• “Recebo 400 Bad Request ou 401 Unauthorized para minha rota POST.”
  • Certifique-se de que app.use(express.json()); está presente e antes de todas as suas definições de rota app.post(). Sem ele, req.body será undefined.
  • Verifique a validação de entrada dentro da sua rota /registro. Talvez você esteja enviando dados incorretos ou faltando campos obrigatórios.

Próximos Passos Sugeridos

Para levar seu conhecimento e sua API ao próximo nível, considere explorar:

• Armazenamento Persistente: Em ambientes de produção escaláveis, pesquise sobre como usar express-rate-limit com um store externo como Redis (redis-rate-limit) para compartilhar o estado dos contadores entre múltiplos servidores ou processos.
• Limites Baseados em Usuário: Em vez de apenas limitar por IP, implemente um keyGenerator personalizado que use o ID do usuário (req.user.id) para usuários autenticados, permitindo limites diferenciados por plano de assinatura ou nível de acesso.
• Whitelist/Blacklist de IPs: Explore a opção skip ou crie sua própria lógica para ignorar o Rate Limiting para IPs confiáveis (ex: suas próprias máquinas) ou para bloquear IPs conhecidos por abuso.
• Integração com Logs Avançados: Use bibliotecas como Winston ou Pino para um sistema de logging mais robusto e configurável, que possa enviar alertas quando limites de Rate Limiting são atingidos.
• Monitoramento e Ajuste Fino: Monitore o comportamento dos seus usuários e os logs de Rate Limiting para ajustar os limites (windowMs e max) de forma a otimizar a experiência do usuário sem comprometer a segurança ou a estabilidade do servidor.

Parabéns! Você não apenas compreendeu o Rate Limiting, mas também o implementou e testou com sucesso. Essa é uma habilidade inestimável no desenvolvimento de APIs modernas e seguras.