Configurações do Supabase Auth para revisar antes de lançar o seu app feito com IA

Quando o Lovable, o Bolt ou outra ferramenta de IA coloca login no seu app, ela escreve as telas e o código. As configurações que decidem o quanto esse login é seguro ficam em outro lugar: no seu projeto do Supabase, em Authentication, e a maioria continua com os valores de quando o projeto foi criado.

Esses padrões servem para começar, não para usuários reais. Este artigo passa pelas configurações que vale mudar antes do lançamento, na ordem em que as verificamos. Nenhuma exige código, e a maioria leva um minuto.

1. Site URL e Redirect URLs #

Depois da confirmação do cadastro, de um magic link ou de uma redefinição de senha, o Supabase manda o usuário de volta ao seu app. Site URL é o destino padrão; Redirect URLs é a lista de outros endereços permitidos.

• Defina a Site URL como o endereço de produção, https://yourapp.com, e não http://localhost:3000. Os e-mails de confirmação e de redefinição usam esse endereço.
• Em Redirect URLs, liste os endereços exatos de produção. Curingas servem para desenvolvimento local e previews, mas mantenha-os restritos.

2. Confirmação de e-mail #

Com Confirm email desligado, qualquer pessoa pode se cadastrar com o endereço de outra e usar a conta na hora. Ligue essa opção nas configurações do provedor de e-mail, a menos que tenha um motivo específico para não fazer isso, e confira se o app trata a etapa de “verifique sua caixa de entrada”.

3. Seu próprio servidor de e-mail (SMTP) #

O envio de e-mail embutido no Supabase é para testes. Ele só envia para membros da sua organização, e o limite padrão de e-mails de autenticação é de 2 por hora: no dia do lançamento, o seu segundo usuário novo não recebe o e-mail de confirmação.

Configure um SMTP próprio com um serviço de envio (Resend, Postmark, Amazon SES, Brevo e outros) no seu domínio. Assim, o e-mail de confirmação sai de no-reply@yourapp.com e você pode aumentar os limites de envio. Para esses e-mails chegarem à caixa de entrada e não ao spam, o domínio precisa de SPF, DKIM e DMARC, os mesmos registros que descrevemos para os e-mails de formulário de contato.

4. Regras de senha #

Nas configurações de senha:

• Tamanho mínimo: o Supabase desaconselha qualquer coisa abaixo de 8 caracteres. Nós usamos 10 ou mais.
• Caracteres obrigatórios: exigir letras e números bloqueia as senhas mais fracas sem criar muito atrito.
• Proteção contra senhas vazadas: recusa senhas que aparecem em vazamentos de dados conhecidos (verificadas no HaveIBeenPwned). Está disponível no plano Pro e acima; se você está no Pro, ligue.

5. Validade de links e códigos #

Enquanto valem, magic links e códigos de uso único equivalem a uma senha. O Supabase recomenda uma validade de uma hora (3600 segundos) ou menos. Se os seus usuários entram com códigos, quanto menor, melhor.

6. CAPTCHA no cadastro, no login e na redefinição de senha #

Bots que encontram o seu formulário de cadastro criam contas falsas, gastam a sua cota de e-mails e testam senhas vazadas no formulário de login. O Supabase Auth aceita CAPTCHA com Cloudflare Turnstile ou hCaptcha no cadastro, no login e na redefinição de senha: você liga no painel (na parte de proteção contra bots e abuso), adiciona o widget aos formulários e envia o token junto com a chamada:

await supabase.auth.signUp({
  email,
  password,
  options: { captchaToken } // from the Turnstile or hCaptcha widget
});

O Turnstile costuma ser invisível para visitantes reais. Com o CAPTCHA ligado, toda chamada de cadastro, login e redefinição precisa de um token, então atualize todos os formulários antes de ativá-lo.

7. Cadastro e provedores que você não usa #

• Se o app é para um grupo fechado (uma equipe, clientes convidados), desligue Allow new users to sign up e convide as pessoas.
• Desligue os provedores que você não usa. Cada provedor ativo é mais uma porta.
• Anonymous sign-ins merecem uma verificação à parte. Usuários anônimos recebem o papel authenticated, então uma política escrita como “qualquer usuário logado pode ler” também deixa entrar quem só clicou em “continuar como visitante”. Se você usa logins anônimos, verifique a claim is_anonymous nas políticas que importam; se não usa, deixe desligado.

8. Troca de e-mail e de senha #

Trocar o endereço de e-mail ou a senha é o caminho pelo qual uma sessão roubada vira uma conta roubada. Mantenha o secure email change ligado (a troca é confirmada no endereço antigo e no novo) e, se o seu plano e as configurações permitirem, exija um login recente antes de trocar a senha.

9. Rate limits #

O Supabase aplica limites de taxa a cadastros, logins, pedidos de código e renovação de tokens. Abra Rate Limits nas configurações de Auth e leia uma vez: depois de configurar o SMTP próprio, suba o limite de e-mails para o que o dia do lançamento exige e deixe o resto como está, a menos que tenha um motivo.

10. MFA, pelo menos para administradores #

Se o seu app tem uma área administrativa ou lida com dinheiro ou dados de saúde, ofereça autenticação multifator e torne-a obrigatória para administradores. As políticas podem então exigi-la nas tabelas sensíveis: o token do usuário diz se ele entrou com um segundo fator (aal2).

O que essas configurações não fazem #

As configurações de Auth decidem quem pode entrar. Elas não decidem o que um usuário logado pode ler e alterar; isso é trabalho do Row Level Security no banco de dados. Se você ainda não verificou, comece pela checagem de RLS em 10 minutos e passe pelo checklist de segurança antes do lançamento para o resto do app.

O nosso Security Check gratuito examina o seu app publicado de fora, só com leitura, incluindo a configuração de autenticação e as regras do banco de dados, e envia por escrito os problemas mais graves.