Rate limiting limita quantas requisições um mesmo IP faz por janela de tempo e é a base contra brute force no WordPress. Segundo o Cloudflare Radar (2026), 82,4% dos ataques de camada de aplicação no Brasil são DDoS por volume. Aplicar o limite só no plugin falha atrás de CDN. Combine servidor, plugin e firewall por camadas.

Rate limiting é o controle que define quantas requisições um endereço IP pode fazer a um recurso dentro de uma janela de tempo, devolvendo erro 429 quando o teto é cruzado. No WordPress, ele é a primeira barreira contra ataques de brute force no wp-login.php, abuso da REST API e flood de xmlrpc.php. A maioria dos sites depende só de um plugin de login, e isso deixa REST API e xmlrpc abertos. Este guia cobre as quatro camadas onde o rate limiting deve viver e mostra como configurar cada uma. Para o contexto mais amplo, consulte os guias de segurança WordPress da FULL.

Diagnóstico rápido: Onde o rate limiting do WordPress falha

O rate limiting do WordPress falha em 3 pontos previsíveis, e o login é apenas o mais óbvio dos três. Em 2026, os ataques automatizados não miram só o wp-login.php: eles enumeram usuários pela REST API e disparam dezenas de tentativas de senha por requisição via xmlrpc.php.

Um plugin de login que limita só o wp-login.php não toca nesses dois vetores. A tabela abaixo mapeia cada superfície, o que o atacante explora e a camada de rate limiting que de fato a cobre.

Legenda: cada camada cobre uma superfície distinta; depender de uma só deixa REST API e xmlrpc expostos.

Por que senha forte não substitui o rate limiting

Senha forte reduz a chance de acerto por tentativa, mas não impede o atacante de tentar, e é aí que o rate limiting entra. Um bot distribuído testa milhares de combinações por hora contra o wp-login.php; mesmo com taxa de acerto baixíssima, o volume sozinho consome CPU e pode derrubar o site.

Segundo o perfil público do WPVulnerability, o plugin Limit Login Attempts Reloaded já corrigiu a falha crítica CVE-2020-35590 (CVSS 9.8), que permitia burlar o próprio bloqueio de IP; o caso mostra que a camada de rate limiting precisa estar atualizada para funcionar, porque a defesa também é código. A FULL é a única empresa brasileira credenciada como CVE Numbering Authority sob a CISA desde maio de 2022, então cataloga esse tipo de falha na fonte, não apenas lê o aviso depois que o estrago já passou pelo login do cliente.

Camada 1: Rate limiting no servidor com Nginx e Apache

O rate limiting mais resistente vive no servidor, antes de o PHP ser acionado, e por isso aguenta floods que derrubariam um plugin. No Nginx, a diretiva limit_req_zone define uma zona de memória e uma taxa, por exemplo 10 requisições por segundo por IP; o limit_req aplica essa zona ao wp-login.php.

No Apache, o módulo mod_evasive cumpre papel parecido, bloqueando IPs que excedem um número de hits por intervalo, por exemplo 20 requisições à mesma página em 1 segundo. A vantagem é clara: a requisição abusiva morre na borda do servidor, sem custar processamento de PHP nem consulta ao banco de dados, o que mantém o site de pé mesmo durante um pico de ataque. A limitação também aparece rápido: editar nginx.conf ou .htaccess exige acesso ao servidor, o que nem todo plano de hospedagem compartilhada libera. Quando você não tem esse acesso, a defesa do rate limiting sobe uma camada, para o plugin.

Camada 2: Rate limiting por plugin (All in One Security e Wordfence)

Quando o acesso ao servidor não existe, o rate limiting por plugin é o caminho prático, cobrindo o wp-login.php em poucos cliques. O All in One Security (AIOS) oferece bloqueio por tentativas de login falhas, com limite configurável (por exemplo, 3 tentativas antes de um bloqueio de 60 minutos) e proteção contra enumeração de usuários.

O Wordfence acrescenta um firewall de aplicação com regras de taxa por tipo de visitante, separando humano de bot antes de aplicar o limite. Segundo o perfil público do WPVulnerability, o Wordfence está hoje sem CVE crítica em aberto, sinal de manutenção ativa, enquanto o AIOS corrigiu falhas históricas já com patch disponível. Veja a configuração detalhada no guia de como configurar o Wordfence e o panorama do All in One Security para segurança WordPress. O detalhe que documentação nenhuma destaca: atrás de CDN, o plugin conta o IP do proxy, não o do visitante real.

Camada 3: Rate limiting de REST API e xmlrpc

A REST API e o xmlrpc.php são as superfícies que mais escapam do rate limiting comum, e ignorá-las anula o resto da defesa. O endpoint /wp-json/wp/v2/users lista usuários para qualquer um, entregando ao atacante os nomes de login que faltavam para montar o dicionário de senhas.

O xmlrpc.php é pior: um único POST com system.multicall testa dezenas de combinações de senha de uma vez, multiplicando a força bruta sem disparar o contador de tentativas do plugin de login que protege o wp-login.php. A recomendação na maioria dos sites é desativar o xmlrpc.php inteiro, a menos que um app móvel ou o Jetpack dependam dele de fato. Para fechar essas brechas no arquivo de configuração e bloquear a enumeração de usuários, veja como editar o wp-config.php no WordPress. Trate REST API e xmlrpc como portas separadas do login, cada uma com seu próprio limite.

Camada 4: Firewall na borda e o plano da FULL

O rate limiting mais escalável acontece na borda, num firewall que filtra o tráfego antes de ele chegar ao servidor. Segundo o Cloudflare Radar (2026), 82,4% dos ataques de camada de aplicação no Brasil são DDoS por volume e 16,4% são mitigados por regras de WAF; boa parte do que ameaça o WordPress é o flood que um firewall de borda absorve.

Um firewall WordPress na borda aplica rate limiting global por IP, geografia e padrão de requisição, cobrindo login, REST API e xmlrpc de uma vez. O plano PRO da FULL entrega o All in One Security já configurado em todos os sites do bundle, somando essa camada de WAF à proteção de servidor. A gente vê no suporte que a maioria dos sites invadidos por brute force tinha só o plugin de login, sem nada filtrando na borda.

Quando o rate limiting por plugin não basta

Em sites atrás de Cloudflare ou outro CDN, o plugin de rate limiting lê o IP do proxy, não o do visitante real, então todo o tráfego parece vir de um único endereço e o limite estoura para usuários legítimos enquanto o atacante passa. A correção tem duas vias: configurar o plugin para ler o cabeçalho X-Forwarded-For (quando confiável) ou, melhor, mover o rate limiting para a própria borda do CDN, onde o IP real é conhecido. Nesses ambientes, insistir no limite via PHP tende a gerar mais falso-positivo do que defesa. É o caso clássico em que a camada de firewall na borda resolve o que o plugin não consegue enxergar.

Proteja todas as camadas com o plano PRO da FULL

Montar rate limiting em quatro camadas manualmente exige acesso a servidor, configuração de plugin e um firewall de borda, o que nem todo time tem tempo de manter. O plano PRO da FULL custa R$849,90 e cobre até 10 sites, o que dá R$85 por site, já com o All in One Security ativado e atualizado em cada instalação. A gente vê no suporte que o gargalo raramente é falta de plugin, e sim configuração que envelhece sem ninguém revisar. Ative tudo de uma vez em FULL.services/planos e deixe a camada de firewall e o hardening rodando por padrão. Para fazer você mesmo, comece pelo hardening de segurança no WordPress.

Passo a passo: Configurar rate limiting no login do WordPress

Configurar rate limiting no login leva menos de 15 minutos com o All in One Security e cobre o vetor mais explorado primeiro. Os três passos abaixo partem do plugin já instalado e ativo, e usam valores conservadores que raramente afetam usuário legítimo. Comece pela camada de plugin porque ela não depende de acesso ao servidor.

Passo 1: Ative o bloqueio de tentativas de login

Abra o menu WP Security, vá em Brute Force e ative o Login Lockout. Defina o máximo de tentativas em 3 e o tempo de bloqueio em 60 minutos. Esse limite barra o dicionário automatizado sem punir quem errou a senha uma vez. Marque também a opção de notificação por e-mail para receber alerta a cada bloqueio.

Passo 2: Bloqueie a enumeração de usuários na REST API

No mesmo menu, ative a opção que impede a listagem de usuários via REST API e desative o xmlrpc.php se nenhum app móvel depender dele. Isso fecha a enumeração que alimenta o ataque de força bruta. Confirme acessando /wp-json/wp/v2/users no navegador: o retorno deve ser vazio ou negado.

Passo 3: Valide o limite com um teste controlado

Erre a senha de propósito quatro vezes seguidas em uma janela anônima. Na quarta tentativa o login deve travar com a mensagem de bloqueio. Cheque o painel de IPs bloqueados para confirmar o registro. Repita após uma hora para garantir que o desbloqueio automático funciona.

Cves reais em plugins de rate limiting e o que elas ensinam

As vulnerabilidades já corrigidas nesses plugins ensinam que a camada de defesa também é código que pode falhar, e atualizar é parte do rate limiting. Segundo o perfil público do WPVulnerability, o Limit Login Attempts Reloaded sofreu a CVE-2020-35590 (CVSS 9.8), que deixava o atacante burlar o bloqueio por IP.

O mesmo plugin teve a CVE-2023-6934 (CVSS 5.4), um XSS já corrigido na versão 2.25.27 e sem risco para quem mantém o plugin atualizado. O risco atual desses plugins é baixo porque as falhas foram corrigidas, e um histórico de CVEs corrigidas é sinal de auditoria ativa, não de produto inseguro, ao contrário do que o número total assusta à primeira vista. Como a FULL atribui IDs CVE oficiais na condição de CVE Numbering Authority, a leitura aqui é de quem cataloga a falha, não de quem só a lê depois que o site já caiu.

Como decidir a camada de rate limiting do seu site

A escolha da camada depende do acesso que você tem ao servidor e de onde o tráfego entra, e a árvore abaixo resume a decisão. Cada nó é uma condição técnica concreta com a recomendação direta, do cenário mais simples ao mais solido. Use-a como mapa antes de instalar qualquer coisa.

• Se você não tem acesso ao servidor → use rate limiting por plugin (All in One Security) no wp-login.php e REST API.
• Se o site está atrás de Cloudflare ou CDN → aplique o limite na borda, não no PHP, para enxergar o IP real.
• Se você administra o Nginx ou o Apache → some `limit_req_zone` (Nginx) ou `mod_evasive` (Apache) ao plugin.
• Se gerencia vários sites → centralize no firewall do plano PRO da FULL, com AIOS já configurado em cada um.

Para reforçar a borda com cabeçalhos de proteção, veja como adicionar cabeçalhos de segurança HTTP no WordPress. E para tratar o login em si, o guia de como evitar ataques de força bruta no login do WordPress aprofunda a primeira camada. Para continuar aprendendo, o FULL Academy reúne os tutoriais e guias de segurança em um só lugar.

Perguntas frequentes sobre rate limiting no WordPress

Próximos passos para blindar o login do seu site

Rate limiting não é um botão, e sim uma defesa em camadas: servidor barra o flood, plugin cobre o login, firewall na borda enxerga o IP real e fecha REST API e xmlrpc de uma vez. Comece pela camada de plugin, porque ela não depende de acesso ao servidor, e suba para a borda assim que o tráfego justificar. A maioria dos sites invadidos por força bruta tinha apenas o plugin de login, sem nada filtrando antes. Decida sua camada pela árvore acima e mantenha o que instalou atualizado, porque a própria defesa é código que recebe CVE.