O que é a API REST do WordPress? Um guia prático

A API REST do WordPress é uma interface HTTP integrada que permite a software externo interagir com um site WordPress via JSON. Foi mesclada ao núcleo do WordPress na versão 4.7 (dezembro de 2016) e alimenta o editor de blocos Gutenberg, os apps móveis oficiais do WordPress, todo frontend de WordPress headless e um enorme número de integrações de plugins. O endpoint base é /wp-json/ em cada site WordPress. Muitos desses endpoints são públicos por padrão, o que geralmente é aceitável, mas alguns deles (notavelmente a lista de usuários) expõem informações que a maioria dos proprietários de sites preferiria manter privadas.

O que é a API REST do WordPress, em termos concretos?

A API REST é a interface programática do site WordPress. Onde um navegador visita uma URL como example.com/sample-post/ e recebe HTML, um cliente de API solicita example.com/wp-json/wp/v2/posts e recebe JSON: um array de objetos de post com seus títulos, conteúdo, datas, IDs de autor e assim por diante. Cada operação CRUD (criar, ler, atualizar, deletar) que o WordPress pode realizar pela sua UI de admin tem um endpoint REST correspondente. O editor de blocos chama esses endpoints quando você salva um post; apps móveis os chamam ao publicar do seu telefone; configurações headless os chamam para buscar conteúdo para um frontend Next.js ou Gatsby.

Alguns endpoints canônicos para conhecer:

• /wp-json/ — o endpoint de discovery. Retorna um documento JSON descrevendo todas as rotas disponíveis no site.
• /wp-json/wp/v2/posts — lista de posts do blog. Público por padrão.
• /wp-json/wp/v2/pages — lista de páginas.
• /wp-json/wp/v2/users — lista de autores e seus perfis públicos. O endpoint que causa mais preocupação.
• /wp-json/wp/v2/media — lista de itens da biblioteca de mídia.
• /wp-json/wp/v2/categories, /tags, /comments — exatamente o que parecem.

Plugins e temas podem registrar endpoints adicionais. WooCommerce adiciona /wp-json/wc/v3/products, /orders, /customers. ACF adiciona endpoints para campos personalizados. Contact Form 7, Yoast SEO, cada plugin principal tem seu próprio subconjunto da API REST.

O que a API REST do WordPress faz que eu deveria me importar?

Três casos de uso de alto impacto, mesmo que você nunca escreva uma linha de código você mesmo:

• O editor Gutenberg depende dela. Toda vez que você salva um post no editor de blocos, o editor chama POST /wp-json/wp/v2/posts/{id}. Se a API REST estiver quebrada ou bloqueada, o Gutenberg para de funcionar. Sintomas: erros "Atualização falhou" ou "A resposta não é uma resposta JSON válida" ao salvar. A causa mais comum é um plugin de segurança ou regra .htaccess excessivamente agressiva que bloqueia /wp-json.
• É o alvo de reconhecimento de ataque mais comum. Atacantes consultando /wp-json/wp/v2/users podem enumerar cada conta de autor: nomes de usuário, nomes de exibição e o caminho URL do arquivo de autor deles. A partir daí, segue adivinhação de senha ou phishing direcionado. Esse único endpoint é responsável pela maioria dos achados "nomes de usuário vazados" em auditorias de segurança WordPress.
• Ela permite toda integração externa. Zapier, Make, IFTTT, notificações personalizadas do Slack, sincronização com um CRM, sincronização com um gerador de site estático, sincronização com MailChimp, serviços de tradução de terceiros, cada integração usa a API REST. Desabilitá-la inteiramente (o que alguns tutoriais de segurança recomendam) quebra todas essas.

Que informações a API REST expõe por padrão?

Pronta para usar, uma requisição não autenticada a um site WordPress típico pode recuperar:

• Todos os posts e páginas publicados. Incluindo seu conteúdo completo. Os mesmos dados que um navegador visitando o site pode ver; apenas em forma JSON para scraping mais fácil.
• A lista de cada usuário que publicou um post. /wp-json/wp/v2/users retorna o nome de usuário do WordPress (o nome de login), o nome de exibição, a URL do arquivo de autor e o ID do usuário para cada autor. Isso foi mudado no WordPress 5.0 para retornar apenas usuários que tenham criado um post publicado (anteriormente retornava cada usuário), mas para a maioria dos blogs isso ainda significa cada administrador e editor.
• Todos os itens da biblioteca de mídia. Incluindo as URLs de tamanho original para cada imagem e arquivo. Útil para scraping, prejudicial se você fez upload de documentos privados para a biblioteca de mídia pensando que não seriam descobertos.
• A taxonomia completa. Categorias, tags, taxonomias personalizadas e seus relacionamentos.
• Metadados do site. Nome, descrição, URL, fuso horário, idioma, formato de hora, tipos de post disponíveis e taxonomias.

Nada disso é tecnicamente uma vulnerabilidade; é a API se comportando como projetada. Mas para a maioria dos sites o trade-off entre "conveniência para integrações" e "vazamento de informações para atacantes" pende para restringir pelo menos o endpoint de usuários.

Devo desabilitar a API REST do WordPress?

Resposta curta: não, não a desabilite inteiramente. Restrinja-a.

Desabilitar a API REST completamente quebra o editor de blocos para qualquer admin logado tentando salvar um post, quebra o app móvel do WordPress, quebra toda automação Zapier ou Make apontando para o site, quebra o checkout do WooCommerce em algumas configurações, e quebra todo plugin que usa a API REST internamente (que é a maioria dos plugins agora). O conselho "desabilite a API REST" de artigos de segurança antigos remonta ao WordPress 4.7-4.9 quando a API era mais nova e a história de integração era menos desenvolvida. Em 2026 está errado.

A abordagem correta é restringir endpoints específicos (especialmente /users) enquanto deixa o resto da API funcionando. Três padrões que atingem o equilíbrio certo:

Padrão 1: exigir autenticação para o endpoint de usuários

A restrição mais comum e útil. Adicione ao functions.php de um child theme ou a um mu-plugin:

add_filter('rest_authentication_errors', function ($result) {
    if (!empty($result)) {
        return $result;
    }
    $route = isset($GLOBALS['wp']->query_vars['rest_route']) ? $GLOBALS['wp']->query_vars['rest_route'] : ';
    if (strpos($route, '/wp/v2/users') === 0 && !is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            'You are not currently logged in.',
            ['status' => 401]
        );
    }
    return $result;
});

Isso retorna um 401 para requisições não autenticadas a /wp-json/wp/v2/users enquanto deixa todo outro endpoint acessível. Apps móveis e integrações que se autenticam (Application Passwords, OAuth) ainda funcionam normalmente. Gutenberg ainda funciona porque a requisição do editor é autenticada.

Padrão 2: limitar a taxa da API

Um scraper de alto volume batendo em /wp-json/wp/v2/posts?per_page=100&page=N pode puxar todo seu banco de dados de conteúdo em segundos. Rate-limiting em nível de servidor web (nginx limit_req) ou via plugin de segurança (Wordfence, iThemes Security) atenua isso. Proteção útil contra scrapers de conteúdo e enumeração de força bruta mesmo quando endpoints individuais não são sensíveis.

Padrão 3: usar um WAF ou CDN que filtra requisições de API

Cloudflare e Sucuri ambos permitem escrever regras como "bloquear qualquer requisição a /wp-json/wp/v2/users de fora da nossa faixa de IP da empresa". Útil para sites onde a API REST é puramente de uso interno (um backend headless de uma equipe editorial, por exemplo).

Como a API REST do WordPress é autenticada?

Para operações de escrita ou para acessar dados não públicos, a API REST requer autenticação. Cinco métodos, em ordem de quão comuns são em 2026:

• Autenticação por cookie. O padrão para requisições originárias do mesmo site que a instalação do WordPress. O editor de blocos e qualquer requisição de UI de admin logado usam cookies. Requer um nonce para proteção CSRF.
• Application Passwords. Introduzido no WordPress 5.6 (2020). Cada usuário pode gerar senhas específicas para finalidade a partir da página de perfil deles, que são então enviadas via HTTP Basic Auth. Este é o método recomendado para apps móveis e integrações externas em 2026. A maioria dos plugins que anteriormente exigiam JWT agora também suporta Application Passwords.
• OAuth 2.0. Via o plugin oficial "WordPress.com" ou plugins OAuth de terceiros. Usado quando você precisa de escopos de granularidade fina ou integração de app de terceiros. Menos comum que Application Passwords para a maioria dos casos de uso.
• JWT (JSON Web Tokens). Via o popular plugin "JWT Authentication for WP REST API". Foi o padrão de fato para WordPress headless entre 2017 e 2022, agora majoritariamente substituído por Application Passwords.
• Autenticação específica do plugin. WooCommerce usa chaves de consumidor assinadas com HMAC para sua API. Cada plugin importante tende a ter sua própria abordagem.

Se você está escrevendo código personalizado ou pedindo a um desenvolvedor para integrar com seu site, a resposta padrão em 2026 é "Application Passwords" a menos que você tenha uma razão específica para usar OAuth ou JWT.

Como verifico o que a API REST do meu site está expondo?

Três verificações rápidas:

1. Visite o endpoint de discovery. Abra https://seusite.com/wp-json/ em um navegador. Você obterá um documento JSON listando cada rota registrada. Leia através do objeto routes para ver o que está disponível.
2. Verifique o endpoint de usuários especificamente. Visite https://seusite.com/wp-json/wp/v2/users. Se você vir um array de usuários com nomes, slugs e links, os nomes dos seus autores são publicamente enumeráveis. Se você vir {"code": "rest_not_logged_in", "message": "..."}, está restrito. Se você obtiver um 404, a API REST inteira está desabilitada (o que provavelmente significa que o Gutenberg também não funciona).
3. Use o InspectWP. A seção de Segurança de um relatório InspectWP testa explicitamente se o endpoint de usuários é acessível publicamente e o sinaliza se for. Mais rápido que digitar as URLs manualmente.

Qual é a diferença entre a API REST e XML-RPC?

WordPress tem duas APIs remotas que sobrepõem em propósito: XML-RPC (legado, desde WordPress 2.6 em 2008) e a API REST (moderna, desde 4.7 em 2016). Para a maioria das operações elas expõem funcionalidade comparável. As diferenças:

• Protocolo. XML-RPC usa XML sobre POST para um único endpoint (/xmlrpc.php). A API REST usa JSON sobre verbos HTTP padrão em múltiplas URLs. JSON é significativamente mais fácil de trabalhar em linguagens modernas.
• Superfície de ataque. XML-RPC tem sido uma dor de cabeça de segurança perene. O método system.multicall permite empacotar milhares de tentativas de adivinhação de senha em uma única requisição, derrotando a maioria do rate-limiting básico. O recurso Pingback tem sido usado em ataques de amplificação DDoS. A maioria dos guias de segurança agora recomenda desabilitar XML-RPC inteiramente, o que é uma conversa diferente da API REST.
• Futuro. O desenvolvimento do núcleo do WordPress se mudou inteiramente para a API REST. XML-RPC ainda é suportado mas nenhum novo recurso é adicionado. Várias ferramentas de terceiros (notavelmente Jetpack, até recentemente) ainda dependem de XML-RPC, o que é a principal razão de continuar habilitado por padrão.

"Desabilitar XML-RPC" e "bloquear o endpoint de usuários da API REST" são ambas medidas de segurança razoáveis e elas miram coisas diferentes. Fazer uma não afeta a outra.

Quais são problemas comuns da API REST em sites WordPress?

• "A resposta não é uma resposta JSON válida" ao salvar no Gutenberg. Quase sempre significa que um plugin de segurança ou regra .htaccess está bloqueando requisições /wp-json/, ou uma configuração de permalink está reescrevendo-as incorretamente. Correção: regenere permalinks (Configurações, Links permanentes, Salvar) e verifique Wordfence/iThemes por toggles "Bloquear API REST".
• Erros CORS ao chamar de um frontend headless. Por padrão, o WordPress só aceita requisições da API REST do seu próprio domínio. Para uma configuração headless em um domínio diferente, adicione cabeçalhos Access-Control-Allow-Origin via o filtro rest_pre_serve_request, ou use um plugin como "WP CORS".
• Application Passwords não funcionando. Alguns ambientes de hospedagem removem o cabeçalho Authorization de requisições recebidas antes do WordPress vê-lo. Esta é a causa mais comum de "Autenticação de Application Password falha silenciosamente". Correção: peça ao host para colocar na whitelist o cabeçalho Authorization para HTTP Basic Auth, ou use o workaround HTTP_AUTHORIZATION em .htaccess.
• Respostas lentas da API REST. Padrão per_page=10, mas uma integração preguiçosa solicita per_page=100 em um site com 50.000 posts. Cada chamada REST carrega o objeto post completo, hidrata campos ACF, executa filtros. Resultado: uma resposta de 30 segundos. A correção geralmente é adicionar um cache de objetos (Redis) e consultar apenas os campos que a integração realmente precisa via o parâmetro _fields.
• 404 em /wp-json/ em todo lugar. Permalinks bonitos não estão habilitados. Vá para Configurações, Links permanentes, selecione qualquer coisa diferente de "Simples", salve. A API REST requer permalinks bonitos para funcionar.

O que o InspectWP verifica

A seção de Segurança de cada relatório InspectWP testa a API REST do WordPress de duas formas específicas. Primeiro, verifica se /wp-json/wp/v2/users é acessível publicamente sem autenticação. Se for, o relatório lista os nomes de usuário enumeráveis e sinaliza isso como um achado de segurança, porque nomes de usuário expostos tornam força bruta e phishing direcionado significativamente mais fáceis. Segundo, o relatório verifica se o endpoint de discovery da API REST é alcançável de alguma forma, o que é necessário para que Gutenberg e a maioria dos plugins funcionem; uma API REST completamente desabilitada é sinalizada como causa provável de problemas do editor. O estado recomendado é "API REST alcançável, endpoint de usuários protegido". O objetivo é fazer as integrações funcionarem enquanto bloqueia o padrão de reconhecimento de atacante mais comum, o que pode ser alcançado com o pequeno snippet de código mostrado acima.