Chaves de API no WordPress: por que o wp-config.php continua sendo a alternativa mais segura — e o que pode mudar no 7.2

Quem administra sites WordPress provavelmente já precisou abrir o arquivo wp-config.php para inserir uma credencial de API — seja do Stripe, de um servidor SMTP, da OpenAI ou de algum webhook. Embora essa seja a prática mais difundida, ela também costuma ser mal interpretada. Muitos consideram as constantes definidas nesse arquivo “suficientemente protegidas”, sem compreender exatamente por que isso acontece — nem em quais situações essa proteção deixa de ser válida.

Com agentes de inteligência artificial e integrações baseadas em MCP começando a consumir APIs diretamente de instalações WordPress — assunto que já abordamos neste artigo —, a quantidade de credenciais presentes em um site tende a aumentar. Por isso, é importante saber onde armazená-las e quais locais devem ser evitados.

O risco: muitos plugins salvam credenciais sem criptografia

Na maioria dos casos, um plugin armazena sua credencial como uma option no banco de dados, junto a informações corriqueiras, como o nome ou o slogan do site. Assim, chaves do Stripe, senhas de SMTP, tokens do Google, credenciais da OpenAI e segredos usados na assinatura de webhooks acabam frequentemente registrados em texto aberto na tabela wp_options.

Essa exposição produz consequências concretas. As informações podem aparecer em:

• Cópias de segurança do banco, que muitas vezes recebem menos proteção do que a instalação em produção;
• Ambientes de homologação, frequentemente clonados sem uma análise cuidadosa do conteúdo replicado;
• Chamados de suporte, quando uma equipe exporta opções para investigar uma falha;
• Arquivos de migração, gerados durante a mudança de provedor ou servidor.

Além disso, cada plugin costuma adotar uma estratégia própria. Ferramentas como Site Kit, WooCommerce e muitas outras implementam suas próprias soluções de criptografia — quando oferecem alguma proteção. Isso aumenta a área que precisa ser revisada e torna a resposta a incidentes menos uniforme, pois cada vazamento exige a compreensão do funcionamento específico do plugin envolvido.

Por que o wp-config.php oferece mais proteção — embora não seja infalível

Definir a credencial como uma constante no wp-config.php elimina o risco mais evidente: o segredo deixa de ficar na tabela wp_options e não aparece na API REST, no painel administrativo nem em um backup convencional do banco de dados.

// wp-config.php
define( 'OPENAI_API_KEY', 'sk-...' );
define( 'STRIPE_SECRET_KEY', 'sk_live_...' );

No plugin ou no tema, a constante pode ser utilizada desta forma:

if ( defined( 'OPENAI_API_KEY' ) ) {
    $client = new OpenAI_Client( OPENAI_API_KEY );
}

Por que não se deve considerar o problema encerrado

O arquivo reduz significativamente a exposição, mas apresenta três pontos fracos que muitas agências acabam ignorando:

1. A credencial continua acompanhando os arquivos do site. Em caso de invasão do servidor, de um backup que inclua a instalação completa ou de um commit acidental, a chave também será levada. Não é raro encontrar o conteúdo integral do wp-config.php no histórico de um repositório privado. E retirar o arquivo em um commit posterior não apaga automaticamente os registros anteriores do Git.
2. Não existe rotação ou histórico de alterações integrado. Se uma chave for exposta, sua substituição precisa ser feita manualmente. O processo não oferece, por padrão, um registro claro da data da troca nem de quem teve acesso à versão anterior.
3. O valor não é criptografado. Ele apenas foi retirado do banco de dados. A chave permanece legível e qualquer pessoa com permissão de leitura no sistema de arquivos poderá visualizá-la, assim como faria com uma option.

Cuidados básicos ao usar o wp-config.php

• Deixar o arquivo fora do versionamento, incluindo-o no .gitignore, sempre que possível. Outra opção é armazenar os segredos em um arquivo independente, como secrets.php, carregado com require e mantido separadamente, com permissões restritas.
• Configurar permissões 640 ou mais limitadas, de modo que apenas o usuário responsável pelo PHP-FPM tenha acesso de leitura.
• Usar credenciais diferentes em produção e homologação. Um ambiente de testes vulnerável não deve ter condições de consumir o orçamento de APIs associado à produção.

Variáveis de ambiente: uma boa escolha em hospedagens gerenciadas

Quando o provedor oferece variáveis de ambiente reais — e não uma simulação feita por plugin —, essa costuma ser a solução mais organizada para equipes técnicas:

// wp-config.php
define( 'OPENAI_API_KEY', getenv( 'OPENAI_API_KEY' ) );

Nesse modelo, a chave não precisa ser armazenada no repositório nem no sistema de arquivos da aplicação. Ela pode ser configurada no painel da hospedagem, em um docker-compose.yml ou como um secret no orquestrador, como Kubernetes ou ECS.

A abordagem elimina o risco relacionado ao Git, mas não resolve completamente a rotação nem fornece, por si só, uma trilha de auditoria. Quando ocorre um vazamento, alguém ainda precisa substituir manualmente o valor estático.

Equipes que utilizam um arquivo .env no ambiente local — por exemplo, com vlucas/phpdotenv — devem protegê-lo como protegeriam o wp-config.php: o arquivo precisa ficar fora do Git, ter permissões limitadas e jamais ser versionado, nem mesmo “apenas para testar”.

Possíveis mudanças com a Secrets API planejada para o WordPress 7.2

Em agosto, foi divulgada uma proposta oficial para incorporar uma Secrets API nativa ao núcleo do WordPress. A previsão é que o feature plugin esteja pronto antes do Beta 1 da versão 7.2, programado para ocorrer entre 20 e 22 de outubro de 2026.

A proposta procura preencher justamente as três principais limitações do wp-config.php:

• Criptografia obrigatória durante o armazenamento, baseada em libsodium. Cada segredo teria sua própria chave de dados, protegida por uma chave mestra. Esse mecanismo não seria opcional nem permitiria ser desativado por configuração.
• Uma interface única para todos os plugins, com funções como wp_set_secret(), wp_get_secret(), wp_delete_secret() e wp_import_option_as_secret(), esta última destinada à migração de chaves existentes salvas como option. O retorno seria um objeto WP_Secret, que disponibilizaria o método reveal(). Dessa forma, os pontos do código que acessam credenciais poderiam ser localizados e auditados com mais facilidade.
• Rotação baseada em duas versões, mantendo uma credencial atual e outra anterior. Isso permitiria trocar a chave sem interromper imediatamente integrações que ainda dependam da versão antiga durante uma curta janela de transição.
• Ausência de filtros durante a leitura, dificultando que um plugin malicioso capture a credencial em texto aberto no meio da operação.

É importante destacar que a funcionalidade ainda está em fase de proposta e não foi confirmada como parte definitiva do WordPress. A interface administrativa para gerenciamento dos segredos foi intencionalmente excluída da versão 7.2 e deverá ser considerada apenas no 7.3, depois que o uso real da API revelar padrões e necessidades mais claros. Para o lançamento previsto para dezembro de 2026, o acesso inicial deve ser oferecido por meio do WP-CLI.

Impacto para quem desenvolve plugins

Caso a proposta seja aprovada sem grandes alterações, um plugin que hoje busca uma credencial desta maneira:

$key = get_option( 'my_plugin_api_key' );

poderá passar a utilizar o mecanismo nativo:

$secret = wp_get_secret( 'my-plugin/api-key' );
if ( null !== $secret && ! is_wp_error( $secret ) ) {
    $client = new API_Client( $secret->reveal() );
}

Isso não dispensa boas práticas. Um desenvolvedor ainda pode registrar acidentalmente o resultado de reveal() em um log, por exemplo. A diferença é que, em vez de dezenas de soluções independentes de proteção espalhadas pelos plugins, haveria um recurso centralizado, auditável e criptografado por padrão.

Lista de verificação para administradores e desenvolvedores

Enquanto a Secrets API não estiver disponível — e também depois, até que os plugins adotem o novo padrão —, vale executar as seguintes ações:

• [ ] Verificar os plugins instalados e identificar quais armazenam credenciais como option sem criptografia. Essa análise pode ser feita diretamente em wp_options, usando, por exemplo, wp option list --search="*key*" no WP-CLI.
• [ ] Transferir chaves importantes para o wp-config.php ou para variáveis de ambiente, evitando os campos administrativos que salvam automaticamente os valores no banco quando houver alternativa.
• [ ] Confirmar que o wp-config.php não faz parte do versionamento do projeto.
• [ ] Limitar as permissões dos arquivos e revisar quais pessoas possuem acesso SSH ou SFTP ao servidor de produção.
• [ ] Manter credenciais exclusivas para produção, homologação e desenvolvimento.
• [ ] Examinar os backups e verificar se os dumps do banco contêm chaves ou tokens. Em caso positivo, identificar exatamente quem pode acessar esses arquivos.

Para agências e empresas que administram diversos sites WordPress com integrações de inteligência artificial, pagamentos ou automações, esse é um dos pontos que facilmente ficam fora de uma auditoria superficial — mas que podem se transformar em um incidente público quando são ignorados.

Fontes

• Proposal: A Secrets API for WordPress 7.2 — Make WordPress Core
• Roadmap to 7.2 — Make WordPress Core
• WordPress Wants a Real Secrets API in 7.2. Plugins Still Dump Keys in wp-config. — Nandann Creative Agency
• What’s new for developers? (September 2026) — WordPress Developer News

Sua agência ou empresa sabe quantas chaves de API estão distribuídas entre os plugins dos sites WordPress que administra? Solicite um diagnóstico gratuito do seu site com a Amicatek e identifique os pontos que precisam de correção antes que se transformem em um incidente.