Como proteger API keys na Lovable: Secrets e Edge Functions

Resposta rápida: nunca coloque uma API key secreta diretamente no frontend de um app criado na Lovable. Código que roda no navegador pode ser inspecionado por qualquer visitante. Para APIs autenticadas, guarde a credencial em Secrets e faça a chamada por uma Edge Function ou pelo backend seguro da integração.

Por que uma API key não pode ficar no frontend

Aplicações web entregam JavaScript, requisições de rede e outros recursos ao navegador do usuário. Por isso, uma chave inserida em componentes React, arquivos públicos, variáveis expostas ao cliente ou chamadas feitas diretamente pelo navegador deve ser considerada acessível. Esconder o texto na interface não transforma a credencial em segredo.

A documentação de segurança da Lovable orienta separar as responsabilidades: o frontend é público; Edge Functions executam lógica server-side; e o banco aplica controles como RLS. Para credenciais, a fronteira segura deve ficar no servidor.

A arquitetura segura para integrar uma API na Lovable

Para uma API que exige autenticação, use este fluxo: usuário interage com a interface; o frontend envia apenas os dados necessários para uma função server-side; a Edge Function lê a chave armazenada em Secrets; a função chama o serviço externo; e devolve ao navegador somente a resposta necessária. A chave não precisa viajar para o cliente.

1. Identifique se a API realmente exige uma credencial

APIs públicas sem autenticação podem ser chamadas diretamente quando isso for apropriado. Já APIs que usam Bearer token, API key, client secret ou outra credencial privada precisam de uma camada server-side. A própria documentação de integrações da Lovable diferencia esses dois cenários.

2. Salve a chave em Secrets

Ao configurar uma API autenticada com Lovable Cloud, adicione a credencial em Cloud → Secrets. Em projetos que usam Supabase, segredos usados por Edge Functions também devem ficar no gerenciamento de secrets do backend. Não grave a chave em tabelas públicas, arquivos do projeto ou componentes da interface.

3. Faça a chamada externa em uma Edge Function

A Edge Function é o ponto em que você pode ler o secret, montar o cabeçalho de autenticação e chamar a API externa sem entregar a credencial ao navegador. Esse padrão serve para serviços de IA, e-mail, pagamentos e APIs privadas em geral.

4. Valide usuário, permissões e entrada no servidor

Proteger a chave é apenas uma parte. Uma função que usa uma credencial poderosa também precisa validar quem está chamando, quais ações esse usuário pode executar e quais dados foram enviados. Regras críticas não devem depender apenas de validações feitas no frontend.

5. Retorne somente o que o frontend precisa

Evite devolver tokens, cabeçalhos internos, respostas completas desnecessárias ou detalhes sensíveis do provedor. Normalize a resposta da API na função e envie ao navegador somente os campos necessários para a experiência do usuário.

Exemplo prático: API de IA com chave privada

Imagine um app Lovable que recebe um texto e o envia para uma API de IA. O formulário pode permanecer no frontend, mas a requisição autenticada deve passar pelo backend. O navegador envia o texto para a Edge Function; a função valida a sessão e o tamanho da entrada; lê a API key em Secrets; chama o provedor; e retorna apenas o resultado processado.

Esse mesmo desenho vale para uma API de e-mail como Resend. Se você estiver implementando envio transacional, veja também o guia interno Como configurar API de e-mail na Lovable com Resend: passo a passo em https://blog.lovacademy.com.br/api-email-lovable-resend.

Erros que deixam chaves expostas

• Colocar uma secret key diretamente em um componente React.
• Criar uma variável de ambiente que é incorporada ao bundle do frontend e assumir que ela ficou privada.
• Enviar a chave do servidor para o navegador para depois chamar a API externa.
• Salvar credenciais em uma tabela que usuários comuns conseguem consultar.
• Confiar apenas em esconder botões ou rotas da interface para impedir ações privilegiadas.
• Publicar logs que contenham tokens, headers de autorização ou payloads sensíveis.

E se eu já expus uma API key?

Trate a chave como comprometida. Revogue ou rotacione a credencial no provedor, atualize o Secret usado pelo backend e verifique histórico de uso, logs e cobranças. Apenas remover a chave do código atual não é suficiente se ela já foi publicada, enviada para um repositório ou entregue ao navegador.

Checklist antes de publicar

• Nenhuma secret key aparece em código executado no navegador.
• APIs autenticadas são chamadas server-side.
• Secrets estão no armazenamento apropriado do backend.
• Edge Functions validam autenticação e permissões.
• Entradas do usuário são validadas no servidor.
• RLS está configurado para dados que precisam de isolamento por usuário.
• Logs não registram credenciais ou tokens sensíveis.
• O Security view foi revisado antes da publicação.

Se o seu projeto também usa Supabase, complemente essa revisão com o guia Como configurar RLS no Supabase com Lovable: passo a passo em https://blog.lovacademy.com.br/como-configurar-rls-supabase-lovable.

Perguntas frequentes

Posso colocar uma API key em uma variável de ambiente do frontend?

Não quando ela precisa permanecer secreta. Se o valor chega ao código executado no navegador, um usuário pode inspecioná-lo. Segredos devem permanecer no servidor.

Toda API precisa de Edge Function?

Não. APIs públicas que não exigem credenciais podem ser chamadas diretamente em alguns casos. O ponto decisivo é se existe autenticação privada, lógica sensível ou uma regra que não pode ser confiada ao cliente.

Secrets e RLS resolvem a mesma coisa?

Não. Secrets protegem credenciais usadas pelo backend. RLS controla quais linhas do banco cada usuário pode ler ou modificar. Projetos reais frequentemente precisam dos dois.

Onde vejo problemas de segurança na Lovable?

Use a área Security do projeto para revisar banco, código e dependências. A Lovable também recomenda revisar os achados críticos antes de publicar e repetir a análise sempre que autenticação, acesso a dados ou integrações externas mudarem.

Fontes oficiais

• Lovable Security overview: https://docs.lovable.dev/features/security
• Lovable Security best practices: https://docs.lovable.dev/tips-tricks/security-best-practices
• Lovable Integrations: https://docs.lovable.dev/integrations/introduction

Quer testar essa arquitetura em um novo projeto? Crie seu projeto na Lovable: https://link.lovacademy.com.br/lovablee