O que é WAF: proteção sem falsas promessas

Um WAF é um firewall de aplicação que inspeciona requisições HTTP antes que elas cheguem ao site. Ele bloqueia padrões suspeitos, aplica limites e registra eventos, mas precisa de ajuste contínuo. Sem correções, autenticação e controle de acesso, vira apenas uma barreira adicional, não uma solução completa.

Onde o WAF fica no caminho da requisição

O WAF precisa estar entre a internet e a aplicação protegida. Em um serviço de borda, ele costuma operar como proxy reverso: recebe a requisição, encerra ou participa da conexão segura, inspeciona o conteúdo HTTP e só então encaminha o tráfego aceito para a origem.

Também pode existir como módulo do servidor, componente do balanceador ou serviço gerenciado. A forma muda. O risco não: todo o tráfego público passa pelo ponto de inspeção ou ainda existe um caminho direto até o servidor?

Se a origem continua acessível pela internet, um atacante pode ignorar a borda e chamar o endereço do servidor diretamente. Quando a arquitetura permitir, a origem deve aceitar conexões apenas do proxy confiável. DNS escondido não é controle de acesso e deixa de funcionar assim que o endereço vaza.

Em HTTPS, o WAF precisa receber o tráfego após a terminação TLS ou participar dela. Dados ainda cifrados não revelam rota, parâmetros ou corpo para uma inspeção semântica. O certificado, a confiança entre proxy e origem e a nova criptografia do trecho interno fazem parte do desenho, não de um detalhe posterior.

Antes de contratar, desenhe o fluxo real:

• navegador ou cliente de API envia a requisição;
• proxy ou borda recebe e decifra o tráfego quando necessário;
• WAF avalia regras, contexto e limites;
• origem recebe apenas o tráfego liberado;
• aplicação ainda valida identidade, permissão e dados.

O que o WAF consegue observar

Na camada HTTP, o WAF pode considerar método, host, caminho, cabeçalhos, parâmetros, cookies e corpo, conforme a configuração e os limites do produto. Isso permite reconhecer padrões associados a injeção, scripts maliciosos, varredura automatizada, abuso de rotas e formatos inesperados.

Reconhecer um padrão não equivale a entender o negócio. Uma sequência estranha em um campo de busca pode ser ataque ou pesquisa legítima. Uma chamada válida pode ser abusiva porque o usuário tenta acessar dados de outra conta. O WAF vê a requisição; a aplicação conhece a autorização e o contexto.

As ações comuns incluem permitir, bloquear, desafiar, limitar, registrar ou apenas contar correspondências. O modo de observação é especialmente útil no início, pois mostra qual regra teria agido sem transformar um erro de configuração em indisponibilidade para clientes reais.

Modelo negativo, positivo ou combinado

As políticas de WAF costumam seguir duas ideias complementares. O modelo negativo procura sinais conhecidos de ataque. O positivo descreve o que uma requisição válida deve parecer. Na prática, aplicações públicas e APIs maduras tendem a combinar ambos.

Uma API com rotas, métodos e formatos bem definidos aproveita melhor regras positivas. Um site com formulários livres, conteúdo editorial e extensões variadas costuma depender mais de detecção negativa e exceções cuidadosas. A política deve seguir a aplicação, não o pacote de regras que veio ativado por padrão.

Permitir somente o comportamento esperado também não elimina falhas de autorização. Uma requisição pode obedecer perfeitamente ao formato e ainda pedir um recurso que aquele usuário não deveria ver. Essa decisão pertence à aplicação e ao serviço de identidade.

Falso positivo é custo, não detalhe

Um falso positivo ocorre quando uma requisição legítima aciona uma regra e é bloqueada ou desafiada. Um falso negativo é o inverso: tráfego malicioso atravessa a proteção. Apertar regras reduz alguns falsos negativos, mas normalmente eleva o risco de bloquear uso válido.

O exemplo clássico não precisa de exotismo. Um editor de conteúdo envia HTML permitido, uma busca recebe sinais de pontuação incomuns ou uma API aceita texto técnico. Uma regra genérica pode interpretar esse conteúdo como ataque porque não conhece as validações e permissões aplicadas depois.

Ajustar não significa desligar a proteção inteira. A boa exceção é estreita: identifica a regra, a rota, o parâmetro e o contexto que geraram o evento. Desativar uma família completa porque um formulário falhou elimina cobertura de páginas que nunca apresentaram o mesmo problema.

O caminho seguro para uma regra nova é progressivo:

• testar em ambiente representativo antes de tocar no tráfego real;
• observar correspondências sem bloquear quando o produto oferecer esse modo;
• reproduzir jornadas legítimas, inclusive login, busca, compra e envio de arquivos;
• criar exceções específicas, com responsável e motivo registrados;
• ativar o bloqueio com reversão preparada.

Mudanças no site exigem nova observação. Rotas, plugins, formatos de API e integrações alteram o tráfego legítimo. Regra sem revisão envelhece em silêncio: ou começa a bloquear clientes, ou permanece permissiva diante de um caminho que já não corresponde ao modelo original.

Registros que ajudam a decidir

Sem registros, a equipe só sabe que alguém recebeu uma página de bloqueio. Um evento útil informa quando ocorreu, qual host, método e caminho estavam envolvidos, qual ação foi tomada e qual regra ou categoria motivou a decisão. Um identificador de correlação liga o evento do WAF ao registro da aplicação.

O registro deve permitir responder a perguntas concretas: a mesma regra atingiu vários clientes legítimos? A atividade veio de uma rota sensível? Houve pico de bloqueios após uma implantação? A origem respondeu mesmo quando a borda deveria ter interrompido o fluxo?

Registrar tudo sem filtro cria outro incidente. Cabeçalhos de autorização, cookies de sessão, senhas, tokens, documentos e corpos de formulário podem conter dados pessoais ou segredos. Use mascaramento, retenção limitada, acesso restrito e coleta proporcional ao que a investigação realmente exige.

Métricas agregadas mostram tendência, mas não substituem amostras investigáveis. Um aumento de bloqueios pode indicar ataque, nova regra agressiva ou mudança legítima no produto. O número isolado não resolve a diferença; contexto de regra, rota e implantação resolve.

O que o WAF não substitui

O WAF pode reduzir exposição enquanto uma correção é preparada, mas não conserta o código vulnerável. Se a origem puder ser acessada por outro caminho, se a regra falhar ou se a requisição parecer válida, a vulnerabilidade continua presente.

Ele também não substitui:

• atualização do sistema, bibliotecas, extensões e dependências;
• validação de entrada e codificação segura de saída;
• autenticação forte, gestão de sessão e recuperação de conta;
• autorização por objeto, função e operação;
• segmentação de rede e restrição da origem;
• limites específicos de negócio, monitoramento e resposta a incidentes;
• cópias de segurança testadas e plano de recuperação.

Um firewall de rede decide sobre endereços, portas e protocolos. O WAF toma decisões na conversa HTTP. Já a aplicação decide se uma pessoa autenticada pode alterar aquela fatura, baixar aquele arquivo ou ver aquele cadastro. Essas camadas se somam; nenhuma herda automaticamente a responsabilidade da outra.

Nem toda mitigação de negação de serviço pertence ao WAF. Limites de requisição e controle de robôs podem ajudar em abusos da camada de aplicação, mas ataques volumétricos exigem capacidade e proteção de rede na borda. Prometer que uma única caixa resolve ambos é marketing, não arquitetura.

Quando vale contratar um WAF

O WAF faz sentido quando a aplicação é pública, recebe entradas variadas, enfrenta varredura frequente ou precisa de uma camada compensatória durante o ciclo de correção. Também ajuda uma equipe pequena a centralizar políticas e visibilidade para vários sites, desde que alguém cuide dos alertas e exceções.

Ele entrega menos valor quando é comprado apenas para marcar uma exigência, fica fora do caminho real, opera sem registros ou acumula regras que ninguém revisa. Nesse cenário, a mensalidade compra uma sensação de controle. Contrato também é infraestrutura: confirme quem ajusta regras, atende incidentes e permite exportar registros.

Ao comparar serviço gerenciado e operação própria, avalie trabalho, não apenas lista de recursos. Pergunte quem investiga falso positivo fora do horário, quanto tempo leva uma exceção urgente, como regras são testadas e se você consegue voltar à configuração anterior sem abrir toda a aplicação.

A decisão prática

Escolha um WAF quando houver um problema claro de exposição HTTP e capacidade real de operar a ferramenta. Posicione-o no fluxo, proteja a origem, comece observando, ajuste com precisão e mantenha os registros úteis. Depois corrija o software como se o WAF pudesse falhar. Ele pode, e esse é o ponto menos confortável do contrato.