O ModSecurity é um mecanismo de firewall de aplicação web (WAF). Ele compara requisições HTTP com regras que procuram padrões de ataque. Quando uma regra intervém, o visitante pode receber 403 Forbidden, mas nem todo 403 foi causado pelo ModSecurity e nem todo bloqueio é falso positivo.
O que o WAF observa
URL, método, cabeçalhos, cookies, argumentos e corpo da requisição podem ser avaliados. Um formulário legítimo com código, HTML, SQL, muitos caracteres ou nome de campo incomum pode se parecer com injeção ou cross-site scripting. Por outro lado, desativar a proteção só porque uma requisição foi bloqueada pode abrir uma vulnerabilidade real.
Primeiro: diferencie as causas de 403
| Indício | Possível causa |
|---|---|
| qualquer arquivo da pasta retorna 403 | permissões, regra no .htaccess, índice ou proprietário |
| apenas seu IP falha; outra rede funciona | firewall ou bloqueio do IP |
| só uma ação POST/AJAX falha | regra WAF, plugin de segurança ou validação da aplicação |
| resposta traz página da CDN | WAF/rate limit na camada de proxy |
| falha após login | sessão, autorização ou regra da própria aplicação |
Como reproduzir com evidência
- Anote URL, horário exato com fuso, IP público, usuário autenticado e ação executada.
- Preserve o código de status, o identificador da requisição e uma captura sem senhas ou tokens.
- Teste uma entrada mínima e depois adicione partes até localizar o campo que dispara o bloqueio.
- Confira console e rede do navegador para descobrir a URL real de AJAX/API.
- Correlacione com Errors, logs da aplicação, CDN e auditoria do ModSecurity quando disponível.
Como reconhecer um falso positivo
Há evidência de falso positivo quando uma operação legítima e esperada dispara uma regra específica, a aplicação está atualizada, o conteúdo foi validado e não há tentativa de explorar o sistema. O ID da regra, variável correspondente e trecho sanitizado são mais úteis do que apenas “ModSecurity bloqueou”. A decisão deve considerar o risco da rota: login, upload, administração e checkout merecem cautela maior.
Correção preferencial
- Atualize aplicação, tema e plugin e corrija requisições malformadas.
- Evite enviar HTML ou código em campos que não precisam desses dados.
- Faça validação e codificação adequadas na aplicação, sem usar base64 como “solução de segurança”.
- Se o falso positivo persistir, peça análise da regra e exceção de escopo mínimo — por ID, domínio, rota ou parâmetro — quando a política da hospedagem permitir.
- Teste novamente e monitore depois da exceção.
Sobre o botão ModSecurity no cPanel
A interface pode permitir ativar ou desativar o ModSecurity por domínio, dependendo do plano e da política do servidor. Desligá-lo integralmente aumenta a superfície de ataque e não deve ser a primeira solução. Se um teste controlado exigir desativação temporária, faça por intervalo curto, restrinja acesso por outra camada, reproduza uma vez e reative imediatamente.
O que não fazer
- não publicar payload, cookie, token ou dados pessoais;
- não remover todas as regras do
.htaccesssem backup; - não trocar 403 por permissão
777; - não repetir muitas vezes uma requisição bloqueada, pois isso pode acionar proteção adicional;
- não criar exceção genérica para todo o site quando uma rota específica é suficiente.
Dados para o suporte
Envie domínio, URL/caminho, horário com fuso, IP público, método (GET/POST), resultado esperado, status recebido e passos mínimos para reproduzir. Informe se há CDN. Relacione o diagnóstico com erro 403, permissões corretas de arquivos, IP bloqueado e logs do cPanel.
Referências oficiais: cPanel — ModSecurity e OWASP ModSecurity Core Rule Set.
Recursos relacionados
Continue com tutoriais, ferramentas e serviços relacionados ao diagnóstico.
Assistente IA WGS