Quem administra um site de vendas, uma plataforma de jogos ou até mesmo uma loja de e-commerce afiliada da Amazon sabe: sem sistemas de defesa — como rate limits, WAFs e balanceadores de carga — nenhum serviço fica online por muito tempo. Mas o que acontece quando essas proteções, essenciais num ataque DDoS, continuam ativas depois que a ameaça passa? Foi exatamente esse “tiro que saiu pela culatra” que o GitHub identificou e resolveu no início de 2026, oferecendo um case que vale ouro para qualquer profissional de infraestrutura ou desenvolvedor que hospeda APIs na nuvem.
O problema: bloqueio silencioso de usuários legítimos
Durante incidentes de abuso, a equipe do GitHub adicionou regras emergenciais em vários níveis da pilha — da borda (HAProxy) até a aplicação Ruby on Rails. Meses depois, essas mesmas regras ainda estavam lá, bloqueando solicitações genuínas, principalmente de visitantes deslogados. O impacto, segundo a empresa, parecia pequeno: apenas 0,003 % a 0,004 % do tráfego total. Contudo, na escala de bilhões de requisições diárias do GitHub, isso significava milhares de devs recebendo a temida mensagem “Too Many Requests”.
Por que isso acontece?
Na pressa de conter um ataque, é comum adotar padrões de fingerprinting mais amplos — combinação de IP, user-agent, ASN, padrões de navegação, etc. Se o atacante muda de estratégia ou se novos serviços legítimos passam a usar padrões semelhantes, a regra “coringa” vira um falso positivo.
Se você administra um site WordPress, um servidor de jogos ou mesmo um blog de reviews de mouses e teclados gamer, o cenário é parecido: aquele filtro de IP ou limite de 100 requisições/minuto criado em 2022 pode estar derrubando o seu tráfego orgânico sem que você perceba.
Como o GitHub encontrou a raiz do erro
A investigação exigiu rastrear logs distribuídos em camadas distintas:
- Relatos de usuários com horário aproximado do bloqueio.
- Logs de borda (HAProxy) para confirmar chegada do tráfego.
- Logs de aplicação, revelando a resposta HTTP 429.
- Análise das regras de proteção que coincidiam com esses eventos.
Resumindo, foi um quebra-cabeça de observabilidade. Sem correlação automática entre as camadas, cada consulta de log era manual. Imagine o trabalho em um ambiente com centenas de micro-serviços!
Medidas corretivas: reciclando regras de segurança
- Auditoria completa nas mitigações: compararam o que cada regra bloqueia hoje versus quando foi criada.
- Expiração por padrão: daqui para frente, toda regra emergencial nasce com data de validade.
- Documentação e pós-incidente: revisão formal para decidir se a regra vira solução permanente ou é removida.
- Visibilidade centralizada: dashboard único mostrando quem bloqueou o quê em tempo real.
O que você pode aplicar no seu projeto
Mesmo sem lidar com dezenas de milhões de requisições por minuto, os princípios são universais. Veja alguns insights que servem tanto para um blog de review de placas de vídeo quanto para APIs de e-commerce:
1. Expire regras temporárias
Configure o seu Amazon WAF ou firewall local para expirar filtros emergenciais em 48 h, a menos que sejam revisados manualmente. Assim, você evita “trancar” clientes que chegaram por novas fontes de tráfego, como Google Discover.
2. Logs centralizados com contexto
Ferramentas como AWS CloudWatch, Datadog ou o combo ELK Stack (Elasticsearch + Logstash + Kibana) permitem juntar borda, aplicação e banco de dados no mesmo painel. O tempo que você economiza em suporte paga qualquer assinatura.
Imagem: Internet
3. Métricas e limites dinâmicos
Aposte em rate limits que se ajustam por usuário autenticado, plano de assinatura ou reputação de IP em tempo real. Serviços de API Gateway fazem isso fora da caixa — e alguns plug-ins de WordPress também.
4. Teste de regressão de segurança
Cada vez que atualizar sua CDN ou o plugin de cache, rode um script de navegação automatizado (Selenium) para garantir que visitantes anônimos continuam vendo as páginas de produto dos seus afiliados Amazon normalmente.
Impacto para desenvolvedores e empresas
Se o GitHub, com equipes dedicadas de SRE, pode cair nessa cilada, qualquer projeto menor está ainda mais vulnerável. Bloqueios inadvertidos prejudicam SEO, reduzem conversões e alimentam reviews negativos — aquele visitante que não carrega sua vitrine de GPUs dificilmente volta.
Melhorar a lifecycle management das defesas é investimento direto na experiência de usuário. Afinal, performance, segurança e acessibilidade são fatores que o Google considera no ranking, especialmente no Discover.
Conclusão
Proteções de tráfego são como remédios fortes: salvam o paciente durante a crise, mas viram veneno se tomadas sem prescrição. Audite suas regras, expire o que for temporário e mantenha visibilidade total. Só assim você garante que a próxima promoção de teclado mecânico ou placa de vídeo RTX chegue aos olhos certos — e não a uma tela de erro 429.
Com informações de GitHub Engineering Blog
