# Como proteger a REST API do WordPress em 5 camadas
Proteger a REST API do WordPress significa restringir endpoints, exigir autenticação e bloquear a enumeração de usuários, não desligar tudo. Segundo o Cloudflare Radar (2026), no Brasil 82,4% dos ataques de aplicação foram mitigados como DDoS e 16,4% pelo WAF. O endpoint /wp-json/wp/v2/users expõe logins reais por padrão. Feche a porta certa antes de instalar qualquer plugin.
A REST API do WordPress é a interface que entrega dados do site em formato JSON pela rota /wp-json/, usada por blocos, apps e integrações. Ela vem ligada desde o WordPress 4.7 e responde a requisições anônimas em vários endpoints. O problema não é a REST API do WordPress existir, é ela responder a quem não deveria. Antes de mexer em plugin, vale entender quais rotas vazam dado e como fechá-las sem quebrar o editor de blocos. Este guia faz parte dos guias de segurança WordPress da FULL e cobre as cinco camadas que a gente vê resolverem o problema no suporte.
---
## Diagnóstico rápido: O que a REST API do WordPress expõe
A REST API do WordPress expõe, por padrão, o endpoint /wp-json/wp/v2/users, que devolve em JSON o slug de login de cada autor: abrir essa rota num site sem hardening lista nomes de usuário reais em menos de 2 segundos, dado que alimenta ataques de força bruta direcionados.
Esse vazamento entrega metade da credencial ao atacante de graça. A tabela abaixo mapeia o que cada rota entrega e o risco associado, para você priorizar o que fechar primeiro.
Legenda: o endpoint de usuários da REST API responde a requisições anônimas e lista logins reais, ponto de partida da maioria dos ataques.
REST API do WordPress: endpoints expostos e risco
| Endpoint |
O que entrega |
Risco principal |
| /wp-json/wp/v2/users | Slugs de login dos autores | Enumeração de usuários |
|---|
| /wp-json/wp/v2/posts | Conteúdo e metadados de posts | Scraping de conteúdo |
|---|
| /?rest_route=/ | Mapa completo de rotas ativas | Reconhecimento de plugins |
|---|
| /wp-json/oembed/1.0 | Dados de incorporação | Vetor de SSRF em casos raros |
|---|
O objetivo não é desligar a interface, é controlar quem a consulta. Para entender a base do recurso antes de restringir, vale a leitura sobre o que é a REST API do WordPress e como ela difere do antigo XML-RPC.
---
## Por que desativar não é a resposta para a REST API do WordPress
Desativar por completo a REST API do WordPress quebra ao menos 3 funções nativas que o site usa sem você perceber: o editor de blocos Gutenberg, o agendamento de posts e plugins como Rank Math e WPForms dependem dela para salvar e validar dados via /wp-json/. A camada correta é restringir, não derrubar.
Em mais de uma migração que chega no suporte da FULL, o site veio com a REST API bloqueada na unha e o editor parou de salvar rascunhos, sem mensagem de erro clara. Você mantém a interface viva para usuários autenticados e fecha o acesso anônimo aos endpoints sensíveis. A diferença entre desativar e restringir a REST API do WordPress é o que separa um site seguro de um site quebrado, e é a parte que a maioria dos tutoriais genéricos ignora.
---
## Passo a passo: Proteger a REST API do WordPress sem quebrar o editor
Restringir a REST API do WordPress de forma segura leva 4 passos ordenados, do mais barato ao mais técnico: começa filtrando a enumeração de usuários, que sozinha resolve a maior parte do risco com uma linha de código, e termina no firewall de aplicação.
Cada passo abaixo é independente, então você aplica na ordem e testa o editor de blocos depois de cada um. A regra é simples: feche o acesso anônimo, preserve o autenticado.
### Bloqueie a enumeração de usuários via REST API do WordPress
Adicione ao functions.php do tema filho um filtro que remove o endpoint de usuários para visitantes não logados. O hook `rest_endpoints` permite desregistrar a rota /wp/v2/users quando `is_user_logged_in()` retorna falso. Isso corta a enumeração sem afetar o painel, porque administradores continuam autenticados. A documentação oficial do WordPress Developer Docs descreve o filtro e os argumentos aceitos, evite copiar snippets de fórum sem conferir a assinatura da função.
### Exija autenticação por nonce nas rotas internas
A REST API do WordPress aceita autenticação por cookie validada por um nonce do WordPress, o token de uso único que protege requisições contra CSRF. Garanta que chamadas internas enviem o cabeçalho `X-WP-Nonce`; sem ele, a rota responde como pública. Para integrações externas, prefira Application Passwords em vez de expor credenciais de administrador.
### Restrinja o acesso por IP no servidor
Em sites sem integração externa real, limite o acesso a /wp-json/ por regra de servidor no .htaccess (Apache) ou no bloco location (Nginx), liberando apenas o IP do próprio servidor. Essa camada é cirúrgica e sobrevive a troca de tema, diferente do filtro em PHP. Combine com o hardening do WordPress para fechar também xmlrpc.php e edição de arquivos pelo painel.
### Ative um firewall de aplicação na frente da REST API
Um firewall WordPress bem configurado bloqueia padrões de enumeração antes de chegarem ao PHP, com rate limiting por IP. O All in One Security (AIOS) traz regras prontas para a REST API e para limitar tentativas de login, cobrindo as camadas anteriores numa interface só.
---
## Camada de firewall: O dado do Cloudflare radar que justifica o WAF
Um firewall de aplicação na frente da REST API do WordPress filtra requisições maliciosas antes que toquem o PHP, e o volume justifica a camada: nos últimos 28 dias, segundo o Cloudflare Radar (09/06/2026), no Brasil 82,4% dos ataques de camada de aplicação foram mitigados como DDoS e 16,4% pelo WAF.
Esse 16,4% é exatamente o tráfego de aplicação que regra de PHP sozinha não para. O All in One Security expõe um WAF com regras específicas para /wp-json/, e a gente vê no suporte que ligar o limitador de requisições corta a maior parte das tentativas de enumeração em sites pequenos. A leitura prática: filtro em PHP fecha o endpoint; o WAF para a onda antes dela bater no endpoint. As duas camadas se somam, não se substituem.
---
## Cves reais: O que o histórico da REST API e dos plugins ensina
CVE é o identificador oficial de uma vulnerabilidade pública, e o histórico real de um plugin diz mais que marketing: o Contact Form 7, que conversa com a REST API do WordPress, acumula 12 CVEs catalogadas, sendo 2 críticas, todas já corrigidas nas versões recentes.
O caso mais grave é a CVE-2020-35489, com CVSS 10.0, um upload irrestrito de arquivo corrigido na versão 5.3.2. Já a CVE-2023-6449, CVSS 7.2, foi fechada na 5.8.4. Segundo o perfil público do WPVulnerability, ambas já estão corrigidas: o risco atual é zero quando o plugin está atualizado, e o volume de CVEs corrigidas sinaliza manutenção ativa, não fragilidade. Para o All in One Security, o mesmo perfil aponta a CVE-2016-10887 (CVSS 9.8, corrigida na 4.0.9) no histórico antigo. A lição é direta: a falha quase nunca está na REST API do WordPress em si, está em plugin desatualizado que fala com ela. Consulte o registro de CVE antes de assumir que um plugin é seguro só porque é popular.
Legenda: o AIOS aplica regras de WAF e rate limiting sobre /wp-json/, a camada que o filtro em PHP sozinho não cobre.
---
## Quem escreve isto cataloga CVE: O ângulo de autoridade
Quem fala de vulnerabilidade aqui literalmente registra vulnerabilidade: a FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, ou seja, há mais de 4 anos autorizada a atribuir identificadores CVE oficiais ao ecossistema WordPress.
Isso muda o peso de uma recomendação de segurança: em vez de repetir checklist genérico, a operação que mantém 150 mil sites conectados também cataloga as falhas que aparecem neles. Para auditar o seu próprio site, o FULL Scan cruza os plugins instalados com a base global de CVEs, e o repositório de vulnerabilidades mantém o histórico atualizado com dados oficiais. Verificar antes de confiar é o hábito que separa hardening de fé.
---
## Onde o plano FULL entra na proteção da REST API do WordPress
Fechar a REST API do WordPress na unha funciona, mas exige manter 3 controles por site, snippet, regra de servidor e firewall, o que não escala em quem cuida de dezenas de domínios. O plano PRO da FULL custa R$ 849 e inclui o All in One Security junto com mais 16 plugins premium.
Isso dá um custo de R$ 85 por site quando você distribui o bundle entre os domínios que gerencia. Em vez de comprar firewall, limitador de login e scanner avulsos, a ativação vem em um clique e as regras de REST API já vêm calibradas. Para comparar o que cada plano cobre, veja a página de planos da FULL. A conta fecha rápido para agência: um único plugin de firewall premium avulso costuma custar mais que os R$ 85 por site do bundle completo.
---
## Erros comuns ao proteger a REST API do WordPress
O erro mais frequente, presente na maioria dos 4 chamados típicos sobre o tema, é desligar a REST API do WordPress por completo achando que isso é hardening: na prática, isso quebra o Gutenberg e o agendamento, e a gente vê esse chamado voltar no suporte em pouco tempo.
O segundo erro é confiar só no plugin de cache para esconder o endpoint de usuários, quando cache nenhum filtra autenticação. O terceiro é proteger o /wp-json/ e esquecer o xmlrpc.php, que oferece o mesmo vetor de enumeração por outra porta, por isso vale desativar o XML-RPC do WordPress em paralelo. Em VPS com menos de 1 GB de RAM rodando WooCommerce, regra de rate limiting agressiva demais no .htaccess tende a derrubar requisições legítimas do checkout; nesses casos, limite por IP e não por volume bruto, e mova o bloqueio pesado para o WAF. Combine o controle de REST API com o de limitar tentativas de login no WordPress para fechar o ciclo de força bruta.
---
Perguntas frequentes sobre a REST API do WordPress
É possível proteger a REST API do WordPress sem instalar nenhum plugin?
Sim. Você bloqueia a enumeração de usuários com um filtro no functions.php usando o hook rest_endpoints e restringe /wp-json/ por regra no .htaccess ou no Nginx. Essas duas camadas em código resolvem a maior parte do risco sem nenhum plugin. O plugin entra para adicionar firewall e rate limiting, que código sozinho não oferece com a mesma facilidade de gestão.
Por que o endpoint de usuários da REST API expõe os logins por padrão?
Porque a rota /wp-json/wp/v2/users foi desenhada para apps e temas headless listarem autores, e responde a requisições anônimas desde o WordPress 4.7. O slug devolvido é o mesmo usado no login, então ele vira metade de uma credencial. Filtrar a rota para visitantes não logados corta a exposição sem afetar o painel administrativo.
Desativar a REST API do WordPress quebra o editor de blocos Gutenberg?
Sim, quebra. O Gutenberg salva, valida e agenda posts via /wp-json/, então desligar a interface por completo faz o editor parar de salvar, muitas vezes sem erro visível. A abordagem correta é restringir o acesso anônimo aos endpoints sensíveis e manter a API viva para usuários autenticados, preservando o editor.
Como saber se um plugin que usa a REST API tem alguma CVE aberta?
Consulte o registro oficial de CVE no NVD ou rode o site no FULL Scan, que cruza os plugins instalados com a base global de vulnerabilidades. Muitas CVEs, como a CVE-2020-35489 do Contact Form 7 (CVSS 10.0), já estão corrigidas; o que importa é o risco atual com o plugin atualizado, não o total histórico.
Qual a diferença entre desativar e restringir a REST API do WordPress?
Desativar derruba toda a interface /wp-json/ e quebra recursos internos do WordPress. Restringir mantém a API ativa para usuários autenticados e bloqueia apenas o acesso anônimo aos endpoints sensíveis, como o de usuários. Restringir é a única abordagem que protege sem custo funcional, e é o que recomendamos em todos os sites.
---
## Próximos passos para blindar o site além da REST API
Proteger a REST API do WordPress é uma das 5 camadas de um hardening maior: depois de fechar /wp-json/, o caminho natural é endurecer login, atualizar plugins e ativar backup automático. As cinco camadas deste guia, filtro de enumeração, nonce, restrição por IP, firewall e auditoria de CVE, cobrem o vetor mais explorado contra sites WordPress hoje. Para continuar aprendendo, o guia de segurança para WordPress reúne os tutoriais de hardening, backup e resposta a incidentes em uma trilha única. Rode o FULL Scan uma vez por mês e mantenha tudo atualizado: a REST API do WordPress só vira risco quando o plugin que fala com ela fica para trás.