O que é WAF (firewall de aplicação)

Todo site ou API exposto à internet recebe requisições que não são de usuários: robôs que testam formulários, scanners que procuram falhas conhecidas, tentativas de injetar código num parâmetro. Um firewall comum não enxerga nada disso, porque o tráfego é HTTP válido, vindo de IPs comuns, para a porta 443.

O WAF existe para cobrir essa lacuna. Ele olha o conteúdo da requisição e decide se ela parece um ataque. Entender o que ele faz (e o que não faz) evita duas confusões comuns: achar que ele resolve tudo ou achar que é só um nome chique para firewall.

O que é um WAF?#

WAF significa Web Application Firewall. É um filtro posicionado entre o cliente e a aplicação web que inspeciona o tráfego HTTP e HTTPS. Se a requisição casa com uma regra de ataque, ele a bloqueia, registra ou desafia (por exemplo, com um CAPTCHA). Se não casa, repassa para a aplicação.

Ele protege contra ataques que exploram a aplicação em si, como SQL injection, XSS (cross-site scripting) e inclusão local de arquivos. Esses exemplos aparecem na descrição do OWASP Core Rule Set (CRS), o conjunto de regras genéricas mais conhecido para WAFs compatíveis com ModSecurity.

Como um WAF funciona por dentro?#

O fluxo básico tem três passos:

1. A requisição chega ao WAF, que a decodifica (URL, cabeçalhos, cookies, parâmetros, corpo JSON ou formulário).
2. O WAF compara cada parte com as regras. Uma regra pode ser uma expressão regular, uma lista de padrões ou uma verificação de formato.
3. Conforme o resultado, ele deixa passar, bloqueia (geralmente com resposta 403) ou só registra.

Muitos WAFs usam pontuação de anomalia. Em vez de bloquear na primeira regra que bate, cada regra soma pontos, e a requisição é bloqueada quando a soma passa de um limite. A documentação do CRS recomenda trabalhar com um limite de 5. Isso reduz bloqueios causados por um único sinal fraco.

Existem dois modelos de regra:

• Lista de bloqueio (modelo negativo): bloqueia o que parece ruim. É simples de ligar, mas só pega o que as regras conhecem.
• Lista de permissão (modelo positivo): só aceita o que está descrito como válido (rotas, métodos, tipos de campo). É mais forte, mas dá trabalho para manter.

O que são níveis de paranoia?#

O CRS tem quatro níveis de paranoia. O nível 1 é a base para qualquer servidor HTTP, com poucos falsos alarmes. O nível 2 é indicado para sites que lidam com dados reais de usuários, como uma loja. Os níveis 3 e 4 detectam mais, mas exigem escrever exclusões de regra porque barram tráfego legítimo. Subir o nível sem testar é a forma mais rápida de quebrar um formulário que funcionava.

Um exemplo concreto#

Imagine uma rota de busca que monta a consulta concatenando texto:

// ERRADO: vulnerável a SQL injection
const sql = `SELECT * FROM users WHERE name = '${req.query.name}'`;

Um atacante envia ?name=' OR '1'='1. Um WAF reconhece o padrão de injeção e devolve 403 antes de a requisição tocar no código. Mas a correção de verdade está na aplicação:

// CERTO: consulta parametrizada (mysql2)
const [rows] = await db.execute("SELECT * FROM users WHERE name = ?", [req.query.name]);

Com a consulta parametrizada, o valor nunca vira parte do SQL. O WAF é uma segunda camada, não a primeira.

Para ter uma ideia de como uma regra é escrita, esta é uma regra mínima de ModSecurity que bloqueia a requisição se algum parâmetro contém <script:

SecRule ARGS "@rx (?i)<script" \
    "id:1001,phase:2,deny,status:403,msg:'Possivel XSS'"

Na prática, você raramente escreve regras assim do zero: usa um conjunto pronto como o CRS e ajusta as exceções.

Qual a diferença entre WAF, firewall de rede e proteção DDoS?#

Eles se complementam. O WAF não é feito para absorver um ataque volumétrico: para isso, veja o que é um ataque DDoS. E é comum o WAF rodar dentro de um proxy reverso ou de uma CDN, porque esse é o ponto por onde o tráfego já passa.

Quais são os limites de um WAF?#

• Falsos positivos: uma regra mal calibrada bloqueia usuários reais, por exemplo quem cola um trecho de código num campo de texto.
• Falsos negativos: um atacante pode ofuscar o payload ou usar uma falha que nenhuma regra conhece.
• Falhas de lógica: um WAF não sabe que o usuário A não deveria ver o pedido do usuário B. Controle de acesso quebrado é problema do código.
• Custo operacional: alguém precisa ler os logs, ajustar exceções e atualizar regras.

Por isso o WAF entra como parte de uma lista maior. Veja o checklist de segurança para deploy para o que fazer além dele.

Quando faz sentido usar um WAF?#

Faz sentido quando a aplicação é pública e recebe entrada de usuários: formulários, APIs com parâmetros, painéis de login. Também ajuda quando você não pode corrigir uma falha agora, porque uma regra temporária (o chamado virtual patch) bloqueia a exploração enquanto o código não é corrigido.

Faz menos diferença em um bot que só abre conexão de saída com o Gateway do Discord e não recebe requisições HTTP de fora. Sem entrada pública, não há o que filtrar.

Como fazer isso na Square Cloud#

Na Square Cloud, todos os planos incluem um WAF e mitigação de DDoS nas camadas 3, 4 e 7. A infraestrutura usa containers isolados e uma CDN Anycast com HTTP/3 e WebSockets.

Isso não dispensa as boas práticas no código. Mantenha segredos em variáveis de ambiente, use consultas parametrizadas e valide a entrada. Trate o WAF como uma camada extra, não como a defesa principal.

Veja a rede da Square Cloud para os detalhes de CDN, WAF e mitigação de DDoS.