Como gerar e usar uma chave de API com segurança sem expor no código do site

Chaves de API: o segredo que precisa continuar sendo segredo 🔐

Oi, eu sou a Sensei da GeHost e hoje vamos falar de um assunto que derruba muito site por aí: a famosa chave de API (aquele código que libera acesso a serviços como pagamento, e-mail, mapas, IA, etc.) aparecendo exposta no código do site, ao alcance de qualquer curioso.

Parece bobagem, mas não é: se alguém encontrar sua chave, pode usar os créditos do seu serviço, gerar cobranças em seu nome ou até acessar dados sensíveis. Vamos aprender, com calma, como gerar e guardar essa chave do jeito certo.

💡 Regra de ouro da Sensei: chave de API é como senha de banco — ela nunca aparece "a olho nu" em nenhum arquivo que o navegador do visitante possa carregar.

Passo 1 — Gerando a chave no serviço de origem

Toda chave de API nasce na plataforma do serviço que você está usando (seu gateway de pagamento, seu provedor de e-mail transacional, sua API de mapas etc.), não no cPanel da GeHost. O caminho costuma ser parecido em quase todos eles:

1. Entre na sua conta do serviço (ex.: painel do gateway, painel da API de IA, painel de e-mail).
2. Procure por uma área chamada "API Keys", "Chaves de Integração", "Developer Settings" ou similar.
3. Gere uma nova chave — se possível, prefira chaves com escopo limitado (só leitura, ou só a função que você realmente vai usar).
4. Copie a chave e guarde num lugar seguro imediatamente (veja o próximo passo). Muitos serviços só mostram a chave completa uma vez.

Passo 2 — Onde NÃO colocar a chave (o erro mais comum)

Aqui é onde a maioria erra, então presta atenção: nunca escreva a chave direto dentro do código do site — nem em arquivos .php, .js, .html que ficam dentro da pasta pública do seu domínio. Por quê? Porque:

• Arquivos .js (JavaScript) rodam no navegador do visitante — ou seja, qualquer pessoa pode abrir o "Inspecionar elemento" do navegador e ler sua chave.
• Mesmo em arquivos .php, se algo no servidor for mal configurado (ou se o arquivo for enviado/baixado por engano), a chave fica exposta.
• Se você usa controle de versão (git) e sobe o projeto para um repositório, a chave pode vazar junto — e uma vez publicada na internet, considere-a queimada para sempre.

⚠️ Se você já colocou uma chave direto no código alguma vez, o passo mais seguro agora é gerar uma chave nova no serviço de origem e revogar a antiga — não dá pra "esconder" uma chave que já foi exposta.

Passo 3 — O jeito certo: variáveis de ambiente / arquivo fora do público

A boa prática é manter a chave separada do código, num arquivo de configuração que fica fora da pasta pública (public_html) do seu site. Assim, mesmo que alguém tente acessar aquele arquivo pelo navegador, ele não consegue — porque ele nem está na área que o navegador enxerga.

1. Acesse o Gerenciador de Arquivos no seu painel cPanel.
2. Suba um nível acima da pasta public_html (é a raiz da sua conta de hospedagem).
3. Crie ali um arquivo de configuração (por exemplo .env ou config.php, dependendo da tecnologia do seu site) e guarde a chave dentro dele.
4. No código do seu site, faça a aplicação ler essa chave desse arquivo em vez de ter o valor escrito direto no código-fonte.

Se o seu site usa WordPress ou outro sistema pronto, muitos plugins de integração (pagamento, e-mail, IA) já têm um campo próprio, dentro do próprio painel administrativo do site, para você colar a chave com segurança — nesse caso, use sempre esse campo oficial do plugin em vez de editar arquivos na mão.

Se você não sabe mexer em arquivo de configuração, tudo bem

Ajustar esse tipo de arquivo pode exigir conhecimento de programação, dependendo da tecnologia do seu site. Se você não se sente confortável fazendo isso sozinho, não arrisque — fale com quem desenvolveu seu site ou abra um chamado com nosso suporte para orientação. Nunca é vergonha pedir ajuda quando o assunto é segurança.

Passo 4 — Reforçando a proteção com o .htaccess

Como camada extra de segurança, você (ou quem cuida do seu site) pode bloquear, pelo .htaccess, o acesso direto a arquivos sensíveis como .env caso eles precisem ficar dentro da pasta pública por algum motivo. É um ajuste técnico simples de se pedir ao suporte, mas que faz toda a diferença.

Passo 5 — Boas práticas para nunca mais se preocupar

• Nunca compartilhe a chave por WhatsApp, e-mail comum ou print de tela — se precisar enviar para alguém da equipe, use um canal seguro e apague a mensagem depois.
• Troque a chave periodicamente, principalmente se alguém que teve acesso a ela saiu da equipe ou do projeto.
• Use permissões mínimas: se o serviço permitir escolher o que aquela chave pode fazer, dê só o necessário (ex.: só "enviar e-mail", não "gerenciar conta inteira").
• Revogue chaves antigas que você não usa mais — chave esquecida é porta aberta.
• Ao contratar um freelancer ou agência para mexer no site, gere uma chave nova só para esse período e revogue depois, em vez de passar a sua chave principal.

🌱 Segurança não é sobre ser paranoico, é sobre ter o hábito certo. Guardar a chave no lugar certo, uma vez, evita meses de dor de cabeça depois.

Ficou com dúvida?

Se você não tem certeza de como sua tecnologia (WordPress, sistema próprio, loja virtual) lida com variáveis de ambiente ou arquivos de configuração, chama a gente. Nosso suporte pode te orientar sobre o caminho mais seguro para o seu caso — é melhor perguntar antes do que lidar com uma chave vazada depois. 💙