1 em cada 9 Apps expõem chaves do Supabase: Veja como isso acontece

O vídeo inicia apresentando um relatório alarmante que indica que um em cada nove aplicativos expõe credenciais do Supabase diretamente no JavaScript baixado pelo navegador. O narrador enfatiza que isso não é o resultado de um ataque hacker sofisticado, mas sim um erro acidental no pipeline de envio do código. Embora existam chaves que devam ser públicas por natureza, o erro humano faz com que segredos privados sejam incluídos indevidamente. Esta seção serve como um alerta sobre como a falta de atenção no processo de build pode comprometer a segurança. O conceito central aqui é que, se a chave está no código cliente, ela já está comprometida.

Nesta parte, explica-se o funcionamento técnico por trás da exposição através de frameworks populares como Next.js, Vite e SvelteKit. O palestrante destaca que prefixos como "NEXT_PUBLIC" funcionam como uma etiqueta de envio que instrui a ferramenta de build a incluir a variável no pacote do cliente. É um erro comum esquecer essa lógica básica durante o desenvolvimento acelerado de projetos. O autor reforça que o nome do framework não é um selo de segurança, mas apenas uma instrução técnica de visibilidade. Entender essa distinção é fundamental para evitar que chaves privadas sejam marcadas incorretamente.

O foco aqui recai sobre a diferença entre chaves "anon" e chaves de serviço como a "service_role". O narrador esclarece um ponto crítico: a Segurança em Nível de Linha (RLS) do Supabase é completamente ignorada quando se utiliza chaves de serviço. Se um desenvolvedor expõe essa chave mestra no front-end, todas as políticas de segurança criadas anteriormente tornam-se inúteis. Isso demonstra que a arquitetura de segurança depende da manutenção do sigilo dessas credenciais específicas. O alerta é claro: confiar apenas na RLS sem proteger a chave de serviço é uma estratégia perigosa.

Através de um sandbox pessoal, o autor demonstra como é fácil encontrar essas chaves em um aplicativo Next.js real após o comando de build. Ele mostra que, ao abrir as ferramentas de desenvolvedor do Chrome, qualquer pessoa pode localizar a URL e a chave do Supabase no arquivo JavaScript compilado. O vídeo ressalta que não é necessário explorar vulnerabilidades complexas; basta ler o que o aplicativo já enviou publicamente. Além disso, é mencionado que bots e pessoas mal-intencionadas escaneiam a internet constantemente em busca desses padrões. Esta demonstração visual serve para validar a gravidade do problema discutido anteriormente.

A solução proposta consiste em mover todas as operações privadas para rotas de API ou funções de servidor, garantindo que o navegador nunca tenha acesso direto às chaves sensíveis. O autor sugere uma estratégia em camadas que inclui a ativação rigorosa da RLS e a implementação de testes automatizados. Para evitar a reintrodução do erro, recomenda-se o uso de ferramentas de varredura de segredos (Secret Scanning) no CI/CD e regras de revisão de código (PR). A rotação de chaves também é citada como uma medida essencial caso haja suspeita de exposição. Essas etapas formam um plano de ação robusto para desenvolvedores que buscam profissionalizar sua segurança.

O vídeo encerra com um desafio prático para os espectadores: gerar o build de seus próprios aplicativos e buscar por termos como "supabase" ou "service_role" na saída. Se qualquer informação privada for encontrada, o desenvolvedor deve considerar a chave comprometida, trocá-la imediatamente e refatorar a lógica para o lado do servidor. A mensagem final é simplificada em uma frase memorável: "Se está no pacote (bundle), é público". O autor reforça a importância de agir rapidamente antes que a exposição cause danos reais. O encerramento foca na responsabilidade do desenvolvedor sobre o que é entregue ao cliente final.