A REST API do WordPress vem ligada por padrao e expoe nomes de usuário e dados de conteudo a qualquer visitante. Segundo a OWASP API Security (2023), autorizacao quebrada de objeto e o risco numero 1 de APIs. Proteger exige restringir endpoints, exigir autenticacao e filtrar requisicoes no firewall. Comece pelo endpoint de usuários, o mais explorado por bots.

A REST API do WordPress é a camada que permite ler e gravar conteúdo do site por requisições HTTP em wp-json/, sem passar pelo painel. Desde a versão 4.7, ela vem ativa por padrão em todo WordPress 6.x, o que é ótimo para Gutenberg e aplicativos, mas abre uma superfície que poucos administradores monitoram. O endpoint wp/v2/users lista os autores do site para qualquer um, e essa exposição alimenta ataques de força bruta direcionados. Este guia de guias de segurança WordPress da FULL mostra como blindar a REST API em camadas, com CVEs reais e configuração concreta, sem quebrar o que o site precisa.

Diagnóstico rápido: O que a REST API expõe por padrão

A REST API do WordPress expõe, sem login, 5 grupos de endpoints em wp-json/wp/v2/: usuários, posts, páginas, comentários e taxonomias. O caso mais sensível é wp/v2/users: num WordPress 6.x recém-instalado, ele devolve o nome e o slug de login de cada autor em JSON, pronto para um bot coletar.

A tabela abaixo separa o que cada endpoint entrega e qual o risco real de deixá-lo aberto, para você priorizar a camada certa.

Repare que a raiz wp-json já entrega o mapa de quais plugins registram rotas. Para um atacante, isso é reconhecimento gratuito.

Por que a REST API é um vetor de ataque mesmo sem plugin vulnerável

A REST API vira porta de entrada mesmo num site 100% atualizado porque a enumeração de usuário não depende de falha de código: é comportamento padrão. Nos tickets da FULL, a maioria das invasões que começam pela REST API não usa exploit sofisticado, e sim esse reconhecimento gratuito que o endpoint entrega de graça.

O bot lê wp-json/wp/v2/users, coleta os slugs de autor reais e dispara força bruta só contra esses nomes, em vez de adivinhar logins genéricos. Isso reduz o universo de tentativas em ordens de grandeza e passa despercebido para quem só monitora wp-login.php.

Esse padrão se repete porque a REST API tende a ficar fora do radar de monitoramento na maioria dos ambientes que chegam ao suporte. O administrador trava o login, instala um plugin de segurança, mas esquece que /wp-json/ responde antes de qualquer tela. Vale a leitura do nosso guia sobre como bloquear força bruta no login do WordPress em paralelo a este, porque as duas camadas se reforçam.

Cves reais de REST API e o que eles revelam

A REST API já acumulou CVEs documentados em plugins populares. No Contact Form 7, a CVE-2023-6449 (CVSS 7.2) permitia upload arbitrário de arquivo por requisição à API antes da 5.8.4, e a CVE-2024-2242 (CVSS 6.1) explorava reflexão de input via REST antes da 5.9.2.

Ambas já foram corrigidas: um plugin com muitos CVEs todos com patch é sinal de auditoria ativa, não de abandono. O histórico ensina mais que o alarme.

A FULL fala de CVE com a autoridade de quem cataloga CVE: somos a única empresa brasileira credenciada como CVE Numbering Authority (CNA) sob a CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais. O ponto técnico é distinguir risco atual de histórico. Segundo o perfil público do WPVulnerability, o Contact Form 7 hoje está sem nenhuma falha sem patch, então o risco real está em rodar versões antigas, não no plugin em si.

Como proteger a REST API do WordPress em 5 camadas

Proteger a REST API do WordPress não é desligá-la, e sim aplicar cinco camadas que reduzem a exposição sem quebrar Gutenberg. Na maioria dos sites que passam pelo suporte da FULL, fechar só o endpoint de usuários e ativar um firewall já elimina o vetor mais explorado. Os passos abaixo vão da configuração que qualquer iniciante aplica em minutos até o controle fino de autenticação por requisição.

Passo 1: Restrinja o endpoint wp/v2/users a usuários autenticados

Restringir wp/v2/users a quem está logado corta a enumeração na origem. Plugins como Wordfence e All in One Security oferecem essa opção em um clique; sem plugin, use o filtro rest_endpoints no functions.php para remover a rota de usuários para visitantes anônimos. Validação: abra seusite.com/wp-json/wp/v2/users numa aba anônima e confirme que retorna 401 em vez de JSON com nomes de autor.

Passo 2: Exija nonce ou application password na REST API

Exigir autenticação garante que apenas requisições legítimas escrevam dados. O WordPress usa nonce para chamadas internas do painel e Application Password para integrações externas. Desative Application Passwords não usadas em Usuários, porque uma senha de aplicação vazada dá acesso total à REST API sem passar pela tela de login. Validação: cada Application Password ativa deve ter dono e finalidade conhecidos.

Passo 3: Filtre requisições à REST API no firewall

Filtrar no firewall bloqueia o payload antes de ele chegar ao PHP. Um WAF como o do Wordfence ou o da Cloudflare aplica regras que barram chamadas suspeitas a wp-json/ por taxa e por padrão. De acordo com a documentação da Cloudflare, regras de rate limiting na borda detêm a requisição antes do servidor de origem, o que reduz carga e tentativa de exploração. Validação: cheque os logs do WAF e confirme bloqueios em /wp-json/wp/v2/users.

Passo 4: Mantenha plugins que registram rotas REST sempre atualizados

Manter plugins atualizados fecha os CVEs de REST API antes que bots os explorem. A telemetria do ecossistema mostra que falhas com CVE público costumam ser varridas por bots em poucas horas após a divulgação. Priorize a atualização de plugins que registram rotas, como Contact Form 7, Yoast SEO e Wordfence. Validação: rode o FULL Scan e confirme que nenhum plugin com CVE sem patch está ativo.

Passo 5: Adicione cabeçalhos HTTP e monitore o tráfego em wp-JSON

Adicionar cabeçalhos de segurança e log fecha a quinta camada e dá visibilidade. Cabeçalhos como X-Content-Type-Options e uma política de CORS restritiva limitam quem consome a REST API de fora. Combine com monitoramento de wp-json/ no log de acesso para detectar enumeração. Veja nosso guia sobre cabeçalhos de segurança HTTP no WordPress para a sintaxe exata por servidor.

Quando não convém bloquear a REST API por completo

Bloquear a REST API inteira costuma ser o erro que mais gera ticket de suporte. O editor Gutenberg, o app móvel oficial e dezenas de plugins legítimos dependem da REST API para funcionar, e desligá-la na marra quebra o salvamento de posts e a pré-visualização do site.

Em sites com WooCommerce, o checkout e o painel de pedidos também conversam por wp-json/, então o bloqueio total tende a derrubar vendas sem aviso visível para o administrador.

A abordagem que se sustenta na maioria dos cenários testados é restringir endpoints sensíveis e exigir autenticação, não cortar a rota. Restringir wp/v2/users resolve o vetor de enumeração sem afetar nada do que o site usa de fato. Para uma visão completa de defesa em camadas, o nosso guia de hardening de segurança no WordPress mostra como a REST API se encaixa no conjunto.

Segurança gerenciada no bundle FULL

Cobrir REST API, firewall, atualização e monitoramento manualmente em cada site consome horas que a maioria das agências não tem. O plano PRO da FULL inclui segurança gerenciada no bundle por R$849 mensais para até 10 sites, o que dá R$85 por site, com All in One Security, Wordfence e backup já configurados.

A gente vê no suporte que o custo de uma única limpeza pós-invasão costuma superar meses do plano. Conheça os planos da FULL e compare com o avulso. A FULL não hospeda: complementamos o seu provedor com a camada de segurança e os plugins gerenciados.

Perguntas frequentes sobre a REST API do WordPress

Próximos passos para blindar a REST API

Proteger a REST API do WordPress se resume a restringir o endpoint de usuários, exigir autenticação e filtrar requisições no firewall, sem nunca desligar a rota que o site precisa. Comece pela camada 1, que sozinha já corta o vetor mais explorado, e suba até o monitoramento de wp-json/. Se quiser validar o estado atual do seu site, rode o repositório de vulnerabilidades da FULL e compare com os plugins que você tem ativos. Para continuar aprendendo, o FULL Academy reúne tutoriais, guias e reviews de segurança em um só lugar.

Legenda: o endpoint de usuários retornando 401 após a restrição comprova que a enumeração foi fechada na origem.