Se uma integração usa a REST API do seu site, teste o WordPress 7.2 Beta 2 conferindo três coisas separadas: se a senha de aplicação identifica a conta certa, se essa conta só acessa o que pode e se a credencial deixa de funcionar após a revogação. Faça os testes somente em staging protegido, com HTTPS, backup e dados fictícios. A notícia oficial da Beta 2 desaconselha expressamente instalar ou testar essa versão em produção.
Este é um checklist para planejar e registrar testes de senhas de aplicação e permissões REST no WordPress 7.2 beta, não o relato de um teste já realizado. As melhorias para application passwords aparecem no roadmap da versão 7.2 como propostas: não há confirmação, nesse anúncio da Beta 2, de que cada mudança esteja incluída nessa build ou na versão final.
O que está confirmado e o que depende da build
Senhas de aplicação existem no WordPress desde a versão 5.6. Elas são distintas da senha usada para entrar no painel e permitem autenticar uma aplicação externa, por exemplo na REST API via Basic Auth sobre HTTPS. A senha identifica uma conta; quem determina o acesso aos recursos são as capacidades dessa conta e as regras da rota. Não trate a senha como um novo papel, um escopo restrito independente ou um segundo fator (guia oficial de autenticação REST).
A notícia da Beta 2 cita melhorias gerais na flexibilidade da REST API, mas não confirma individualmente as propostas sobre senhas de aplicação. O roadmap menciona possíveis ajustes de experiência e segurança, inclusive aviso de criação por email; a presença ou a ausência de uma tela/aviso não prova, sozinha, uma regressão. A notícia indica 8 de dezembro de 2026 como previsão de lançamento final, sujeita a mudanças. Confira as notas oficiais e a versão exata antes de atribuir qualquer comportamento ao WordPress 7.2.
Prepare um staging seguro antes de instalar a beta
- Use uma cópia de staging protegida e separada do site publicado, com autorização para testar. Faça e saiba restaurar um backup completo de arquivos e banco de dados antes de instalar a beta ou alterar contas. Não copie senhas, tokens nem dados reais de clientes para o teste.
- Confirme HTTPS válido no endereço do staging. Se não estiver disponível, corrija o ambiente; não force a habilitação de senhas de aplicação em HTTP. A disponibilidade pode variar conforme configuração, filtros, plugins e hospedagem (guia oficial de integração).
- Isole emails, webhooks, pagamentos e demais integrações para não enviar mensagens nem fazer alterações em serviços reais. Registre versões do WordPress, PHP, tema e plugins relevantes; se houver WAF ou proxy, anote a configuração que pode afetar as requisições.
- Crie contas e recursos fictícios com as menores capacidades adequadas à rota escolhida. Para comparar autorização, você precisa de uma conta que tenha a capacidade exigida e outra que não a tenha. Não eleve ambas a administradoras apenas para obter uma resposta positiva. Para governança das contas humanas e seus papéis, consulte a política de senhas e acessos.
- Escolha um cliente HTTP que armazene segredos com segurança e não os imprima em relatórios. Não inclua credenciais em URL, comando gravado no histórico, captura, log, repositório ou texto do artigo. Oculte também cabeçalhos
Authorizatione dados de usuários nas evidências.
A notícia oficial descreve o plugin WordPress Beta Tester com canal Bleeding edge e fluxo Beta/RC Only em ambiente de teste. A interface pode variar conforme idioma e versão; confirme a build exibida antes da atualização, pois esse canal pode oferecer uma beta ou RC posterior. Não ative o canal no site publicado. O procedimento de atualização da produção, quando chegar a hora, é outro: veja o checklist de atualização segura do WordPress.
Checklist para testar autenticação e permissões REST
1. Defina a linha de base e o resultado esperado
Anote a rota usada pela integração, método HTTP, versão do plugin que a fornece, regra de permissão e capacidade exigida. Antes da beta, registre em staging a resposta esperada para uma conta permitida e outra sem a capacidade necessária; depois repita o mesmo roteiro na build de teste. Use apenas respostas de leitura de recursos fictícios e não copie o corpo sensível para o relatório. Se a rota for de plugin, uma diferença não é automaticamente defeito do core.
2. Crie uma credencial temporária no staging
No perfil de uma conta fictícia autorizada, procure a seção de senhas de aplicação, se disponível, e crie uma com nome de teste temporário. Guarde o segredo somente no cofre ou armazenamento seguro do cliente HTTP; no relatório, registre nome e finalidade, nunca o valor. A referência REST de senhas de aplicação mostra que o valor gerado só está disponível após a criação.
Se a seção não aparecer, confira HTTPS, permissões da conta, políticas de plugins, filtros e hospedagem antes de atribuir o problema à beta. Não desative proteção ou autenticação às cegas. Para comparar as duas contas no teste de autorização, use credenciais temporárias distintas e identifique a qual conta cada uma pertence.
3. Confira identidade antes de conferir autorização
No staging, com o cliente HTTP configurado para autenticação segura, faça um GET autenticado para /wp-json/wp/v2/users/me. Confira se a resposta identifica a conta fictícia esperada; a referência oficial da rota de usuários documenta GET /wp/v2/users/me. Repita a consulta sem credencial e sem cookie de sessão: ela não deve expor os dados privados da conta como se estivesse autenticada. Uma rota pública que responde não comprova a identidade do solicitante.
Depois, use uma rota protegida de leitura cuja regra de acesso você conheça, apontando para um recurso fictício. A conta autorizada deve ver apenas o recurso previsto; a conta sem a capacidade exigida não deve vê-lo. Não escolha uma rota arbitrária nem realize operações de escrita para “provar” permissões. Se a integração usa cookie e nonce dentro do painel, documente esse teste separadamente: é um método diferente de autenticação (guia REST).
| Cenário | Evidência segura | Sinal de atenção |
|---|---|---|
| Identidade autenticada | Build, método GET, rota, identificador fictício e horário | Conta inesperada ou autenticação não reconhecida. |
| Mesma rota sem credenciais e sem sessão | Status e ausência de dados privados | Dados protegidos aparecem sem autenticação. |
| Conta com e sem a capacidade exigida | Regra da rota, capacidades esperadas e resultado resumido | Conta não autorizada recebe o recurso protegido. |
| Credencial temporária revogada | Identificador não secreto, horário e resultado de nova tentativa | A credencial ainda autentica a conta fictícia. |
Códigos como 401 e 403 ajudam a investigar, mas não são diagnóstico universal: rota, plugin, WAF e proxy podem alterar o resultado. Compare antes e depois da beta e verifique HTTPS, transmissão do cabeçalho de autorização, capacidades e regra da rota. Não enfraqueça a segurança de produção para fazer um teste passar.
4. Revogue apenas a credencial criada para a rodada
Ao terminar, revogue somente a senha de aplicação fictícia criada no staging e repita o teste de identidade com ela, sem cookie ou outra credencial ativa: ela não deve continuar autenticando. Revogue também a credencial temporária da segunda conta, se houver. Nunca revogue senhas de aplicação em uso na produção. Se algum segredo ficou em log, print ou cliente compartilhado, revogue-o imediatamente e avalie a exposição com a equipe responsável.
E se aparecer uma notificação ou uma tela diferente?
Anote build, sequência de ações e o resultado, sem capturar segredos. Se houver email de aviso, verifique-o apenas na caixa isolada de testes. A proposta de notificação citada no roadmap não é uma garantia para a Beta 2; a ausência de mensagem também pode refletir o isolamento do email no staging. Para 2FA no login interativo do WordPress, faça um teste separado: a senha de aplicação não é o segundo fator e não equivale à senha usada no painel.
Fechamento: o que registrar antes de decidir pela atualização
Guarde uma ficha com build exata, ambiente, rota, regra/capacidade esperada, resposta resumida sem segredos e passos de reprodução. Se a conta sem permissão obtiver dados protegidos, interrompa o teste, restrinja o ambiente e investigue com a equipe responsável. Não instale a Beta 2 em produção. Mesmo que staging passe, confira as notas da versão final, a compatibilidade dos plugins e a hospedagem; faça novo backup antes de aplicar uma atualização real.
