ModSecurity é o firewall de aplicação web mais usado em servidores de hospedagem — um módulo do servidor que lê cada requisição HTTP antes de ela chegar ao seu site e bloqueia o que corresponde a padrões de ataque. Ele é open source, roda no Apache, Nginx e IIS, e está ativo na maioria das hospedagens compartilhadas sem que o cliente saiba.
E é justamente por estar ativo sem aviso que a maior parte das buscas por “ModSecurity” vem de quem foi bloqueado por ele: o formulário que parou de enviar, o post do WordPress que não salva, o erro 403 que aparece só numa ação específica. Este guia cobre as duas pontas — o que ele faz e o que fazer quando ele bloqueia algo legítimo.
ModSecurity é um WAF que roda no servidor, antes do PHP. Lê a requisição inteira e bloqueia padrões de ataque.
| Ele bloqueou meu site? | Sintoma típico: erro 403 em uma ação específica, não no site inteiro |
| O que fazer | Peça ao suporte o ID da regra que disparou e a liberação daquela regra |
| Desativar tudo? | Não. Ele bloqueia ataques reais o tempo todo, silenciosamente |
Conteúdo
O que é o ModSecurity
O ModSecurity é um módulo de firewall de aplicação web — um WAF — que se instala junto ao servidor web. Ele foi criado em 2002 para o Apache, é open source, e hoje funciona também no Nginx e no IIS.
A diferença para um firewall comum é a camada em que atua. Um firewall de rede decide com base em endereço IP e porta: ele vê de onde a requisição vem, mas não o que ela contém. O ModSecurity lê o conteúdo — URL, parâmetros, cabeçalhos, cookies, corpo do POST — e compara com padrões conhecidos de ataque.
Nosso guia sobre o que é WAF explica essa distinção em detalhe. O ModSecurity é a implementação mais comum desse conceito em hospedagem.
Onde ele roda importa. Como é um módulo do servidor, ele inspeciona a requisição antes do PHP carregar. Um plugin de segurança do WordPress faz um trabalho parecido, mas só depois que o WordPress já iniciou — o que significa que o ataque já consumiu recursos da sua conta antes de ser barrado.
Contra o que ele protege
As categorias que ele cobre são as mais frequentes contra sites:
- SQL injection — comandos de banco inseridos em campos de formulário ou parâmetros de URL
- Cross-site scripting (XSS) — JavaScript malicioso injetado em páginas
- Path traversal e inclusão de arquivos — tentativas de acessar arquivos fora do diretório do site, como o
wp-config.php - Exploração de vulnerabilidades conhecidas — bots varrendo a internet em busca de sites com plugins desatualizados
- Execução remota de comandos
- Força bruta em formulários de login
O benefício mais concreto é o que se chama de virtual patching: quando surge uma falha crítica num plugin popular, a regra que bloqueia a exploração costuma chegar antes de o desenvolvedor lançar a correção — e muito antes de o dono do site aplicá-la.
Como ele decide o que bloquear: as regras
O ModSecurity sozinho não bloqueia nada. Ele é um motor que aplica regras, e as regras vêm de conjuntos separados.
O mais usado é o OWASP Core Rule Set (CRS) — um conjunto aberto, mantido pela comunidade, que cobre as principais categorias de ataque. Praticamente toda hospedagem que usa ModSecurity usa o CRS como base, complementado por regras próprias do provedor ou de fornecedores comerciais.
Cada regra tem um ID numérico, e esse detalhe é mais útil do que parece: quando o ModSecurity bloqueia algo, o log registra o ID da regra que disparou. É esse número que permite liberar exatamente aquela regra, em vez de desativar a proteção inteira.
ModSecurity: Access denied with code 403.
Matched "Operator Rx" against variable "ARGS:content"
[id "942100"] [msg "SQL Injection Attack Detected"]
Nesse exemplo, a regra 942100 foi acionada porque algo no campo content pareceu injeção de SQL. Se isso aconteceu enquanto você salvava um post com um trecho de código, é falso positivo — e o suporte pode liberar essa regra específica para o seu site.
Os níveis de paranoia
Um conceito do CRS que explica muita coisa, e que quase nenhum artigo em português cobre.
O Core Rule Set trabalha com níveis de paranoia, de 1 a 4. Quanto maior o nível, mais regras são aplicadas e mais rigorosa fica a inspeção — e mais falsos positivos aparecem.
| Nível | Comportamento |
|---|---|
| 1 (padrão) | Poucos falsos positivos. Cobre os ataques mais evidentes. É o recomendado para a maioria dos sites |
| 2 | Mais rigoroso. Exige algum ajuste de regras para o site funcionar normalmente |
| 3 e 4 | Muito rigorosos. Para ambientes de alto risco, e exigem trabalho contínuo de ajuste |
Em hospedagem compartilhada, o provedor define esse nível para o servidor inteiro — o que explica por que a mesma aplicação funciona numa hospedagem e é bloqueada em outra.
Quando ele bloqueia você
Aqui está o motivo pelo qual a maioria das pessoas procura por ModSecurity.
O sintoma característico: um erro 403 que acontece numa ação específica, não no site inteiro. O site abre normalmente, mas alguma coisa dá erro.
Os casos mais comuns:
| Situação | Por que dispara |
|---|---|
| Salvar um post com código ou HTML | O conteúdo se parece com tentativa de injeção |
| Enviar formulário com texto longo | Certas combinações de caracteres acionam regras |
| Fazer upload de arquivo | Regras de inspeção de conteúdo de upload |
| Usar uma URL com muitos parâmetros | Padrões de query string que se parecem com ataque |
| Um plugin ou tema específico para de funcionar | A requisição dele bate com alguma regra |
O que fazer, em ordem:
1. Confirme que é o ModSecurity. Peça ao suporte para verificar o log no horário exato em que o erro aconteceu. A entrada trará o ID da regra.
2. Peça a liberação daquela regra específica, para o seu site. É procedimento de rotina em qualquer hospedagem, e leva minutos.
3. Se o problema for recorrente com um plugin, vale investigar o que ele está enviando — às vezes o padrão que dispara a regra é evitável.
É a solução que muita gente pede ao suporte, e é a pior de todas. Desligar o ModSecurity resolve o falso positivo e remove, junto, a proteção contra todos os ataques que ele estava bloqueando silenciosamente — e são muitos, todos os dias, sem que você perceba. Liberar uma regra específica leva o mesmo tempo e mantém o resto funcionando. Se o suporte oferecer desativar tudo como primeira solução, vale insistir na liberação pontual.
ModSecurity em hospedagem compartilhada e em VPS
A diferença prática é quem controla:
Em hospedagem compartilhada, o ModSecurity é configurado pelo provedor para o servidor inteiro. Você não escolhe as regras nem o nível de paranoia — mas também não precisa manter nada. Quando um falso positivo acontece, o caminho é o suporte.
Em VPS ou dedicado, você tem controle total: escolhe o conjunto de regras, ajusta o nível de paranoia, cria exceções e lê os logs diretamente. Em painéis como cPanel e CyberPanel, o ModSecurity aparece como uma seção do próprio painel, com ativação em um clique.
Vale notar que o ModSecurity é o motor por trás de várias soluções comerciais de segurança para servidores — o cPGuard e o Imunify360, por exemplo, usam regras baseadas nele, acrescentando antivírus, detecção de malware e interface de gestão.
O que ele não faz
Delimitar importa, porque WAF é frequentemente vendido como proteção completa:
- Não corrige a vulnerabilidade. Ele bloqueia a tentativa de exploração, mas a falha continua no código. Atualizar plugins e temas continua sendo a defesa principal
- Não protege contra senha fraca. Se o atacante acerta a senha, a requisição é legítima
- Não remove malware já instalado. Isso é trabalho de scanner e limpeza
- Não protege serviços fora do HTTP. SSH, FTP e banco de dados são responsabilidade do firewall de rede
- Não substitui backup
Os servidores da Homehost usam firewall de aplicação com regras atualizadas continuamente — e quando um falso positivo acontece, o suporte identifica a regra no log e libera aquela especificamente, em vez de desligar a proteção. Servidor no Brasil, CloudLinux isolando cada conta e atendimento em português.
Ver planos de hospedagemPerguntas frequentes
O que é ModSecurity?
É um módulo de firewall de aplicação web (WAF) que roda junto ao servidor, lendo cada requisição HTTP antes que ela chegue ao site. Ele compara o conteúdo da requisição com padrões conhecidos de ataque e bloqueia o que corresponder. É open source, criado em 2002, e funciona em Apache, Nginx e IIS.
Como saber se o ModSecurity está bloqueando meu site?
O sintoma típico é um erro 403 numa ação específica — salvar um post, enviar um formulário, fazer upload — enquanto o resto do site funciona normalmente. Para confirmar, peça ao suporte para verificar o log do ModSecurity no horário exato do erro; a entrada traz o ID da regra que disparou.
Por que o ModSecurity bloqueou uma ação legítima?
É um falso positivo: alguma regra interpretou conteúdo válido como tentativa de ataque. O caso mais comum é salvar um post com trechos de código ou HTML, que se parecem com injeção de SQL. Quanto mais rigoroso o nível de paranoia configurado no servidor, mais frequentes esses bloqueios.
Devo desativar o ModSecurity?
Não. Desativá-lo remove a proteção contra todos os ataques que ele bloqueia silenciosamente todos os dias. O correto é identificar o ID da regra que causou o falso positivo e pedir ao suporte a liberação daquela regra específica para o seu site.
O que é o OWASP Core Rule Set?
É o conjunto de regras aberto mais usado com o ModSecurity, mantido pela comunidade OWASP. Ele cobre as principais categorias de ataque a aplicações web e serve de base para praticamente toda hospedagem que usa ModSecurity, geralmente complementado por regras próprias do provedor.
Qual a diferença entre ModSecurity e um plugin de segurança do WordPress?
A camada em que rodam. O ModSecurity é um módulo do servidor e inspeciona a requisição antes do PHP carregar. Um plugin roda dentro do WordPress, depois que ele já iniciou — então a requisição maliciosa já consumiu recursos da sua conta antes de ser barrada. Os dois são complementares, não redundantes.
Minha hospedagem tem ModSecurity?
Provavelmente sim, se for uma hospedagem séria. A maioria mantém ModSecurity ou solução equivalente ativa em todos os servidores, sem configuração do cliente. Vale confirmar com o suporte — e é também a explicação para bloqueios aparentemente inexplicáveis em ações específicas do site.
O que são níveis de paranoia?
São os níveis de rigor do OWASP Core Rule Set, de 1 a 4. Quanto maior, mais regras são aplicadas e mais rigorosa fica a inspeção — com mais falsos positivos como consequência. O nível 1 é o padrão e o recomendado para a maioria dos sites; níveis 3 e 4 são para ambientes de alto risco e exigem ajuste contínuo.
Veja também
Para o conceito geral de firewall de aplicação, veja o que é WAF. Sobre o erro que o ModSecurity gera quando bloqueia algo, veja erro 403 Forbidden. E sobre o isolamento entre contas no servidor, veja CageFS.
Conclusão
O ModSecurity faz um trabalho que só aparece quando erra: bloqueia ataques todos os dias sem que ninguém perceba, e chama atenção no dia em que barra um post legítimo. Entender isso muda a reação — em vez de pedir para desligar tudo, o caminho é pegar o ID da regra no log e liberar aquela especificamente. Leva o mesmo tempo, resolve o mesmo problema, e mantém no lugar a proteção que estava funcionando o tempo inteiro.
