FixVibe

// docs / baas security / auth0 hardening

Checklist de segurança Auth0: 22 itens

O Auth0 é uma plataforma de identidade-como-serviço com uma enorme superfície — aplicações, APIs (resource servers), tenants, actions, rules (legado), connections e grants. Configuração incorreta de qualquer um é um bypass de auth. Este checklist é uma auditoria de 22 itens através de aplicações, allowlists de callback / logout, tokens e rotação de refresh, actions customizadas, RBAC, detecção de anomalias e monitoramento contínuo. Cada item é verificável no painel Auth0 em menos de 10 minutos.

Para o checklist equivalente no Clerk, veja Checklist de segurança Clerk. Para contexto sobre por que configurações incorretas em nível de identidade são pontos cegos de ferramentas de IA, veja Por que ferramentas de codificação com IA deixam lacunas de segurança.

Tipo de aplicação e tipos de grant

O tipo de aplicação e os tipos de grant habilitados são as configurações de maior impacto no Auth0. Errá-los abre classes de ataque que nenhuma quantidade de código frontend vai fechar.

  1. Use Application Type = Single Page Application para apps apenas no navegador e Regular Web Application para apps renderizados no servidor. O tipo errado permite os grants errados — p. ex., uma Regular Web App com o grant SPA habilita o flow Implicit sem PKCE, que vaza tokens via fragmentos de URL.
  2. Desabilite o tipo de grant Implicit em cada aplicação. Painel → Application → Advanced Settings → Grant Types → desmarque Implicit. O flow Implicit retorna tokens em fragmentos de URL, onde são registrados no histórico do navegador e analytics. Use Authorization Code com PKCE no lugar.
  3. Desabilite o grant Password a menos que você tenha uma necessidade documentada. O grant Resource Owner Password Credentials (ROPC) requer que você lide com senhas de usuário você mesmo — derrotando a maior parte do que você comprou no Auth0. Desabilite a menos que esteja integrando um sistema legado.
  4. Habilite Authorization Code com PKCE em cada cliente público. Painel → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = habilitado. PKCE é requerido para apps móveis e SPAs para prevenir interceptação de código.

Allowlists de URL de callback e logout

Redirecionamentos abertos no caminho de callback OAuth são uma primitiva de roubo de token. A allowlist do Auth0 é sua única defesa.

  1. Defina Allowed Callback URLs ao seu caminho de callback de produção exato — sem wildcards. https://yourapp.com/callback, não https://yourapp.com/*. Callbacks com wildcard deixam atacantes redirecionar tokens para subcaminhos arbitrários do seu domínio.
  2. Defina Allowed Logout URLs como uma lista finita. Mesma regra: apenas URLs explícitas. Um redirecionamento de logout aberto deixa atacantes criar páginas de phishing que parecem com seu estado pós-logout.
  3. Defina Allowed Web Origins apenas à sua origem de produção. Usado para autenticação silenciosa (renovação de token via iframe oculto). Uma origem com wildcard deixa páginas de atacantes realizar auth silenciosa contra seu tenant.
  4. Defina Allowed CORS origins para os endpoints de API, não para a aplicação. Tenant Settings → Advanced → Allowed CORS origins. Padrão é vazio (restrito); adicione apenas origens explícitas que você controla.

Tokens e rotação de refresh

Tempo de vida de token, rotação de refresh e algoritmo de assinatura decidem o raio de explosão de qualquer vazamento de token.

  1. Habilite Rotação de Refresh Token. Application → Refresh Token Settings → Rotation. Cada refresh emite um novo refresh token e invalida o antigo. Combinado com expiração absoluta, isso contém roubo de token.
  2. Defina Refresh Token Reuse Interval em 0 (ou tão baixo quanto sua tolerância a replay permita). O intervalo de reuso deixa um token ser usado duas vezes na mesma janela — desligue a menos que você tenha uma razão específica para mantê-lo.
  3. Defina Absolute Refresh Token Expiry em 14-30 dias, não infinito. Application → Refresh Token Expiration → Absolute Expiration. Auth0 por padrão usa apenas Inactivity, o que significa que uma sessão ociosa pode persistir por anos.
  4. Defina JWT Signature Algorithm em RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 usa assinatura assimétrica para o cliente não conseguir forjar tokens. Nunca use HS256 para aplicações voltadas ao cliente.
  5. Verifique claims aud e iss em cada JWT que sua API recebe. Use o SDK Auth0 oficial no lado do servidor — ele os verifica automaticamente. Parsing JWT feito à mão geralmente pula a validação de audiência, o que é um bypass de auth.

Actions e código customizado

Actions do Auth0 (e Rules legadas) rodam do lado do servidor no login e outros eventos de ciclo de vida. Têm acesso a todo o contexto da requisição. Código inseguro aqui é uma vulnerabilidade em todo o tenant.

  1. Nunca registre event.user ou event.transaction como objeto completo. Eles contêm endereços de e-mail, endereços IP e outros PII. Use apenas registro em nível de campo, e registre apenas o que precisa.
  2. Use a loja de segredos para qualquer chave de API ou URL de webhook. Actions → Edit → Secrets. Nunca coloque inline uma chave de API como literal string no código da action — o código é visível para qualquer um com acesso de editor de Actions no tenant.
  3. Valide entradas antes de persisti-las como user_metadata ou app_metadata. Uma action self-service que escreve event.body.name em user.user_metadata.display_name é um vetor de XSS armazenado se seu frontend renderiza esse campo sem escape.

RBAC e resource servers

Se você usa Auth0 RBAC, o mapeamento role-para-permissão é sua camada de autorização. Erre e qualquer usuário autenticado pode atingir endpoints de admin.

  1. Defina Resource Servers (APIs) explicitamente no painel Auth0, não na hora. Cada API tem um identificador (a audience), scopes e configurações de assinatura. Sem uma API registrada, todos os tokens são emitidos para a implícita "Auth0 Management API" — audiência errada.
  2. Configure Permissions por API e exija-as no seu código com o claim scope. Não verifique membresia de role na lógica da sua aplicação; verifique scopes no token de acesso. Scopes são o mecanismo de autorização nativo do OAuth.
  3. Teste que um usuário autenticado sem o role / scope requerido não pode atingir endpoints privilegiados. Entre como usuário normal, tente chamar POST /api/admin/users/delete. Resposta deve ser 403.

Detecção de anomalias e logs de tenant

Auth0 emite eventos de alto sinal. Configure-os para alertar sua equipe, não apenas ficar em um buffer de log.

  1. Habilite Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Painel → Security → Attack Protection. Cada um está desligado por padrão em planos gratuitos; ligue todos para produção.
  2. Faça stream de logs de tenant para um SIEM ou seus logs de aplicação. Painel → Monitoring → Streams. Auth0 retém logs por 30 dias na maioria dos planos; retenção de longo prazo requer um stream para seu próprio sistema.
  3. Alerte em picos de fcoa (auth cross-origin falha) e fp (login falho). Uma rajada destes em uma janela curta é credential stuffing. Roteie para seu canal de plantão.

Próximos passos

Rode uma varredura do FixVibe contra sua URL de produção — a verificação baas.clerk-auth0 sinaliza client secrets Auth0 no bundle JavaScript e outras classes de exposição de provedor de identidade. Para o equivalente no Clerk, veja Checklist de segurança Clerk. Para a visão geral sobre provedores BaaS, leia Scanner de configurações incorretas de BaaS.

// varra sua superfície baas

Encontre a tabela aberta antes que outra pessoa o faça.

Coloque uma URL de produção. O FixVibe enumera os provedores BaaS com que seu app conversa, identifica seus endpoints públicos e relata o que um cliente não autenticado pode ler ou escrever. Grátis, sem instalação, sem cartão.

  • Plano gratuito — 3 varreduras/mês, sem cartão de cadastro.
  • Identificação BaaS passiva — sem necessidade de verificação de domínio.
  • Supabase, Firebase, Clerk, Auth0, Appwrite e mais.
  • Prompts de correção com IA em cada achado — cole de volta no Cursor / Claude Code.
Rodar varredura BaaS gratuita →

sem necessidade de cadastro

Checklist de segurança Auth0: 22 itens — Docs · FixVibe