API Key exposta no frontend? Proteja com um proxy Workers em 5 minutos

Criei uma pequena ferramenta que chamava a API do ChatGPT e coloquei a API Key direto no código frontend. No dia seguinte, a conta sofreu uso indevido de mais de 300 yuans: milhares de chamadas em uma noite. Variável de ambiente também não resolve; variáveis do Vite ou Webpack acabam empacotadas no arquivo JS final, e o usuário consegue ver a requisição completa no painel Network.

A solução tradicional é subir um backend para servir de proxy. Só que servidor custa dinheiro, exige configuração de ambiente, certificado SSL e CORS. Com Cloudflare Workers, dá para implantar um proxy de API em 5 minutos. A API Key fica em uma variável de ambiente no servidor, fora do alcance do frontend. É gratuito, com cota de 100 mil requisições por dia. Este artigo mostra como montar isso.

Por que a API Key não pode ficar no frontend

O código frontend é totalmente transparente

Muita gente acha que usar um arquivo .env ou import.meta.env do Vite já é seguro. Na prática, isso é só uma conveniência de desenvolvimento. Depois do build, todas as variáveis de ambiente são hardcoded nos arquivos JS.

Se quiser confirmar, teste em qualquer projeto frontend em produção: pressione F12, abra as ferramentas de desenvolvedor, vá para o painel Network e recarregue a página. Você verá todas as requisições de API, incluindo headers, body e parâmetros de URL.

Mesmo que você use ofuscação ou minificação, isso só deixa o código um pouco mais difícil de ler. A chamada de API precisa enviar a Key real, e isso não tem como esconder. Criptografia também não resolve: o código para criptografar e descriptografar está no frontend, então o usuário consegue ver.

Resumindo, o frontend roda no navegador do usuário. Tudo que você consegue fazer ali, o usuário também consegue fazer. Não há saída mágica.

Quanto custa ter a chave roubada

Antes eu pensava: quem perderia tempo vasculhando meu código para roubar uma API Key? Depois descobri que existe gente na internet trabalhando exatamente com isso.

Há ferramentas que escaneiam projetos no GitHub automaticamente procurando API Keys expostas. Quando encontram, alguém pode usar para consumir a API de graça ou revender para outras pessoas. A API da OpenAI cobra por token; uma chave roubada pode gerar algumas centenas de yuans em uma noite, e casos graves passam de mil.

Vi uma discussão em um fórum de desenvolvedores sobre alguém que criou uma página de chat com IA e colocou a Key no frontend. Depois que a chave foi raspada, as chamadas dispararam, e a fatura do mês passou de 2.000 dólares. A pessoa conseguiu recorrer depois, mas o processo foi bem estressante.

E não é só OpenAI. Google Maps API, APIs de clima e APIs de tradução, desde que sejam cobradas por uso, também correm o risco de uso indevido.

O problema da solução tradicional

Depois de entender o risco, comecei a pesquisar como resolver. A resposta mais comum era: “suba um backend para fazer proxy”.

Parece simples. Na prática:

• Custo: mesmo servidores em nuvem baratos, como opções leves da Alibaba Cloud ou Tencent Cloud, custam cerca de 50 a 100 yuans por mês. Não é absurdo, mas pesa para projeto pessoal pequeno.
• Configuração complexa: instalar Node.js ou outro runtime, configurar Nginx como proxy reverso, emitir certificado SSL, habilitar HTTPS e lidar com CORS. Só entender tudo isso já pode consumir meio dia.
• Manutenção: servidor precisa de atualização, monitoramento e reinício quando cai. Para projeto pequeno, é trabalho demais.

Funções serverless de provedores chineses, como Alibaba Cloud Function Compute e Tencent Cloud Functions, até ajudam a economizar, mas a configuração é mais complicada, o cold start é mais lento e a documentação nem sempre é amigável. Tentei algumas vezes e não consegui avançar.

API Gateway soa profissional, mas normalmente é produto de nível empresarial. Para um desenvolvedor solo, a barreira de entrada é alta demais.

Vantagens da solução com Cloudflare Workers

Gratuito e com bom desempenho

O plano gratuito do Cloudflare Workers oferece 100 mil requisições por dia. Para projetos pessoais, isso costuma ser mais do que suficiente. A pequena ferramenta que fiz chama a API algumas centenas de vezes por dia, então a cota gratuita sobra.

{{< geo:stats >}}

100 mil/dia | Cota gratuita | Sobra para projetos pessoais
5 minutos | Tempo de deploy | Da criação até entrar no ar
Economia de 50-100 yuans/mês | Comparação de custo | Em relação a manter um servidor próprio

{{< /geo:stats >}}
Além disso, a Cloudflare tem mais de 200 data centers pelo mundo, e seu código é implantado automaticamente nesses pontos. Quando o usuário acessa, a requisição é roteada para o ponto mais próximo, o que deixa a resposta bem rápida. Diferente de um servidor tradicional, em que usuários distantes da região escolhida sentem mais latência.

Outro ponto importante: Workers não sofre com cold start. Funções serverless, como AWS Lambda, podem levar alguns segundos para iniciar depois de um período sem requisições. Workers geralmente responde em milissegundos, com experiência próxima à de um servidor tradicional.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Deploy extremamente simples

Na primeira vez que usei Workers, levei mesmo cerca de 5 minutos entre criar a conta e concluir o deploy. Não é exagero.

Você não precisa configurar ambiente de servidor, instalar Node.js, Nginx ou emitir certificado SSL, porque Workers já fornece HTTPS. O que você precisa fazer é:

1. Escrever o código, normalmente um arquivo JS com algumas dezenas de linhas
2. Rodar um comando: wrangler publish
3. Pronto

Depois do deploy, a Cloudflare entrega um domínio parecido com your-worker.your-subdomain.workers.dev, pronto para uso. Se quiser usar seu próprio domínio, basta vinculá-lo no painel, sem configuração extra.

Compare com a abordagem tradicional: comprar servidor -> configurar ambiente -> escrever código -> configurar Nginx -> emitir certificado -> fazer deploy -> testar. Só o fluxo já cansa.

Resolve CORS de forma natural

Chamadas do frontend para APIs de terceiros frequentemente encontram erros de CORS, como: Access to fetch at 'xxx' from origin 'yyy' has been blocked by CORS policy.

Isso acontece por causa das restrições de segurança do navegador: requisições entre domínios diferentes podem ser bloqueadas. A solução tradicional seria o provedor da API adicionar headers de CORS na resposta, mas você não controla a configuração de uma API de terceiros.

Com Workers como proxy, o problema fica bem mais simples:

• O frontend chama o endereço do seu próprio Worker, por exemplo https://api.yourdomain.com
• O Worker chama a API de terceiros
• O Worker adiciona os headers de CORS ao devolver a resposta

Para o navegador, você está chamando uma API do seu próprio domínio. Para a API de terceiros, quem chama é o servidor do Workers. Nos dois lados, o problema de CORS deixa de existir.

Antes, ao chamar a API do Amap, eu recebia erro de CORS o tempo todo. Depois de colocar Workers como proxy, duas linhas de código resolveram.

Prática: crie seu primeiro proxy de API

Agora que as vantagens estão claras, vamos montar um proxy passo a passo. Vou usar a OpenAI API como exemplo, mas o método é quase igual para outras APIs.

Primeiro passo: preparar o ambiente

1. Criar uma conta Cloudflare

Acesse cloudflare.com e crie uma conta. A gratuita já serve. O cadastro é simples; basta validar o e-mail.

2. Instalar o Wrangler CLI

Wrangler é a ferramenta oficial de linha de comando da Cloudflare para criar e implantar Workers.

npm install -g wrangler

Se você ainda não tem Node.js instalado, baixe em nodejs.org primeiro.

3. Fazer login e autorizar

wrangler login

Esse comando abre o navegador para você autorizar o acesso. Confirme, e a ferramenta de linha de comando poderá gerenciar seus Workers.

Segundo passo: criar o projeto Worker

wrangler init openai-proxy

O comando fará algumas perguntas:

• “Would you like to use TypeScript?” -> escolha No, a menos que você já esteja confortável com TS
• “Would you like to create a new Worker?” -> escolha Yes
• “Would you like to install dependencies?” -> escolha Yes

Depois disso, uma pasta de projeto será gerada com uma estrutura parecida com esta:

openai-proxy/
├── src/
│   └── index.js       # seu código fica aqui
├── wrangler.toml      # arquivo de configuração
└── package.json

Terceiro passo: escrever o código do proxy

Abra src/index.js, apague o código padrão e substitua por este:

export default {
  async fetch(request, env) {
    // Permite apenas requisições POST
    if (request.method !== 'POST') {
      return new Response('Método não permitido', { status: 405 });
    }
    // Lê a OpenAI API Key da variável de ambiente
    const apiKey = env.OPENAI_API_KEY;
    if (!apiKey) {
      return new Response('API Key não configurada', { status: 500 });
    }
    try {
      // Lê o corpo enviado pelo frontend
      const body = await request.json();
      // Chama a OpenAI API real
      const response = await fetch('https://api.openai.com/v1/chat/completions', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'Authorization': `Bearer ${apiKey}`,  // usa a Key do servidor
        },
        body: JSON.stringify(body),
      });
      // Lê os dados da resposta
      const data = await response.json();
      // Devolve ao frontend e adiciona headers de CORS
      return new Response(JSON.stringify(data), {
        status: response.status,
        headers: {
          'Content-Type': 'application/json',
          'Access-Control-Allow-Origin': '*',  // permite acesso de qualquer domínio
          'Access-Control-Allow-Methods': 'POST',
          'Access-Control-Allow-Headers': 'Content-Type',
        },
      });
    } catch (error) {
      return new Response(JSON.stringify({ error: error.message }), {
        status: 500,
        headers: { 'Content-Type': 'application/json' },
      });
    }
  },
};

O código faz quatro coisas:

1. Recebe a requisição POST do frontend
2. Lê a API Key real da variável de ambiente, que o frontend nunca vê
3. Usa essa Key para chamar a OpenAI API
4. Devolve o resultado ao frontend e adiciona headers de CORS

Quarto passo: configurar Secrets para armazenar a API Key

Esta é a etapa mais importante. A API Key não pode ficar no código; ela deve ser armazenada com o recurso Secrets da Cloudflare.

Rode:

wrangler secret put OPENAI_API_KEY

Depois de pressionar Enter, o terminal pedirá o valor da Key. Cole sua OpenAI API Key e confirme.

Essa Key será salva com criptografia nos servidores da Cloudflare e não aparece em texto puro no painel. No código, você lê com env.OPENAI_API_KEY.

E no desenvolvimento local?

Crie um arquivo .dev.vars na raiz do projeto:

OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx

Esse arquivo é só para desenvolvimento local. Nunca envie para o Git. Adicione esta linha ao .gitignore:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

.dev.vars

Quinto passo: testar localmente

No diretório do projeto, rode:

wrangler dev

Isso inicia um servidor local, por padrão em http://localhost:8787. Você pode testar com Postman ou com código frontend:

fetch('http://localhost:8787', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    model: 'gpt-3.5-turbo',
    messages: [{ role: 'user', content: 'Hello!' }],
  }),
})
  .then(res => res.json())
  .then(data => console.log(data));

Se a resposta da OpenAI voltar normalmente, o proxy está funcionando.

Sexto passo: fazer deploy em produção

Depois do teste, faça o deploy com um comando:

wrangler publish

Em poucos segundos estará pronto. Ao terminar, a Cloudflare mostrará um endereço parecido com:

https://openai-proxy.your-subdomain.workers.dev

Troque o endereço da API no frontend por esse endereço e pronto: a API Key não será exposta no navegador.

Se quiser usar seu próprio domínio, vá à página de Workers no painel da Cloudflare, selecione seu Worker -> Settings -> Triggers -> Add Custom Domain, informe o domínio, como api.yourdomain.com, e siga as instruções de DNS.

Técnicas avançadas e boas práticas

O código acima já roda, mas ainda há alguns pontos que dá para melhorar.

Evite abuso do seu proxy

Neste momento, seu Worker é público. Qualquer pessoa que souber o endereço pode chamá-lo. Se alguém abusar da API, sua cota gratuita pode acabar rápido e, em casos graves, gerar custo.

Validação simples por token

Você pode adicionar uma verificação simples:

export default {
  async fetch(request, env) {
    // Valida o token no header da requisição
    const token = request.headers.get('X-API-Token');
    if (token !== env.MY_SECRET_TOKEN) {
      return new Response('Não autorizado', { status: 401 });
    }
    // ... restante da lógica do proxy
  },
};

Depois, defina um segredo com wrangler secret put MY_SECRET_TOKEN. Na chamada do frontend, envie esse token:

fetch('https://your-worker.workers.dev', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Token': 'your-secret-token',  // este token também pode ficar em variável de ambiente do frontend
  },
  body: JSON.stringify(data),
});

Esse token ainda pode ser visto no frontend, mas pelo menos adiciona uma barreira. Você pode trocá-lo periodicamente ou distribuir tokens diferentes para usuários diferentes.

Lista de IPs ou origens permitidas

Se sua aplicação só roda em domínios específicos, limite a origem:

const allowedOrigins = ['https://yourdomain.com', 'http://localhost:3000'];
const origin = request.headers.get('Origin');
if (!allowedOrigins.includes(origin)) {
  return new Response('Proibido', { status: 403 });
}

Suporte a várias APIs

Se você precisa fazer proxy de várias APIs diferentes, separe por caminho:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    // Encaminha para APIs diferentes conforme o caminho
    if (url.pathname.startsWith('/openai')) {
      return proxyOpenAI(request, env);
    } else if (url.pathname.startsWith('/maps')) {
      return proxyMaps(request, env);
    } else {
      return new Response('Não encontrado', { status: 404 });
    }
  },
};
async function proxyOpenAI(request, env) {
  // Lógica do proxy da OpenAI
}
async function proxyMaps(request, env) {
  // Lógica do proxy da API de mapas
}

Assim, um único Worker consegue lidar com várias APIs.

Tratar requisições OPTIONS para suporte completo a CORS

O código anterior só trata POST. Mas antes de enviar uma requisição cross-origin, o navegador pode fazer uma requisição OPTIONS de preflight. Um tratamento completo de CORS fica assim:

export default {
  async fetch(request, env) {
    // Trata a requisição CORS de preflight
    if (request.method === 'OPTIONS') {
      return new Response(null, {
        headers: {
          'Access-Control-Allow-Origin': '*',
          'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS',
          'Access-Control-Allow-Headers': 'Content-Type, X-API-Token',
          'Access-Control-Max-Age': '86400',
        },
      });
    }
    // ... tratamento normal da requisição
  },
};

Monitoramento e debug

O painel do Cloudflare mostra a operação do Worker:

• Número de requisições
• Taxa de erro
• Tempo de resposta

Se quiser acompanhar logs em tempo real, use:

wrangler tail

O comando imprime os logs das requisições e facilita o debug. Saídas feitas com console.log() no código também aparecem.

Perguntas frequentes

O que fazer se a cota gratuita acabar?

100 mil requisições por dia costumam ser suficientes para projetos pessoais. Meus próprios projetos rodaram por meses sem ultrapassar a cota gratuita.

Se realmente não bastar, o plano pago do Workers também não é caro: 5 dólares por mês para 10 milhões de requisições. Comparado a comprar servidor, é um preço bem razoável.

Workers é estável? Pode cair de repente?

A Cloudflare é uma das maiores provedoras de CDN do mundo, com infraestrutura muito confiável. Usei por mais de meio ano sem encontrar indisponibilidade.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

O SLA oficial é de 99,99%, e a chance de problema é muito menor do que manter seu próprio servidor.

Posso usar meu próprio domínio?

Sim. Vincule o domínio no painel da Cloudflare e configure um registro DNS. O processo inteiro leva cerca de 5 minutos e não exige certificado extra, porque o HTTPS é automático.

Como fica a velocidade de acesso na China?

A Cloudflare tem pontos de presença na China, então a velocidade costuma ser aceitável. Nos meus testes, o tempo de resposta geralmente ficou entre 100 e 300 ms, bem mais rápido do que chamar uma API estrangeira diretamente.

Ainda assim, não é tão bom quanto um serviço otimizado especificamente para a China. Se você precisa de latência muito baixa, pode considerar uma plataforma serverless local, como Alibaba Cloud Function Compute. Só que a configuração é mais complexa.

Além de JavaScript, há suporte a outras linguagens?

Workers hoje suporta principalmente JavaScript e TypeScript. Se você prefere outra linguagem, pode considerar compilar para WebAssembly, mas a barreira é maior.

Para um proxy simples de API, JavaScript dá conta tranquilamente.

Isso é realmente seguro?

Desde que você não devolva a API Key ao frontend na resposta, é seguro. Secrets são armazenados com criptografia e não aparecem em texto puro no painel.

Claro, você ainda precisa controlar acesso para evitar abuso do proxy. As opções acima, como validação por token e lista de IPs ou origens permitidas, ajudam bastante.

Conclusão

O vazamento de API Key me incomodou por bastante tempo. No começo, parecia que só havia duas opções: aceitar o risco ou pagar por um servidor.

Quando encontrei o Cloudflare Workers, percebi que dava para resolver de forma muito mais simples. Deploy em 5 minutos, gratuito, API Key armazenada com segurança e CORS resolvido no mesmo pacote. Para projetos pessoais, Workers chega bem perto da solução ideal.

Se você está criando um projeto que precisa chamar APIs de terceiros, vale muito testar esse método. Não é difícil; seguindo os passos acima, em meia hora você consegue deixar tudo funcionando.

O código está detalhado o suficiente para copiar, adaptar e usar. Se tiver dúvida, consulte a documentação oficial da Cloudflare ou deixe um comentário; quando eu vir, respondo.

Só um lembrete final: depois do deploy, configure controle de acesso. Não deixe seu proxy aberto para abuso. Um token simples ou uma restrição de domínio já ajudam bastante.

Agora é só criar uma conta Cloudflare e testar.