# Como proteger a REST API do WordPress em 5 camadas 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.
Endpoints da REST API: exposição padrão e risco
Endpoint O que entrega sem login Risco principal
wp/v2/users Nome e slug de login dos autores Enumeração de usuário para força bruta
wp/v2/posts Conteúdo, incluindo rascunhos mal protegidos Vazamento de conteúdo não publicado
wp-JSON (raiz) Lista de rotas e plugins que as registram Mapeamento de versões vulneráveis
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 , 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

O que a REST API do WordPress expõe por padrão sem login?

A REST API expõe sem login os endpoints de posts, páginas, comentários e, o mais sensível, `wp/v2/users`, que lista nome e slug de login de cada autor em JSON. Num WordPress 6.x recém-instalado, basta abrir `wp-json/wp/v2/users` no navegador. Esse dado alimenta força bruta direcionada e deve ser o primeiro endpoint a restringir.

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

Porque a enumeração de usuário não depende de falha de código: é comportamento padrão da REST API. O bot lê os slugs de autor reais e dispara força bruta só contra esses nomes, em vez de adivinhar. Isso reduz o número de tentativas e escapa de quem só monitora `wp-login.php`. O risco existe num site 100% atualizado.

Qual a diferença entre desativar a REST API e restringir os endpoints?

Desativar a REST API inteira quebra Gutenberg, app móvel e plugins que dependem de `wp-json/`, como o WooCommerce. Restringir endpoints fecha só os pontos sensíveis, como `wp/v2/users`, e exige autenticação onde importa. Na prática, restringir resolve o vetor de enumeração sem derrubar nada que o site usa. Bloqueio total gera ticket de suporte.

É possível proteger a REST API sem editar o código do tema?

Sim, é possível proteger a REST API sem tocar em código. Plugins como Wordfence e All in One Security restringem `wp/v2/users` e aplicam regras de firewall a `wp-json/` em poucos cliques. O `functions.php` é só para quem quer controle fino com o filtro `rest_endpoints`. Para a maioria dos sites, o plugin de segurança já cobre as cinco camadas.

Quanto tempo um CVE de REST API leva para ser explorado por bots?

Falhas de REST API com CVE público tendem a ser varridas por bots em poucas horas após a divulgação. Por isso a atualização de plugins que registram rotas, como Contact Form 7 e Yoast SEO, é a camada com melhor retorno. A CVE-2023-6449, CVSS 7.2, foi corrigida na versão 5.8.4 do Contact Form 7, mas quem não atualizou seguiu exposto.

--- ## 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.