Supabase com Next.js virou o stack favorito de founders que usam IA para construir SaaS. É rápido, barato, escalável e a integração funciona bem.
O problema é que esse stack tem armadilhas específicas de segurança que aparecem com frequência em sistemas construídos dessa forma. Vou listar as que vejo mais.
1. SERVICE_ROLE_KEY no frontend
O Supabase tem duas chaves principais. A anon key é pública, segura para usar no browser, limitada pelo Row Level Security. A service_role_key é a chave de administrador, bypassa todo o RLS, tem acesso irrestrito ao banco.
O erro mais grave que existe nesse stack é a service_role_key chegando ao bundle JavaScript que o browser carrega. Qualquer usuário que inspecionar o código fonte da sua aplicação encontra essa chave e tem controle total do seu banco de dados.
Isso acontece quando a chave é usada em componentes client-side ou quando a separação entre Server Components e Client Components não foi feita corretamente.
A verificação é simples: abra o DevTools, vá em Sources, busque por service_role. Se aparecer, é crítico.
2. RLS desativado ou incompleto
Row Level Security é o mecanismo do Supabase que garante que cada usuário acessa apenas os seus próprios dados. Quando está bem configurado, mesmo que alguém descubra a anon key, não consegue ler dados de outros usuários.
O problema é que RLS precisa ser configurado tabela por tabela, política por política. Em sistemas construídos com IA, é comum ter RLS ativo em algumas tabelas e ausente em outras, especialmente nas criadas depois, quando o desenvolvedor já não está pensando nisso.
3. CORS aberto demais
Access-Control-Allow-Origin: * em uma aplicação autenticada significa que qualquer site na internet pode fazer requisições para sua API e potencialmente ler as respostas. Para uma landing page pública, aceitável. Para uma API que serve dados de usuários autenticados, é um problema.
4. Tokens de sessão acessíveis via JavaScript
Por padrão, o Supabase armazena o token de sessão de forma acessível ao JavaScript no browser. Isso significa que qualquer script injetado na página, via XSS, consegue roubar a sessão do usuário.
A combinação de token acessível via JavaScript com ausência de Content-Security-Policy é especialmente perigosa.
5. Ausência de CSP
Content Security Policy é o header que diz ao browser quais scripts têm permissão de executar na página. Sem ele, um ataque XSS bem-sucedido tem alcance total. Com ele, o dano fica contido.
Em Next.js com App Router, configurar CSP exige atenção, especialmente por causa dos scripts inline que o framework gera. Mas é possível e necessário.