Eu não precisei entrar na conta da Capricho para enxergar o catálogo de posts. O WordPress já devolvia os artigos publicados em JSON, organizados em páginas que um programa consegue percorrer. Ver esse conteúdo arrumado numa lista me fez olhar para a configuração do meu próprio site: quem realmente precisava ler esse endpoint sem login?
A API REST mostra os posts que o WordPress já publica
A API REST já faz parte do WordPress e atende ao editor, a plugins e a outras integrações. A rota `/wp-json/wp/v2/posts` lista os posts disponíveis para consulta. Quando um post está publicado e público no próprio site, uma resposta anônima pode incluir título, endereço, resumo, conteúdo e outros campos daquele registro.
A coleção é dividida em páginas. O parâmetro `per_page` aceita até 100 posts por chamada e `page=2` busca a próxima página. Também dá para consultar um registro específico pelo ID. O limite por chamada evita uma resposta enorme; quem recebe os resultados ainda pode pedir as páginas seguintes.
Isso não abre rascunhos ou páginas privadas automaticamente. O WordPress aplica permissões a dados restritos; o que a API facilita é ler, em formato organizado, aquilo que o site já decidiu deixar público. Chamar essa função de vulnerabilidade sem esse contexto pode passar a impressão errada sobre o que ela expõe.
A demonstração na Capricho chegou a 8.910 páginas
Usei a Capricho como exemplo porque o portal roda em WordPress. Com a lista de posts acessível, montei uma demonstração local que mostrava os resultados por página e abria cada matéria pelo próprio registro da API. O catálogo do teste chegou a 8.910 páginas; eu podia ir até uma página avançada da lista e abrir o conteúdo completo de um post.
Esse teste mostrou por que a API é um caminho conveniente para percorrer um acervo: ela entrega títulos, endereços e conteúdo numa estrutura que um aplicativo consegue reutilizar. Também mostrou uma diferença importante: consultar um post público pela API é uma forma de leitura do material publicado, não uma entrada no painel administrativo do site.
Posts, categorias, imagens e outros recursos podem ter rotas próprias, e cada rota tem seus campos e permissões. Por isso, confira o endpoint que realmente está aberto no seu domínio em vez de presumir que toda a base do WordPress ficou exposta.
Confira o que alguém vê sem estar conectado
Para conferir seu próprio site, use uma janela privada e abra o endpoint de posts com o seu domínio. Se a resposta mostrar os artigos em JSON sem pedir login, a listagem está disponível para visitantes anônimos. A paginação também pode ser verificada na segunda chamada; ela ajuda a descobrir se o endpoint permite seguir pelo catálogo inteiro.
Depois, teste o endereço de um post publicado para ver quais campos aparecem no seu site. O objetivo é entender a resposta que você entrega: a API pode ser personalizada por plugins e configurações, então o que aparece num WordPress não precisa ser igual ao que aparece em outro.
- Abra `/wp-json/wp/v2/posts` numa janela privada.
- Confira se a resposta lista posts publicados e tente uma página seguinte, como `?per_page=100&page=2`.
- Se quiser conferir um post, use a rota de consulta pelo ID e observe os campos retornados sem login.
Exija autenticação para quem não precisa da API aberta
Se o seu site não usa a API para visitantes deslogados, limite esse acesso em vez de desligar a REST API inteira. Um plugin como o Perfmatters oferece a opção de bloquear a API para quem está desconectado. Em código próprio, o WordPress documenta o filtro `rest_authentication_errors` para exigir autenticação nas chamadas. A regra pode ser ajustada às rotas de que o site realmente precisa.
Desativar a API por completo pode quebrar funções do painel. O editor de blocos do WordPress usa essas chamadas para carregar e salvar conteúdo. Depois de alterar a regra, entre no admin, abra um post, salve uma edição e confira também plugins ou serviços externos que dependem dos endpoints.
Na Cloudflare, também dá para criar uma regra de firewall para o caminho `/wp-json`. Um bloqueio amplo alcança as chamadas do editor e das integrações, inclusive as autenticadas, a menos que você configure as exceções necessárias. Por isso eu começaria pela permissão no WordPress e usaria uma regra de borda somente depois de identificar o tráfego que precisa permanecer liberado.
Restringir essa rota não torna os posts privados
A regra dificulta a coleta em lote por essa API, mas os artigos públicos continuam disponíveis em HTML. Sitemap, feed RSS e leitura automatizada das próprias páginas também podem fornecer caminhos para encontrar conteúdo. Então eu trato a restrição como uma forma de limitar uma porta de entrada prática, não como garantia de que ninguém conseguirá copiar o site.
Também não dá para descobrir que uma cópia aconteceu apenas porque o endpoint está aberto. Para investigar uso indevido, você precisa observar requisições e comparar as páginas reproduzidas. Se um conteúdo deve ficar privado, coloque-o atrás de autenticação; bloquear uma lista de posts não transforma o restante do site em área restrita.