Chaves de API e cabeçalhos de autenticação
A maioria das APIs úteis não é aberta ao mundo. A empresa precisa saber quem está perguntando, para poder rastrear o uso e cobrar por ele. Ela te dá uma chave de (API key) — uma longa string secreta que identifica sua conta. Você a anexa a toda requisição, geralmente em um cabeçalho (HTTP header) chamado Authorization, como na linha Bearer sk_live_... acima.
Trate uma chave de API exatamente como uma senha, porque é isso que ela é. Qualquer um que a tenha pode fazer requisições como se fosse você — e estourar sua fatura ou ler seus dados. Isso se conecta diretamente ao capítulo de segurança, e há uma regra que importa mais do que as outras:
- Nunca coloque uma chave de API em código que vai para o navegador. Tudo o que está no seu é público — usuários podem abrir as ferramentas de desenvolvedor e lê-lo. A IA, ao ser pedida para "chamar a API a partir da página", vai alegremente colar sua chave secreta bem ali. Impeça isso. Chaves secretas pertencem ao servidor.
- Nunca faça de uma chave no . Mesmo que você a apague depois, ela permanece para sempre no histórico, e robôs vasculham repositórios públicos atrás de chaves em minutos.
- Guarde chaves em variáveis de ambiente, não no próprio código — o mesmo padrão coberto no capítulo de segurança.
A chave precisa viajar a partir de um lugar seguro, nunca a partir do navegador. Imagine os dois caminhos — um seguro, um vazamento:
SAFE ✓ LEAK ✗
┌──────────┐ key ┌──────────┐ ┌──────────┐ key ┌──────────┐
│ SERVER │ ─────▶ │ API │ │ BROWSER │ ────▶ │ API │
│ (your │ stays │ │ │ (anyone │ │ │
│ backend)│ hidden │ │ │ can │ │ │
└──────────┘ └──────────┘ │ read it)│ └──────────┘
key in env var └──────────┘
key in frontend = public
Se você algum dia vir uma chave real sentada em um diff, em um arquivo de frontend, ou em uma mensagem de chat, trate-a como já vazada: rotacione-a (gere uma nova, desative a antiga) imediatamente.