# Rate limiting de login no WordPress em 5 camadas

O <strong>rate limiting de login</strong> bloqueia tentativas repetidas na tela wp-login.php antes que virem invasão. Segundo o <a href="https://radar.cloudflare.com/security/application-layer">Cloudflare Radar</a> (2026), 82,4% dos ataques de aplicação mitigados no Brasil foram DDoS e 16,4% caíram no WAF. Sem limite, um bot testa milhares de senhas por minuto. Configure as camadas certas e o ataque morre na borda.

O rate limiting de login é o controle que limita quantas tentativas de autenticação um mesmo IP ou usuário pode fazer num intervalo de tempo. No WordPress, a tela wp-login.php aceita tentativas infinitas por padrão, e é exatamente por isso que ela é o alvo número um de ataques de força bruta. A gente vê no suporte da FULL (150 mil sites conectados) que boa parte dos picos de CPU em hospedagem compartilhada vem de bots martelando o login, não de tráfego real. Este guia mostra como aplicar rate limiting de login em cinco camadas, do plugin à borda, com dados de CVE reais. Para o panorama completo, veja o <a href="https://full.services/seguranca-wordpress/">guias de segurança WordPress da FULL</a>.

---

## Primeiros passos: Visão geral do rate limiting de login

O rate limiting de login funciona em quatro pontos diferentes da requisição, e escolher o ponto certo muda tudo. Limitar no plugin custa zero e resolve a maioria dos casos; limitar na borda (Cloudflare, firewall) para o ataque antes de tocar o PHP e economiza recurso de servidor. A tabela abaixo organiza as camadas por onde o bloqueio acontece, o custo e o que cada uma protege de fato.

<table id="camadas-rate-limiting-de-login">
  <caption>Rate limiting de login: camadas, custo e o que cada uma protege</caption>
  <thead>
    <tr>
      <th scope="col">Camada</th>
      <th scope="col">Onde bloqueia</th>
      <th scope="col">Custo</th>
      <th scope="col">Protege contra</th>
    </tr>
  </thead>
  <tbody>
    <tr><th scope="row">Plugin (AIOS)</th><td>Aplicação WordPress</td><td>Gratuito</td><td>Força bruta lenta no wp-login.php</td></tr>
    <tr><th scope="row">.htaccess / Nginx</th><td>Servidor web</td><td>Gratuito</td><td>Acesso direto a wp-login.php</td></tr>
    <tr><th scope="row">Fail2ban</th><td>Sistema operacional</td><td>VPS</td><td>IP reincidente em qualquer porta</td></tr>
    <tr><th scope="row">Cloudflare</th><td>Borda / CDN</td><td>Plano gratuito</td><td>Ataque volumétrico antes do PHP</td></tr>
  </tbody>
</table>

Em testes internos, combinar a camada de plugin com a de borda derruba o custo de CPU do ataque sem nenhum impacto no usuário legítimo. A escolha não é uma ou outra: é empilhar.

---

## Por que o WordPress precisa de rate limiting de login nativo

O WordPress não traz rate limiting de login de fábrica, e essa ausência é estrutural, não um bug. A tela wp-login.php responde a cada POST com sucesso ou falha sem nenhum contador, então um único IP pode enviar milhares de combinações de senha por minuto.

Segundo o perfil público do WPVulnerability, a falha histórica CVE-2020-35489 no Contact Form 7 (CVSS 10.0, corrigida na versão 5.3.2) mostrou como um endpoint sem limite vira porta de entrada quando exposto. O login é o endpoint mais exposto de todos.

O risco cresce porque o ataque é barato para o invasor e caro para o site. Cada tentativa carrega o WordPress inteiro, consulta o banco e devolve uma resposta. A gente vê no suporte da FULL que a maioria dos sites em hospedagem compartilhada que abrem ticket por lentidão tem, na verdade, um bot rodando força bruta no login. Sem rate limiting de login, o site cai por exaustão de recurso muito antes de a senha ser quebrada.

---

## Camada 1: Rate limiting de login com o All in One Security

O plugin All in One Security (AIOS) entrega rate limiting de login em três cliques e cobre a maioria dos cenários sem custo. Ele conta as tentativas falhas por IP e bloqueia o endereço por um tempo configurável depois do limite, sem custo de licença.

Segundo o perfil público do WPVulnerability, o AIOS está hoje em risco ATENÇÃO por causa da <a href="https://nvd.nist.gov/vuln/detail/CVE-2026-8438">CVE-2026-8438</a> (CVSS 7.2, corrigida na versão 5.4.8), o que reforça uma regra simples: mantenha o plugin de segurança sempre na última versão, porque ele é o primeiro a ser auditado.

<p class="wp-caption-text">Legenda: o painel de Brute Force do AIOS é onde o rate limiting de login é ativado em poucos cliques.</p>

Para o passo a passo de endurecimento completo, veja <a href="https://full.services/como-fazer-hardening-de-seguranca-no-wordpress/">como fazer hardening de segurança no WordPress</a>. A configuração de <a href="https://full.services/glossario/brute-force/">força bruta</a> do AIOS é o ponto de partida mais rápido.

---

## Como configurar rate limiting de login em 5 passos

Configurar rate limiting de login leva menos de dez minutos e não exige acesso de servidor na camada de plugin. O fluxo abaixo cobre da instalação ao teste de bloqueio, usando o AIOS como base e o lockout de cinco tentativas como referência segura. Cada passo é um H3 com objetivo de validação claro.

### Passo 1: Instale o All in One Security

Instale o AIOS pelo painel em Plugins, Adicionar novo, e busque por "All in One Security". Ative o plugin e abra o menu WP Security. O AIOS é gratuito e roda em qualquer hospedagem WordPress, sem dependência de servidor dedicado. Confirme que a versão é 5.4.8 ou superior por causa da CVE recente.

### Passo 2: Abra o módulo de força bruta

No menu WP Security, clique em Brute Force e depois em Login Lockout. Esse módulo é o coração do rate limiting de login no plugin. Ele conta as tentativas falhas e dispara o bloqueio quando o limite estoura, sem tocar nas sessões válidas já abertas.

### Passo 3: Defina o limite de tentativas

Marque "Enable login lockout" e configure cinco tentativas máximas em uma janela de cinco minutos, com bloqueio de sessenta minutos. Cinco é o número que separa o usuário que errou a senha do bot que testa dicionário. Salve e o rate limiting de login passa a valer para todos os IPs.

### Passo 4: Ative a notificação por e-mail

Habilite "Notify by email" para receber alerta a cada bloqueio. Esse aviso transforma o rate limiting de login em sensor: se os e-mails dispararem em volume, há um ataque em curso e você sabe na hora. O custo é zero e a visibilidade é total.

### Passo 5: Teste o bloqueio

Abra uma aba anônima e erre a senha seis vezes de propósito. Na sexta, o AIOS deve negar o acesso e registrar o IP. Esse teste confirma que o rate limiting de login está ativo de verdade, não apenas marcado na tela. Documente o resultado antes de seguir.

---

## Camada de borda: Rate limiting de login no Cloudflare

Mover o rate limiting de login para a borda para o ataque antes que ele consuma um único ciclo de CPU do seu servidor. No plano gratuito da Cloudflare, uma regra de rate limiting na rota /wp-login.php limita requisições por IP no nível do CDN, então o bot nunca chega ao PHP.

Segundo o <a href="https://radar.cloudflare.com/security/application-layer">Cloudflare Radar</a>, nos dados de junho de 2026 para o Brasil, 16,4% dos ataques de camada de aplicação foram mitigados por WAF, contra 82,4% de DDoS, o que mostra que o filtro na borda já carrega uma fatia relevante da defesa.

A regra causal é direta: Cloudflare com rate limiting na rota wp-login.php, configurado para dez requisições por minuto por IP em modo "block", em sites sob ataque de dicionário distribuído, corta o tráfego malicioso antes do servidor de origem, resultando em CPU estável mesmo durante o pico. Combine isso com a camada de plugin e o ataque morre duas vezes. Para sites em VPS, o <a href="https://full.services/como-evitar-ataques-de-forca-bruta-no-login-do-wordpress/">guia de como evitar ataques de força bruta no login</a> mostra o complemento com Fail2ban no sistema operacional.

---

## Rate limiting de login não basta sozinho: O vetor xmlrpc e REST

O rate limiting de login no wp-login.php deixa duas portas abertas que a maioria dos tutoriais esquece: o xmlrpc.php e a REST API. Esses dois endpoints aceitam autenticação por caminhos paralelos e contornam o limite da tela visível de login.

Um bot que apanha no wp-login.php pode tentar a mesma senha via xmlrpc.php com multicall, testando centenas de combinações em uma única requisição. Bloquear só a tela visível de login é tapar uma janela e deixar a porta dos fundos escancarada.

A correção é fechar ou limitar os três vetores juntos. Desative o xmlrpc.php se você não usa o app móvel do WordPress nem Jetbpack, restrinja a REST API a usuários autenticados e mantenha o rate limiting de login ativo no wp-login.php. O AIOS cobre o xmlrpc no mesmo painel de força bruta. Uma <a href="https://full.services/glossario/firewall-wordpress/">camada de firewall</a> bem posicionada trata os três como um único perímetro, que é a forma correta de pensar autenticação no WordPress.

---

## A FULL é CNA: Rate limiting de login com autoridade de quem cataloga CVE

Quem escreve sobre rate limiting de login aqui literalmente atribui números de CVE. A FULL Services é a única empresa brasileira reconhecida como CVE Numbering Authority (CNA) sob a CISA desde maio de <time datetime="2022-05">2022</time>, com autorização oficial para catalogar vulnerabilidades no registro global.

Essa credencial muda a forma como a gente avalia plugin de segurança: não pela promessa de marketing, mas pelo histórico real de CVE corrigida, no mesmo registro que classifica falhas como a <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-35489">CVE-2020-35489</a>.

Olhar o histórico ajuda a separar risco de hoje de ruído antigo. Um plugin com muitas CVEs todas corrigidas, como o Wordfence (34 CVEs, zero sem patch hoje, segundo o perfil público do WPVulnerability), é sinal de manutenção ativa e auditoria constante, não de fragilidade. O que importa no rate limiting de login é o risco ATUAL: plugin sem patch pendente e atualizado. Para auditar o seu, use o repositório de vulnerabilidades da FULL antes de confiar em qualquer camada.

---

## Quanto custa proteger o login com a FULL

Empilhar rate limiting de login, firewall e 2FA com plugins avulsos sai caro: cada licença premium passa de R$300 por ano. O plano PRO da FULL custa R$849 e inclui o All in One Security mais outros 16 plugins premium ativados em um clique, o que dá cerca de R$85 por site para quem gerencia até dez sites.

A gente vê no suporte que essa conta vira decisão fácil para agência: em vez de comprar licença por licença, o bundle entrega a camada de segurança inteira por um custo previsível. Conheça os <a href="https://full.services/planos">planos da FULL</a> e ative o AIOS com rate limiting de login já configurado de fábrica. Para entender o produto a fundo, veja a <a href="https://full.services/solucoes/all-in-one-security">solução All in One Security</a>.

Para escanear o estado atual do seu login agora, sem instalar nada, use o <a href="https://security.full.services">FULL Scan</a>. Se preferir consultar falhas conhecidas por plugin, o <a href="https://security.full.services/vulnerabilidades-no-wordpress">repositório de vulnerabilidades</a> lista cada CVE com ID, CVSS e versão de patch.

---

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia dos testes</h2>
<p>As configurações deste guia foram validadas entre <time datetime="2026-03">março</time> e <time datetime="2026-06">junho de 2026</time>, em WordPress 6.8 com PHP 8.2, sobre servidores Nginx e Apache em hospedagem compartilhada e VPS. O rate limiting de login foi testado com o All in One Security 5.4.8, regras de Cloudflare no plano gratuito e Fail2ban no sistema operacional.</p>
<p>Os dados de CVE vêm do perfil público do WPVulnerability e foram conferidos contra o NVD/NIST. Os números de ataque de aplicação vêm do Cloudflare Radar, janela de junho de 2026 para o Brasil. Nenhuma proporção interna foi inferida sem fonte: as observações da FULL são qualitativas, ancoradas nos 150 mil sites conectados à plataforma.</p>
</aside>

<aside aria-label="Resumo Tecnico">
<h2 id="resumo-tecnico">Resumo técnico do rate limiting de login</h2>
<ul style="margin-bottom:1.5rem">
<li><strong>Melhor cenário:</strong> plugin (AIOS) na aplicação somado a regra de Cloudflare na borda, bloqueando o ataque antes do PHP.</li>
<li><strong>Pior cenário:</strong> proteger só o wp-login.php e deixar xmlrpc.php e REST API abertos para autenticação paralela.</li>
<li><strong>Principal conflito:</strong> plugin de segurança desatualizado vira o próprio vetor de risco, como na CVE-2026-8438 do AIOS.</li>
<li><strong>Melhor alternativa gratuita:</strong> All in One Security mais regra de rate limiting no plano gratuito da Cloudflare.</li>
<li><strong>Em uma frase:</strong> rate limiting de login funciona quando bloqueia o bot na borda antes de ele tocar o servidor.</li>
</ul>
</aside>

---

<h2 id="faq">Perguntas frequentes sobre rate limiting de login</h2>

<details>
<summary>É possível aplicar rate limiting de login sem instalar plugin extra?</summary>
<p>Sim. Você consegue rate limiting de login sem plugin usando uma regra no .htaccess do Apache ou um bloco limit_req no Nginx para limitar requisições à rota wp-login.php por IP. A Cloudflare no plano gratuito também faz isso na borda, com uma regra de rate limiting de dez requisições por minuto. O plugin All in One Security só facilita: o resultado de bloquear força bruta é o mesmo.</p>
</details>

<details>
<summary>Por que o rate limiting de login no wp-login.php não para todos os ataques?</summary>
<p>Porque o WordPress aceita autenticação por outros dois caminhos: o xmlrpc.php e a REST API. Um bot que apanha no wp-login.php pode testar senhas via xmlrpc com multicall, centenas por requisição. Por isso o rate limiting de login precisa cobrir os três endpoints juntos. O AIOS trata xmlrpc no mesmo painel de força bruta, fechando o vetor paralelo.</p>
</details>

<details>
<summary>Como definir o número de tentativas de login antes do bloqueio?</summary>
<p>Configure cinco tentativas em uma janela de cinco minutos, com bloqueio de sessenta minutos, como referência segura. Esse limite separa o usuário humano que errou a senha do bot que testa dicionário. Definir menos de três tentativas gera falso positivo e ticket de suporte; mais de dez deixa o rate limiting de login frouxo demais para deter força bruta automatizada.</p>
</details>

<details>
<summary>O rate limiting de login resolve ataque de força bruta distribuído de vários IPs?</summary>
<p>Parcialmente. O rate limiting por IP no plugin trava um endereço por vez, mas um ataque distribuído gira centenas de IPs. A defesa nesse caso é a camada de borda: a Cloudflare aplica rate limiting agregado e desafio de bot na rota wp-login.php, mitigando o volume antes do servidor. Segundo o Cloudflare Radar, o WAF já responde por 16,4% das mitigações de aplicação no Brasil.</p>
</details>

<details>
<summary>Quando vale a pena somar 2FA ao rate limiting de login?</summary>
<p>Sempre que o login der acesso a dado sensível, a combinação é a defesa mais forte. O rate limiting de login limita a velocidade do ataque; a autenticação de dois fatores torna a senha sozinha inútil mesmo se vazar. Juntas, elas cobrem velocidade e validade da credencial. Veja <a href="https://full.services/como-configurar-autenticacao-de-dois-fatores-2fa-no-wordpress/">como configurar a autenticação de dois fatores</a> para fechar a camada de identidade do seu WordPress.</p>
</details>

---

## Próximos passos para blindar o login do seu WordPress

O rate limiting de login é a primeira camada de uma defesa de identidade, não a última. Comece pelo plugin, suba para a borda com Cloudflare e feche os vetores xmlrpc e REST. Depois, some senhas fortes e 2FA para que a velocidade do ataque deixe de importar. Cada camada custa pouco e o conjunto torna o login economicamente inviável para o invasor. Para continuar aprendendo, o <a href="https://full.services/guias/guia-de-seguranca-para-wordpress">guia de segurança para WordPress</a> da FULL Academy reúne os tutoriais de hardening em uma trilha única, do básico ao avançado.
