---
title: "O que é WAF e quando usar em sites e APIs"
description: "WAF é o firewall que inspeciona requisições HTTP. Entenda ModSecurity com OWASP CRS, Coraza, WAF de CDN, falsos positivos e quando usar em sites e APIs."
url: "https://streethosting.com.br/guias/infraestrutura/o-que-e-waf-firewall-aplicacao"
category: "infraestrutura"
slug: "o-que-e-waf-firewall-aplicacao"
datePublished: "2026-09-28"
dateModified: "2026-09-28"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "o que e waf"
  - "waf firewall de aplicacao web"
  - "modsecurity owasp crs"
  - "modsecurity nginx ubuntu"
  - "coraza waf"
  - "waf para api"
---

# WAF, o firewall que lê as requisições HTTP

Um WAF inspeciona o conteúdo de cada requisição e barra injeções, XSS e exploração de falhas conhecidas. Veja os modelos, como instalar o ModSecurity com o OWASP CRS no Nginx e como calibrar sem quebrar o site.

> **Resposta rápida**
>
> **WAF** (Web Application Firewall) é um firewall de camada 7: em vez de olhar só IP e porta, ele lê cada requisição HTTP e barra padrões de ataque como injeção de SQL, XSS e exploração de falhas conhecidas. Pode rodar na CDN, como módulo do servidor web (ModSecurity ou Coraza com o OWASP CRS) ou como proxy separado. Vale para sites com login, formulários e plugins, sempre começando em modo de detecção.

## O que é um WAF e o que ele enxerga

Um firewall de rede, como o UFW, responde a uma pergunta simples: essa conexão pode chegar a essa porta? Para um site, a resposta na porta 443 precisa ser sim para todo mundo, e é por essa porta aberta que chegam os ataques contra a aplicação. O WAF entra depois disso. Ele vê o método, a URL, os parâmetros, os cabeçalhos, os cookies e o corpo da requisição, e compara tudo com um conjunto de regras. A comparação conceitual entre os dois está em [firewall de rede e de aplicação](https://streethosting.com.br/guias/infraestrutura/firewall-rede-vs-aplicacao-diferenca); aqui o foco é como um WAF funciona na prática.

O que um WAF com boas regras costuma barrar:

- injeção de SQL em parâmetros e formulários;
- XSS, quando alguém tenta enviar script para ser exibido a outros usuários;
- inclusão de arquivos locais e remotos e travessia de diretórios;
- execução de comandos do sistema injetados em campos;
- ferramentas de varredura conhecidas e requisições que violam o protocolo HTTP.

O Core Rule Set da OWASP, conjunto de regras mais usado, trabalha por pontuação de anomalia. Cada regra que casa soma pontos à requisição, 5 para uma ocorrência crítica, e a decisão sai no fim: bloqueia quando o total atinge o limite, 5 por padrão. Uma ocorrência crítica basta; avisos menores precisam se somar. A sensibilidade se ajusta em um lugar só.

O que ele não faz: não corrige erro de lógica, não percebe que um usuário acessou o pedido de outro, não detecta login com senha vazada que é válida e não segura DDoS volumétrico. Um WAF é uma camada, não a segurança inteira da aplicação.

## Três formas de ter um WAF

| Modelo | Onde roda | Vantagem | Limitação |
| --- | --- | --- | --- |
| WAF de CDN | Na borda da CDN, antes da VPS | Filtra antes de gastar CPU e banda da VPS | Só protege se a origem aceitar tráfego apenas da CDN; regras avançadas costumam ser pagas |
| Módulo no servidor web | Dentro do Nginx, na própria VPS | Controle total das regras, sem licença, vê o tráfego já descriptografado | Consome CPU e RAM da VPS; calibrar e manter é tarefa sua |
| Proxy separado | Processo ou máquina à frente da aplicação | Isola o WAF e atende vários sistemas de uma vez | Mais um componente para operar e mais um salto de rede |

O WAF de CDN tem um ponto fraco que quase ninguém confere: se o IP real da VPS vazar, por um registro DNS antigo ou por um email enviado direto do servidor, o atacante fala com a origem e pula toda a proteção. Por isso, ao usar CDN, trave as portas 80 e 443 da VPS para aceitar só as faixas de IP publicadas pela CDN, com regras de origem no [UFW](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu). E configure o Nginx para recuperar o IP verdadeiro do visitante com `set_real_ip_from` e `real_ip_header`, usando o cabeçalho que a CDN documenta. Sem isso, logs, bloqueios e limites enxergam todo visitante como se fosse a própria CDN.

## ModSecurity com OWASP CRS no Nginx

O ModSecurity nasceu como módulo do Apache. A versão 3 separou o motor em uma biblioteca, a libmodsecurity, ligada ao Nginx por um conector. Em 2024 o projeto passou para a OWASP. O motor sozinho não bloqueia nada: quem define o que é ataque é o OWASP Core Rule Set, o CRS. No Ubuntu 24.04 os dois estão no repositório universe, que vem ativo na instalação padrão:

```
sudo apt update
sudo apt install libnginx-mod-http-modsecurity modsecurity-crs
```

O primeiro pacote traz o módulo do Nginx e o `/etc/nginx/modsecurity.conf`, com a configuração do motor. O segundo instala o CRS 3.3, com os ajustes em `/etc/modsecurity/crs/crs-setup.conf` e as regras em `/usr/share/modsecurity-crs/rules/`. Um detalhe quebra a instalação de muita gente: o arquivo que o pacote do CRS usa para carregar as regras foi escrito para o Apache e usa a diretiva IncludeOptional, que a libmodsecurity não reconhece. O caminho mais seguro é listar tudo com Include no arquivo que o Nginx lê:

```
# /etc/nginx/modsecurity_includes.conf
Include /etc/nginx/modsecurity.conf
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Include /usr/share/modsecurity-crs/rules/*.conf
Include /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
```

A ordem importa: ajustes, depois exclusões que agem antes das regras, depois as regras, e por último as exclusões que alteram regras já carregadas. Em seguida, ligue o módulo no bloco server do site, o mesmo que você montou no guia de [proxy reverso com Nginx](https://streethosting.com.br/guias/vps/configurar-nginx-reverse-proxy-vps):

```
server {
    server_name seu-dominio.com.br;

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsecurity_includes.conf;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}
```

Valide e recarregue com `sudo nginx -t && sudo systemctl reload nginx`. Para confirmar que as regras estão ativas, faça uma requisição que o CRS reconhece como execução de comando. Em modo de detecção a resposta segue normal e a ocorrência vai para o log; com bloqueio, vira 403:

```
curl -s -o /dev/null -w "%{http_code}\n" "https://seu-dominio.com.br/?exec=/bin/bash"
sudo tail -n 20 /var/log/nginx/error.log | grep ModSecurity
```

O nível de paranoia, de 1 a 4, fica no `crs-setup.conf`. O nível 1, padrão, pega os ataques comuns com poucos falsos positivos e é o certo para quase todo site. Cada nível acima acrescenta regras mais desconfiadas e muito mais trabalho de calibragem. O CRS 4, série atual, não está nos repositórios do Ubuntu 24.04 e é instalado a partir das versões publicadas no GitHub do projeto.

## Coraza, a alternativa em Go

O OWASP Coraza é um motor de WAF escrito em Go que entende a mesma linguagem de regras do ModSecurity e roda o CRS sem adaptação. Ele faz sentido quando o seu proxy não é o Nginx:

- **Caddy:** o módulo `coraza-caddy` entra em um binário do Caddy compilado com o xcaddy, e a diretiva do Caddyfile já traz o CRS embutido.
- **Envoy:** roda como filtro WebAssembly, pelo projeto `coraza-proxy-wasm`, comum em clusters Kubernetes.
- **HAProxy:** conversa com o Coraza por SPOA, com o WAF em um processo separado.
- **Aplicação em Go:** pode ser usado como biblioteca, dentro do próprio código.

```
xcaddy build --with github.com/corazawaf/coraza-caddy/v2
```

Com Nginx no Ubuntu, o ModSecurity segue como caminho de menor atrito, porque vem empacotado. Detecção e falsos positivos, a seguir, funcionam igual nos dois, já que regras e diretivas são as mesmas.

## Comece em modo de detecção

O CRS não conhece a sua aplicação. Um editor de texto rico que envia HTML, um campo de busca onde alguém digita um trecho de SQL, uma API que recebe código dentro de um JSON: tudo isso parece ataque para uma regra genérica. Ligar o bloqueio no primeiro dia é o jeito mais rápido de derrubar o próprio login ou o próprio checkout.

Por isso o modsecurity.conf do pacote vem com `SecRuleEngine DetectionOnly`: as regras rodam, as ocorrências são registradas, mas nada é bloqueado. Deixe assim por uma ou duas semanas de tráfego real, passando por todos os fluxos do sistema. As ocorrências aparecem no log de erro do Nginx como linhas com ModSecurity: Warning, contendo o id da regra, a variável que casou e a URI. Duas consultas mostram o quadro:

```
# últimas ocorrências completas
sudo grep "ModSecurity: Warning" /var/log/nginx/error.log | tail -n 5

# regras que mais disparam
sudo grep -o '\[id "[0-9]*"\]' /var/log/nginx/error.log | sort | uniq -c | sort -rn | head
```

Separe dois grupos. Ocorrências vindas de IPs desconhecidos, em caminhos que não existem no seu site, são ataque de verdade e mostram que o WAF está trabalhando. Ocorrências vindas dos seus próprios usuários, sempre na mesma rota e no mesmo campo, são falso positivo e pedem exclusão. Quando o segundo grupo zerar, troque para bloqueio:

```
sudo sed -i 's/^SecRuleEngine DetectionOnly/SecRuleEngine On/' /etc/nginx/modsecurity.conf
sudo nginx -t && sudo systemctl reload nginx
```

> **Dica**
>
> O registro completo de cada requisição sinalizada, com cabeçalhos e corpo, vai para o arquivo definido em SecAuditLog no modsecurity.conf. Ele ajuda muito na calibragem, mas cresce rápido e pode guardar dados pessoais enviados em formulários. Acompanhe o tamanho e trate o arquivo como sensível.

## Como tratar falsos positivos

A regra de ouro é excluir o mínimo possível: uma regra, em um campo, em uma rota. Desligar o WAF inteiro por causa de um formulário, ou baixar o limite de pontuação do site todo, joga fora a proteção onde ela não atrapalhava. O CRS reserva dois arquivos para isso.

**Antes das regras**, no arquivo `REQUEST-900`, entram as exclusões que dependem da requisição. Exemplo: o editor do painel em /admin/editor envia HTML no campo conteudo e dispara a regra 941100, que detecta XSS pela libinjection. A exclusão tira só esse campo dessa regra, e só nessa rota:

```
# /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
SecRule REQUEST_URI "@beginsWith /admin/editor" \
    "id:10001,phase:1,pass,nolog,ctl:ruleRemoveTargetById=941100;ARGS:conteudo"
```

**Depois das regras**, no arquivo `RESPONSE-999`, entram as exclusões fixas, que valem para o site inteiro. Exemplo: um fórum de programação onde o campo busca recebe trechos de SQL o tempo todo e dispara a 942100, que detecta injeção de SQL pela libinjection:

```
# /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
SecRuleUpdateTargetById 942100 "!ARGS:busca"
```

- Use ids próprios que não colidam com os do CRS, que ocupam a faixa a partir de 900000.
- A ação `ctl:ruleRemoveById` tira a regra inteira da requisição e é mais grosseira. Prefira remover só o alvo, como no exemplo.
- Para WordPress, Drupal, Nextcloud e outros sistemas conhecidos, o CRS 3.3 traz pacotes de exclusão prontos, ligados no `crs-setup.conf`. No CRS 4 eles viraram plugins instalados à parte. Se o seu caso é um [WordPress na VPS com Nginx](https://streethosting.com.br/guias/vps/hospedar-wordpress-vps-nginx), comece por eles.
- Depois de cada exclusão, rode `sudo nginx -t`, recarregue, repita a ação que disparava e confira o log.

> **Atenção**
>
> Resista à tentação de excluir por IP o seu próprio escritório ou o seu próprio usuário. Se essa conta for comprometida, o atacante herda a exceção. Exclusão boa é por rota e campo, não por pessoa.

## Quando o WAF vale a pena

| Cenário | Recomendação |
| --- | --- |
| Site institucional estático | Opcional; cache, cabeçalhos de segurança e servidor atualizado resolvem mais |
| WordPress ou outro CMS com plugins | Vale a pena; é o alvo clássico de exploração em massa de plugin vulnerável |
| Loja ou sistema com login e formulários | Vale a pena, começando em modo de detecção |
| API JSON consumida por app próprio | Camada extra útil; autenticação, permissão por objeto e limite por token pesam mais |
| Sistema legado que não recebe mais atualização | Muito recomendado, como correção virtual enquanto não há substituto |
| Servidor de jogo como Minecraft | Não se aplica; o protocolo não é HTTP, a defesa é firewall e AntiDDoS |

O uso mais valioso do WAF é a correção virtual. Quando sai uma falha grave em um plugin ou framework, a exploração em massa começa em poucos dias, às vezes horas. As regras genéricas do CRS costumam pegar boa parte dessas cargas, e uma regra específica para a falha pode ser escrita na hora, comprando tempo até a atualização ser aplicada.

Em APIs, o CRS inspeciona também corpos JSON, mas o risco número um da lista de segurança de APIs da OWASP é autorização por objeto quebrada: o cliente troca o id na URL e lê dados de outra pessoa. Nenhum WAF genérico enxerga isso, porque a requisição é perfeitamente válida. O panorama das outras camadas está em [como proteger uma aplicação web contra ataques](https://streethosting.com.br/guias/infraestrutura/proteger-aplicacao-web-ataques).

## Custo de CPU e onde rodar

Com o WAF no servidor, cada requisição passa por centenas de regras antes de chegar à aplicação. O custo cresce com o tamanho do corpo, com o nível de paranoia e com a inspeção das respostas. Em uma VPS pequena com WordPress, o PHP e o WAF disputam os mesmos núcleos. Isso também explica por que o WAF sozinho não segura uma enxurrada de requisições: ele gasta CPU em cada uma. Contra esse cenário, o limite de frequência e a borda trabalham melhor, como mostra o guia de [DDoS de camada 7](https://streethosting.com.br/guias/infraestrutura/ddos-camada-7-l7-aplicacao). IPs que o WAF barra repetidamente podem ir para o [Fail2Ban](https://streethosting.com.br/guias/vps/configurar-fail2ban-ssh-vps), com um filtro próprio para essas linhas do log.

As [VPS da StreetHosting](https://streethosting.com.br/vps) são KVM com acesso root, então você instala o módulo que quiser, e ficam em São Paulo com AntiDDoS incluso na rede, cobrindo a camada volumétrica que o WAF não cobre. Para um WordPress ou uma loja com ModSecurity, PHP e banco na mesma máquina, a VPS Ryzen 9 9950X de 4 vCPU, 8 GB DDR5 e 80 GB NVMe, por R$ 114,00 por mês, dá folga para as regras sem apertar a aplicação. Para uma API mais leve, a VPS Xeon de 4 vCPU e 6 GB sai por R$ 57,00. Os planos de entrada, de R$ 23,00 na Xeon e R$ 39,00 na Ryzen, servem para calibrar a configuração antes da produção.

## Perguntas frequentes

### WAF substitui o firewall da VPS?

Não. O firewall de rede decide quais portas aceitam conexão e continua sendo o que fecha banco de dados, painéis e serviços internos. O WAF só atua no tráfego HTTP que já passou por esse firewall, lendo o conteúdo das requisições. Os dois trabalham juntos.

### O WAF deixa o site mais lento?

Ele acrescenta processamento em cada requisição, porque cada uma passa por centenas de regras. Em páginas comuns a diferença costuma ser pequena, mas cresce com corpos grandes, uploads e nível de paranoia alto. Meça o tempo de resposta e o uso de CPU antes e depois de ligar.

### O ModSecurity ainda é mantido?

Sim. Em 2024 o projeto passou para a OWASP, que já mantinha o Core Rule Set. A versão 3, usada com o Nginx, segue ativa, e o CRS 4 é a série atual das regras. O Ubuntu 24.04 ainda empacota o CRS 3.3, que continua funcional para começar.

### Posso usar o WAF da CDN e o ModSecurity ao mesmo tempo?

Pode. A CDN filtra o grosso antes de gastar CPU da VPS, e o ModSecurity inspeciona o que chegou, com regras que você controla. O custo é calibrar falsos positivos em dois lugares. Se a origem estiver travada para aceitar só a CDN, muita gente fica só com o WAF da borda.

### WAF protege uma API?

Em parte. Ele barra injeções e cargas maliciosas conhecidas também em corpos JSON, mas não sabe se o usuário 15 pode ler o pedido do usuário 16. Para API, autenticação por token, checagem de permissão em cada objeto, validação de esquema e limite de requisições pesam mais que o WAF.

## Guias relacionados

- [Proteger aplicação web contra ataques: defesa em camadas](https://streethosting.com.br/guias/infraestrutura/proteger-aplicacao-web-ataques.md)
- [Firewall de rede e firewall de aplicação: qual a diferença](https://streethosting.com.br/guias/infraestrutura/firewall-rede-vs-aplicacao-diferenca.md)
- [DDoS de camada 7: o que é o ataque de aplicação e como mitigar](https://streethosting.com.br/guias/infraestrutura/ddos-camada-7-l7-aplicacao.md)
- [Como configurar o Nginx como reverse proxy na VPS](https://streethosting.com.br/guias/vps/configurar-nginx-reverse-proxy-vps.md)
- [Configurar Fail2Ban na VPS: SSH, Nginx e reincidentes](https://streethosting.com.br/guias/vps/configurar-fail2ban-ssh-vps.md)

## Produtos citados

- https://streethosting.com.br/vps
- https://streethosting.com.br/vps/ryzen
- https://streethosting.com.br/vps/xeon

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "WAF, o firewall que lê as requisições HTTP",
    "name": "O que é WAF e quando usar em sites e APIs",
    "abstract": "Um WAF inspeciona o conteúdo de cada requisição e barra injeções, XSS e exploração de falhas conhecidas. Veja os modelos, como instalar o ModSecurity com o OWASP CRS no Nginx e como calibrar sem quebrar o site.",
    "description": "WAF é o firewall que inspeciona requisições HTTP. Entenda ModSecurity com OWASP CRS, Coraza, WAF de CDN, falsos positivos e quando usar em sites e APIs.",
    "datePublished": "2026-09-28",
    "dateModified": "2026-09-28",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/infraestrutura/o-que-e-waf-firewall-aplicacao"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "WAF substitui o firewall da VPS?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Não. O firewall de rede decide quais portas aceitam conexão e continua sendo o que fecha banco de dados, painéis e serviços internos. O WAF só atua no tráfego HTTP que já passou por esse firewall, lendo o conteúdo das requisições. Os dois trabalham juntos."
        }
      },
      {
        "@type": "Question",
        "name": "O WAF deixa o site mais lento?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Ele acrescenta processamento em cada requisição, porque cada uma passa por centenas de regras. Em páginas comuns a diferença costuma ser pequena, mas cresce com corpos grandes, uploads e nível de paranoia alto. Meça o tempo de resposta e o uso de CPU antes e depois de ligar."
        }
      },
      {
        "@type": "Question",
        "name": "O ModSecurity ainda é mantido?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Sim. Em 2024 o projeto passou para a OWASP, que já mantinha o Core Rule Set. A versão 3, usada com o Nginx, segue ativa, e o CRS 4 é a série atual das regras. O Ubuntu 24.04 ainda empacota o CRS 3.3, que continua funcional para começar."
        }
      },
      {
        "@type": "Question",
        "name": "Posso usar o WAF da CDN e o ModSecurity ao mesmo tempo?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Pode. A CDN filtra o grosso antes de gastar CPU da VPS, e o ModSecurity inspeciona o que chegou, com regras que você controla. O custo é calibrar falsos positivos em dois lugares. Se a origem estiver travada para aceitar só a CDN, muita gente fica só com o WAF da borda."
        }
      },
      {
        "@type": "Question",
        "name": "WAF protege uma API?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Em parte. Ele barra injeções e cargas maliciosas conhecidas também em corpos JSON, mas não sabe se o usuário 15 pode ler o pedido do usuário 16. Para API, autenticação por token, checagem de permissão em cada objeto, validação de esquema e limite de requisições pesam mais que o WAF."
        }
      }
    ]
  }
]
```