fix(seguranca): limitar o /events/ingest, unica rota publica de escrita - #30
Merged
Conversation
O PR #23 protegeu as rotas de auth, mas o /ingest ficou de fora - e ele e a unica rota publica de escrita do sistema, exposta a internet para Zabbix/Grafana/Datadog chamarem. So havia o limite global de 100/min, entao um token vazado ou uma ferramenta em loop podia inundar a base de eventos (e consumir a cota de eventos do plano do tenant). Limite por TOKEN, nao por IP: varias fontes costumam sair do mesmo IP de saida (NAT), e limitar por IP faria uma ferramenta ruidosa derrubar a ingestao das demais. Sem token identificavel, cai para o IP. 120/min e folgado para monitoramento normal e ainda contem um loop. Verificado subindo o Fastify isolado: a fonte que estoura o limite leva 429 enquanto outra fonte, no mesmo IP, segue recebendo 200.
Contributor
There was a problem hiding this comment.
Pull request overview
Este PR adiciona um rate limit específico para o endpoint público de ingestão de eventos (POST /api/events/ingest), visando conter abuso/loops e reduzir o risco de consumo indevido da cota mensal de eventos por tenant.
Changes:
- Adiciona rate limit por rota em
/api/events/ingest, com chave preferencial por token (fallback para IP). - Documenta no
CONTRIBUTING.mdque esta é a única rota pública de escrita e que o limite é por token.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| CONTRIBUTING.md | Documenta a decisão de rate limit por token para a rota pública de ingestão. |
| backend/src/modules/events/events.routes.js | Configura rate limit dedicado para /ingest (max 120/min) com keyGenerator baseado em token/IP. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+55
to
+59
| rateLimit: { | ||
| max: 120, | ||
| timeWindow: '1 minute', | ||
| keyGenerator: (request) => request.headers['x-api-token'] || request.ip | ||
| } |
This was referenced Aug 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
O problema
O PR #23 protegeu as rotas de
/api/auth, mas o/api/events/ingestficou de fora — e ele é a única rota pública de escrita do sistema, exposta à internet para Zabbix/Grafana/Datadog/Sentry chamarem.Só havia o limite global de 100/min. Um token vazado ou uma ferramenta em loop podia inundar a base de eventos — e, de quebra, consumir a cota mensal de eventos do plano do tenant.
A decisão: limite por token, não por IP
Este é o ponto que merece atenção na revisão. Ferramentas de monitoramento de uma mesma empresa costumam sair pelo mesmo IP de saída (NAT). Se o limite fosse por IP, uma ferramenta ruidosa derrubaria a ingestão de todas as outras da mesma rede — falha em cascata a partir de um problema isolado.
Com limite por token, cada fonte tem sua própria cota. Sem token identificável, cai para o IP.
120/min é folgado para monitoramento normal e ainda contém um loop descontrolado.
Validação
Subi o Fastify isolado reproduzindo o cenário exato:
Ou seja: a fonte que estoura é barrada, e a outra — no mesmo IP — continua funcionando. Era exatamente o comportamento que a escolha por token pretendia garantir.
Test plan
npm test→ 25 passam