Evite que o login leve clientes a uma página falsa
Seu app deve levar o cliente somente a páginas escolhidas e ainda controladas por você. Uma lista ampla pode terminar em um destino antigo ou falso.
antes de começar
Depois de entrar, o cliente deve voltar somente para uma lista curta de páginas revisadas e controladas por você.
Entenda a volta depois que a pessoa entra
em palavras simples
Seu app envia o cliente por alguns instantes para confirmar quem ele é e depois o traz de volta a uma página escolhida.
Imagine um cliente tocando em Continuar com Google ou Continuar com Apple. Ele sai do app por alguns instantes, confirma sua identidade e espera voltar a uma página conhecida. O app e a empresa que confirma a entrada usam um endereço salvo para decidir onde essa volta termina. Se o endereço estiver errado ou aceitar opções demais, o cliente poderá chegar a uma página antiga, inesperada ou muito parecida com a sua, onde alguém pede senha, dados de pagamento ou outro código de acesso.
A ideia segura é simples: aprove somente as páginas exatas que realmente recebem clientes depois da entrada. O nome técnico é endereço de redirecionamento OAuth. OAuth é o sistema técnico que permite usar uma conta de empresas como Google ou Apple para entrar em outro app sem entregar a esse app a senha do Google ou da Apple. O endereço de redirecionamento é o destino aprovado usado quando essa confirmação termina.
- ▸Anote a página que o cliente normalmente vê depois de entrar.
- ▸Inclua outro destino somente quando uma jornada real do cliente precisar dele.
- ▸Investigue todos os endereços que você não reconhecer.
risco comum
Uma configuração ampla aceita várias páginas em vez de um único destino. Uma página antiga com o nome da empresa continua aprovada, embora ninguém mais cuide dela.
o que fazer agora
Entre com uma conta de teste, copie o endereço completo exibido no final e compare com a página que você pretendia mostrar.
peça isto à sua IA
Inspecione este app e as configurações do serviço de login. Mostre todos os endereços de redirecionamento OAuth configurados, onde cada um foi definido e qual jornada do cliente o utiliza. Explique tudo para uma pessoa iniciante. Sinalize padrões amplos, endereços antigos de teste, prévias temporárias e entradas que não representam uma página exata. Ainda não faça alterações.
Veja por que uma lista ampla ameaça contas
em palavras simples
Cada destino adicional vira mais uma página que precisa continuar sob seu controle, bem cuidada e confiável.
Pode parecer prático aceitar um site inteiro, todas as páginas abaixo dele ou vários endereços temporários enquanto o app muda. O problema pode continuar muito tempo depois que essa necessidade acaba. Uma pessoa contratada pode parar de cuidar da página, um projeto de demonstração pode ser abandonado ou um endereço temporário de hospedagem pode passar para outro responsável. O serviço de entrada continuará tratando aquele destino como aprovado até alguém removê-lo.
Uma página desonesta nem sempre precisa capturar a senha diretamente para causar prejuízo. Ela pode copiar suas cores e textos, dizer que houve uma falha e pedir que o cliente informe senha, cartão de pagamento, código de recuperação ou dados da conta. Esse tipo de imitação tem um nome técnico: phishing. Mandar o cliente somente para páginas exatas que você controla reduz a quantidade de lugares que poderiam ser usados para criar essa confusão.
- ▸Não aprove um site inteiro quando uma única página de retorno basta.
- ▸Remova destinos criados para demonstrações e prévias encerradas.
- ▸Registre quem controla e mantém cada página aprovada.
risco comum
Uma prévia temporária foi aprovada durante a criação do app. Meses depois, a equipe já não a controla, mas o serviço de entrada ainda a considera permitida.
o que fazer agora
Abra as configurações do serviço de entrada e classifique cada item como necessário agora, necessário somente para testes ou desnecessário.
peça isto à sua IA
Prepare uma proposta de limpeza dos endereços de redirecionamento OAuth deste app. Separe páginas públicas usadas por clientes das páginas de teste e prévia. Para cada entrada, informe quem parece controlá-la, por que ela existe e se um endereço exato pode substituir um padrão amplo. Mostre lado a lado as listas atual e proposta, mas não altere nada.
Confira cada parte do endereço
em palavras simples
Dois endereços podem parecer quase iguais e ainda levar a páginas controladas por pessoas diferentes.
Leia cada endereço aprovado do começo ao fim. Confira a escrita, o nome principal do site, qualquer nome adicional colocado antes dele e a informação da página que aparece depois da barra. Não confie em um endereço apenas porque sua marca aparece em algum ponto. Uma área de clientes, um site de ajuda, uma campanha antiga e uma prévia temporária podem parecer relacionados, embora sejam administrados por contas diferentes.
O nome principal do site tem um nome técnico: desenvolvedores o chamam de domínio. Uma palavra adicional antes desse nome, como conta em conta.exemplo.com, também tem um nome técnico: subdomínio. O começo seguro mostrado como https também importa. O nome técnico é HTTPS, e ele ajuda o navegador a proteger informações durante o caminho. Confirme que cada endereço completo abre a página pretendida e que sua equipe ainda controla a conta usada para publicá-la.
- ▸Compare cada item, caractere por caractere, com a página pública.
- ▸Confirme a finalidade e o responsável por cada nome adicional do site.
- ▸Confira se o destino usa o endereço seguro indicado pela empresa de hospedagem.
risco comum
A lista contém a página atual dos clientes e um site antigo, com nome parecido, usado em um lançamento anterior. O cliente talvez não perceba que o endereço antigo já não faz parte do app.
o que fazer agora
Crie um registro com cada endereço aprovado, sua finalidade, seu responsável e a data do último teste.
peça isto à sua IA
Revise, caractere por caractere, a lista completa de endereços de redirecionamento OAuth. Procure erros de escrita, domínios antigos, subdomínios desnecessários, hospedagens temporárias, inícios de endereço sem proteção e páginas que talvez não estejam mais sob nosso controle. Explique cada preocupação em linguagem simples e não faça alterações.
Teste o mesmo caminho usado pelo cliente
em palavras simples
Um teste real confirma se a lista menor funciona sem depender de suposições.
Depois de reduzir a lista proposta, teste cada jornada comum antes de remover um destino da configuração pública. Comece pela página inicial, use cada botão de entrada, conclua o processo com uma conta de teste e anote o endereço final. Teste também convites, conexões entre contas ou retornos de compra quando houver uma etapa de entrada. Evite usar dados de clientes reais nessas verificações.
Se um teste falhar, não aceite imediatamente todas as páginas para contornar o erro. Primeiro identifique a única página que deve receber o cliente. Desenvolvedores chamam essa página de callback; o nome técnico é callback. Aprove o endereço exato somente quando ele pertencer ao app público e for necessário para uma jornada documentada. Uma mensagem clara de erro durante o teste é mais fácil de investigar do que enviar alguém silenciosamente a uma página nunca revisada.
- ▸Crie um teste para cada botão de entrada e cada jornada especial.
- ▸Anote o endereço final esperado antes de mudar as configurações.
- ▸Repita os testes em um celular e em um computador.
risco comum
Uma mudança visual causa erro na entrada, então alguém aprova todas as páginas para fazer o erro desaparecer. O app volta a funcionar, mas passa a aceitar muitos destinos desnecessários.
o que fazer agora
Teste a lista menor em uma configuração segura de testes, aplique-a ao app público e repita as jornadas dos clientes.
peça isto à sua IA
Crie um plano de testes de entrada fácil para iniciantes. Inclua cada botão de login, convite, conexão entre contas e jornada de compra que faça a pessoa entrar. Para cada teste, informe a página inicial, as ações, o endereço de callback esperado, o resultado esperado e a evidência que devo guardar. Não sugira padrões amplos de redirecionamento.
Continue verificando enquanto o app muda
em palavras simples
Destinos antigos podem permanecer ou reaparecer quando o site, os colaboradores e as opções de entrada mudam.
Revise as páginas de retorno aprovadas sempre que trocar o nome do site, a empresa de hospedagem, o serviço de entrada, a área do cliente ou uma prévia temporária. Faça outra revisão quando um colaborador sair. Mantenha a lista nas anotações de publicação e defina uma pessoa para confirmar que cada destino é exato, atual, necessário e ainda controlado pela equipe.
Uma verificação externa acrescenta outro ponto de vista útil. A VibeCodeWall verifica o app público por fora e acompanha mudanças importantes ao longo do tempo. Ela não precisa acessar códigos que não estão públicos. Essa visão externa não substitui a revisão da lista salva no serviço de entrada, pois é ali que as páginas de retorno são aprovadas. Use tanto a verificação pública quanto a revisão periódica das configurações.
- ▸Revise os destinos depois de cada mudança importante no app.
- ▸Retire colaboradores antigos da conta do serviço de entrada.
- ▸Teste novamente as páginas que permanecem aprovadas após campanhas ou mudanças visuais.
- ▸Use verificações externas contínuas para notar mudanças públicas importantes.
risco comum
Uma campanha termina, mas sua página de retorno continua aprovada. Ninguém mais a testa, e mudanças posteriores podem torná-la confusa ou insegura para os clientes.
o que fazer agora
Inclua a revisão dos destinos em toda checklist de publicação e programe verificações recorrentes do app público e das configurações de entrada.
peça isto à sua IA
Adicione uma verificação recorrente de segurança às anotações de publicação e manutenção deste projeto. Ela deve confirmar que cada endereço de redirecionamento OAuth é exato, ainda necessário, controlado por nós, protegido com HTTPS e testado pela jornada pública do cliente. Também deve exigir a remoção de prévias e campanhas antigas, registrar o nome do revisor e a data, e lembrar do acompanhamento externo do app público para mudanças importantes.
Checklist rápido
- 01Liste as páginas exatas que o cliente deve abrir depois de entrar.
- 02Remova endereços antigos de teste, demonstração e prévia temporária.
- 03Confira a escrita completa de cada endereço aprovado.
- 04Confirme que sua equipe ainda controla todas as páginas aprovadas.
- 05Separe as configurações de teste das usadas pelo app público, quando possível.
- 06Teste cada botão de entrada com uma conta criada para testes.
- 07Revise a lista após trocar o endereço do site, a hospedagem ou o serviço de entrada.
- 08Peça à sua ferramenta de IA que explique a finalidade de cada destino.
- 09Verifique o app público com frequência para perceber mudanças importantes.
FAQ
Para que serve o endereço de retorno usado na entrada?
É a página exata que o app pode mostrar depois que uma empresa externa termina de confirmar a pessoa. O nome técnico é endereço de redirecionamento OAuth.
Preciso aprovar todas as páginas do app?
Normalmente, não. Aprove somente as páginas específicas que precisam receber o cliente depois de uma jornada de entrada ou conexão entre contas.
Posso deixar páginas de prévia aprovadas?
Somente quando elas ainda forem necessárias, estiverem sob controle da sua equipe, ficarem separadas da configuração pública quando possível e forem testadas regularmente. Caso contrário, remova-as.
O que devo fazer com um endereço que não reconheço?
Não tente adivinhar. Descubra quem o controla e qual jornada do cliente precisa dele. Se não conseguir confirmar as duas informações, mantenha-o fora da lista pública até que uma pessoa responsável faça a verificação.