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.