Se o seu produto tem uma API pública ou uma interface web, ele já recebe tráfego que você não pediu: scanners automatizados testando rotas conhecidas, bots tentando credenciais vazadas em outros vazamentos, ferramentas de reconhecimento mapeando o que sua stack expõe. Isso acontece independente de você ter tido um incidente ou não — é ruído de fundo da internet pública.

Um WAF (Web Application Firewall) fica entre esse tráfego e a sua aplicação, filtrando o que nunca deveria chegar ao seu código.

As três camadas de proteção de uma API pública

Vale separar o que cada camada realmente cobre — é comum ver produtos vibe-code com uma camada forte e as outras duas completamente ausentes.

  • Perímetro (WAF): filtra payloads malformados, assinaturas conhecidas de ataque, tráfego automatizado abusivo e picos fora do padrão — antes de qualquer linha do seu código executar.
  • Regra de negócio: decide se um usuário autenticado pode acessar um recurso específico. Isso não é trabalho do WAF — é lógica de autorização que vive na sua aplicação.
  • Validação de entrada no código: garante que os dados que chegam depois do filtro de perímetro estão no formato e nos limites esperados antes de tocar seu banco de dados.
O erro mais comum

Tratar o WAF como a única camada — "coloquei um WAF, então estou protegido" — é o mesmo erro que deixar a porta de casa trancada e as janelas abertas. O WAF reduz o volume de ruído malicioso que chega até você; ele não substitui as outras duas camadas.

O que muda na prática depois de configurado

Antes de qualquer regra específica de negócio, um conjunto bem calibrado de regras de WAF já resolve uma fatia relevante do que costuma virar incidente em produtos pequenos:

  • Tentativas de injeção SQL e NoSQL em parâmetros de URL e corpo de requisição.
  • Scanners de vulnerabilidade automatizados testando rotas e headers conhecidos.
  • Rate limiting por rota e por origem, contendo brute force em endpoints de login antes que consuma recursos da sua VPS.
  • Bloqueio de payloads acima do tamanho esperado, que costumam anteceder tentativas de exaustão de recursos.

Calibrar, não copiar um conjunto de regras genérico

Regras de WAF prontas, aplicadas sem ajuste, geram dois problemas opostos: ou bloqueiam tráfego legítimo do seu próprio produto (um webhook seu que "parece" malicioso porque tem payload grande), ou deixam passar o que é específico da sua API porque a regra genérica não conhece suas rotas. A calibração parte do tráfego real do seu produto — não de uma lista universal.

Onde termina o WAF

Um WAF não sabe se o usuário autenticado "A" deveria ver o recurso do usuário "B" — isso é controle de acesso da aplicação. Ele também não substitui validação de tipo, tamanho e formato de dados no seu próprio código, nem revisão de dependências vulneráveis. É por isso que perímetro, acesso privado e AppSec no pipeline entram juntos como camadas complementares, não intercambiáveis.

Se sua API pública ainda não tem nenhuma camada de perímetro, esse costuma ser o primeiro item resolvido numa implantação — antes mesmo de mexer em SSO ou VPN, porque é a superfície com maior exposição direta ao tráfego público.