A REST API do WordPress é uma interface poderosa que permite que aplicações externas, temas e plugins interajam com os dados do seu site. De fábrica, o WordPress expõe vários endpoints públicos que qualquer um pode consultar sem autenticação. Embora isso seja útil para configurações headless e integrações de terceiros, também abre portas para vazamentos de informação, especialmente em torno de dados de usuários.
O que a REST API do WordPress expõe por padrão
Quando a REST API está totalmente acessível, vários endpoints retornam dados que a maioria dos proprietários de sites preferiria manter privados. Os mais comumente abusados incluem:
/wp-json/wp/v2/users: retorna uma lista de todos os usuários que publicaram pelo menos um post, incluindo nome de usuário, nome de exibição, ID do usuário, URL do avatar e link do arquivo do autor./wp-json/wp/v2/users/1: retorna informações detalhadas sobre um usuário específico pelo ID. Atacantes frequentemente começam pelo ID 1, porque essa costuma ser a conta de administrador./wp-json/wp/v2/posts: lista posts publicados junto com informações do autor./wp-json/wp/v2/pages: lista todas as páginas publicadas, o que pode revelar a estrutura interna do site./wp-json/: o próprio endpoint raiz revela todas as rotas registradas, dando aos atacantes um mapa das capacidades do seu site e dos plugins instalados.
O endpoint /wp/v2/users é a maior preocupação para a maioria dos sites. Atacantes o usam para enumeração de usuários, coletando nomes de usuário válidos que então alimentam ataques de força bruta de login. Mesmo se você usa senhas fortes, expor nomes de usuário remove uma camada de defesa.
Por que você não deve desabilitar a REST API por completo
Pode ser tentador bloquear a REST API totalmente, mas fazer isso quebrará vários recursos centrais do WordPress. O editor de blocos Gutenberg depende fortemente de chamadas à REST API para carregar dados de blocos, salvar conteúdo e gerenciar mídia. Se você desabilita a API por completo, o Gutenberg deixará de carregar e você não conseguirá editar posts ou páginas.
Além do Gutenberg, muitos plugins populares dependem da REST API para suas funcionalidades:
- Contact Form 7: usa endpoints da REST API para tratamento de envio de formulários em versões mais novas.
- WooCommerce: depende de rotas da REST API para operações de carrinho, processamento de checkout e a interface administrativa.
- Yoast SEO: usa chamadas à REST API para sua metabox e recursos de análise de conteúdo no editor.
- Jetpack: requer acesso à REST API para sua conexão aos serviços do WordPress.com.
A abordagem correta é a restrição seletiva: bloquear o acesso público a endpoints sensíveis enquanto mantém a API disponível para usuários autenticados e a área administrativa do WordPress.
Restrinja a REST API apenas a usuários logados
O método mais eficaz é exigir autenticação para todas as requisições da REST API. Adicione este código ao functions.php do seu tema ou, melhor ainda, a um plugin específico do site personalizado:
add_filter('rest_authentication_errors', function($result) {
// If a previous authentication check already passed or failed, respect it
if (true === $result || is_wp_error($result)) {
return $result;
}
// Block unauthenticated requests
if (!is_user_logged_in()) {
return new WP_Error(
'rest_not_logged_in',
'You are not currently logged in.',
array('status' => 401)
);
}
return $result;
});Essa abordagem bloqueia todo o acesso à REST API para visitantes que não estão logados. Gutenberg, WooCommerce e outros plugins continuam funcionando normalmente porque suas requisições vêm de sessões administrativas autenticadas. Visitantes tentando acessar /wp-json/wp/v2/users receberão um erro 401 em vez de dados de usuário.
Uma observação a ter em mente: se o seu site usa um frontend headless ou se você tem um recurso público que busca dados via REST API (por exemplo, uma busca ao vivo alimentada pela REST API), esse método quebrará esse recurso. Nesses casos, a abordagem seletiva abaixo é mais adequada.
Desabilitar seletivamente apenas o endpoint de usuários
Se você quer manter a REST API acessível para uso público, mas especificamente impedir a enumeração de usuários, pode remover apenas os endpoints de usuários:
add_filter('rest_endpoints', function($endpoints) {
// Remove the users list endpoint
if (isset($endpoints['/wp/v2/users'])) {
unset($endpoints['/wp/v2/users']);
}
// Remove the single user endpoint
if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
unset($endpoints['/wp/v2/users/(?P[\d]+)']);
}
return $endpoints;
}); Isso deixa todas as outras rotas da REST API funcionais, enquanto bloqueia especificamente o vetor de enumeração de usuários. É um bom compromisso para sites que precisam de acesso público à REST API para busca, consultas de conteúdo ou outros recursos, mas querem proteger os dados de usuário.
Remova o link de descoberta da REST API do HTML
O WordPress imprime uma tag <link rel="https://api.w.org/"> no head do HTML e um cabeçalho Link nas respostas HTTP. Esses elementos dizem às ferramentas automatizadas onde encontrar a REST API. Embora remover essas tags não desabilite de fato a API (os endpoints ainda respondem em suas URLs habituais), reduz a descoberta:
// Remove the REST API link from the HTML head
remove_action('wp_head', 'rest_output_link_wp_head');
// Remove the REST API link from XML-RPC responses
remove_action('xmlrpc_rpc_methods', 'rest_output_link_wp_head');
// Remove the Link header from HTTP responses
remove_action('template_redirect', 'rest_output_link_header', 11);Esse passo é mais bem usado em conjunto com um dos métodos de restrição acima, não isoladamente. Remover a tag de link sem restringir os endpoints reais é segurança por obscuridade, o que oferece proteção real mínima.
Usando um plugin para gerenciar o acesso à REST API
Se você prefere não adicionar código personalizado, vários plugins fornecem uma interface para gerenciar o acesso à REST API:
- Disable WP REST API: bloqueia todo o acesso à REST API para requisições não autenticadas com um toggle simples. Sem configuração além de ativar o plugin.
- WP REST API Controller: dá controle granular sobre quais endpoints são públicos e quais exigem autenticação, permitindo que você libere algumas rotas enquanto bloqueia outras.
A abordagem por plugin é mais simples de gerenciar, mas adiciona uma dependência. Se o plugin é desativado ou removido durante uma atualização, sua REST API estará novamente totalmente pública. A abordagem baseada em código é mais confiável para proteção a longo prazo.
Testando suas restrições da REST API
Após aplicar suas alterações, verifique se elas funcionam corretamente. Abra uma janela anônima do navegador (para que você não esteja logado) e tente acessar essas URLs no seu site:
https://yoursite.com/wp-json/wp/v2/usershttps://yoursite.com/wp-json/wp/v2/users/1https://yoursite.com/wp-json/
Se sua restrição está funcionando, esses endpoints devem retornar um erro 401 ou uma resposta vazia em vez de dados de usuário. Em seguida, faça login no admin do WordPress e confirme que o editor Gutenberg, seus formulários e qualquer funcionalidade do WooCommerce ainda funcionam como esperado.
Verifique com o InspectWP
Após implementar suas alterações, execute uma nova varredura no InspectWP no seu site. A seção de Segurança do seu relatório mostrará se a REST API está publicamente acessível e se o endpoint de usuários retorna dados. Se a restrição estiver funcionando corretamente, o InspectWP relatará a API como não acessível ou o endpoint de usuários como restrito.