Impeça Sites Desconhecidos de Ler as Respostas do Seu App
Seu app pode estar permitindo que qualquer site leia respostas com informações de clientes. Veja o que essa configuração faz, o que ela não protege e como limitá-la.
antes de começar
Um app público não precisa deixar qualquer outro site ler respostas com informações de clientes.
O que essa permissão de compartilhamento significa
em palavras simples
O navegador separa os sites, mas seu app pode permitir que sites escolhidos leiam suas respostas.
Quando alguém abre seu site, o navegador, como Chrome ou Safari, recebe os arquivos que montam a página. Depois, a página pode pedir a outro computador um pedido, perfil, agendamento ou outra informação. Esse outro computador executa a parte do app que guarda informações e toma decisões. Os desenvolvedores chamam esse computador de servidor. Seu site normalmente precisa ler as respostas dele para mostrar as informações certas à pessoa que está usando o app.
O navegador também tem uma regra interna de separação. Em termos simples, uma página costuma ser impedida de ler respostas ligadas a outro endereço de site, a menos que receba permissão. O nome técnico é política de mesma origem. Uma origem é a combinação exata do tipo de endereço, do nome do site e, em alguns casos, de um número que identifica a conexão. Seu app pode enviar instruções dizendo quais origens podem ler uma resposta. O nome técnico desse compartilhamento controlado é Compartilhamento de Recursos entre Origens, mais conhecido pela sigla CORS. Imagine uma lista de convidados que o navegador consulta antes de mostrar a resposta a outro site.
- ▸Mantenha na lista somente endereços de sites que você reconhece e controla.
- ▸Lembre que pequenas diferenças no endereço podem representar entradas separadas.
risco comum
Um app de agendamentos libera todos os sites porque uma visualização inicial não funcionava. A regra aberta continua ativa quando clientes começam a usar o app real.
o que fazer agora
Anote todos os endereços de sites que devem ler respostas do app, incluindo o site principal e qualquer endereço temporário de teste que ainda seja realmente necessário.
peça isto à sua IA
Analise este app e mostre onde ele informa ao navegador quais endereços de sites podem ler suas respostas. O nome técnico dessa configuração é CORS. Liste todos os endereços permitidos agora, explique em linguagem simples por que cada entrada pode existir e identifique qualquer regra que libere todos os sites. Não altere nada ainda.
Por que isso importa e até onde protege
em palavras simples
Limitar o compartilhamento ajuda o navegador, mas o app ainda precisa verificar quem está pedindo informações de clientes.
Imagine que uma cliente entra no app e pede para ver um pedido. O app deve primeiro confirmar quem ela é e se aquele pedido pertence a ela. Só depois deve devolver nome, endereço, itens comprados ou situação do pagamento. A regra de compartilhamento do navegador acrescenta uma barreira útil: ela pode impedir que uma página sem relação leia essa resposta pelo navegador da cliente. Isso importa porque as pessoas costumam manter vários sites abertos e não deveriam precisar confiar em todas as páginas que visitam.
Essa barreira do navegador não é o cadeado principal das informações de clientes. Uma pessoa ou um programa automático pode falar diretamente com o computador que executa o app, sem usar uma página comum. Nesse caso, a regra do navegador pode nem participar. O app precisa tomar sua própria decisão em cada pedido. O nome técnico é verificação de permissão no servidor, porque ela acontece no computador que executa o app, e não somente na página exibida ao visitante. CORS não identifica o cliente, não confirma a titularidade, não protege uma senha sozinho e não impede todo pedido indesejado. Ele define se uma página de uma origem pode ler a resposta de outra origem. Use essa regra junto com as verificações de entrada e titularidade, nunca no lugar delas.
- ▸Confira a pessoa conectada antes de devolver informações de clientes.
- ▸Confirme que o pedido, perfil, agendamento ou conta pertence a essa pessoa.
risco comum
Uma loja limita a lista de sites, mas devolve qualquer pedido quando recebe seu número. Quem descobrir outro número pode receber informações de outro cliente porque a titularidade não foi conferida.
o que fazer agora
Revise toda ação que mostra informações de clientes, altera uma conta ou inicia um pagamento. Confirme que o computador que executa o app verifica a pessoa conectada e a titularidade antes de responder.
peça isto à sua IA
Revise todas as partes deste app que devolvem informações de clientes, alteram uma conta ou iniciam um pagamento. Confirme que o computador que executa o app verifica quem entrou e se o cadastro solicitado pertence a essa pessoa. O nome técnico das verificações feitas nesse computador é verificação de permissão no servidor. Informe o que estiver faltando e proponha correções seguras sem depender somente de CORS.
Uma configuração aberta que merece revisão
em palavras simples
Uma regra que aceita qualquer site pode ajudar em um teste rápido, mas costuma ser ampla demais para um app usado por clientes.
Ferramentas de criação com IA às vezes escolhem uma regra muito ampla para fazer uma visualização inicial funcionar rapidamente. Essa regra pode mostrar um asterisco no lugar de endereços específicos. Em linguagem simples, o asterisco pode significar que qualquer site está convidado a ler certas respostas no navegador. O nome técnico dessa regra é curinga. O efeito exato depende de outras configurações, inclusive de o navegador enviar ou não informações da pessoa conectada, mas a presença do asterisco merece revisão. Não presuma que ele é inofensivo.
Troque uma liberação geral desnecessária por uma lista curta de endereços exatos. Preste atenção: um endereço iniciado com http é diferente de outro iniciado com https, e um nome com www pode ser diferente do mesmo nome sem www. Um endereço de visualização também pode ser separado do endereço público. Mantenha um endereço de teste somente enquanto alguém estiver usando-o e registre o motivo. Não copie um padrão amplo apenas para fazer uma mensagem do navegador desaparecer. Se um formulário externo, uma área de compras incorporada ou uma página de parceiro precisar ler respostas, confirme quem controla essa página e quais informações ela receberá antes de incluir o endereço.
- ▸Prefira endereços exatos a um asterisco ou padrão amplo.
- ▸Remova endereços temporários assim que o teste terminar.
risco comum
Uma loja adiciona um asterisco durante a montagem, depois passa a guardar nomes e detalhes de pedidos, mas nunca revisa a regra porque as páginas parecem funcionar normalmente.
o que fazer agora
Peça à ferramenta de IA para substituir a liberação geral desnecessária pelos endereços públicos exatos que você controla. Preserve um endereço de teste somente se ele ainda tiver responsável e finalidade.
peça isto à sua IA
Atualize a configuração de compartilhamento no navegador deste app. O nome técnico é CORS. Troque qualquer curinga desnecessário, que é o asterisco que libera todos os sites, por uma lista exata contendo apenas os endereços públicos usados pelo app. Mantenha um endereço de teste ou visualização somente se ele for necessário agora, registre o motivo e mostre a lista final antes de fazer a mudança.
O que fazer depois de reduzir a lista
em palavras simples
Teste a experiência real, registre os endereços aprovados e confira tudo novamente quando o app mudar.
Depois de mudar a lista, abra o site real em uma janela comum do navegador. Entre, veja as informações da conta, carregue um pedido ou agendamento, salve uma alteração e saia. Teste também toda página pública que carrega informações. Se algo parar de funcionar, não volte a liberar todos os sites. Anote o endereço exato da página, confirme que você o controla e adicione somente esse endereço se ele realmente precisar ler a resposta. A ausência de um endereço legítimo é um problema de configuração, não um motivo para manter a lista aberta.
Guarde um registro curto com cada endereço aprovado, sua finalidade e a pessoa responsável por removê-lo quando for temporário. Revise esse registro quando a ferramenta de IA refizer parte do app, quando o site público mudar de endereço ou quando uma função nova conectar outro site. Essas mudanças podem reabrir a regra sem chamar atenção ou deixar uma visualização antiga na lista. O VibeCodeWall confere o app público pelo lado de fora; ele não vê código privado. Ele pode ajudar você a perceber mudanças públicas importantes ao longo do tempo. Continue revisando a lista interna e as verificações feitas para pessoas conectadas, pois a conferência externa e a revisão interna observam partes diferentes do problema.
- ▸Teste as ações importantes dos clientes logo depois da mudança.
- ▸Repita a revisão após mudança de endereço, função importante ou nova conexão externa.
risco comum
Um novo visual usa outro endereço. Para corrigir uma página quebrada, alguém libera todos os sites e depois esquece de desfazer a mudança temporária.
o que fazer agora
Guarde a lista aprovada e os resultados dos testes nas anotações do app. Crie um lembrete para remover endereços temporários e continue acompanhando mudanças importantes no app público.
peça isto à sua IA
Crie e execute uma revisão do compartilhamento no navegador deste app. O nome técnico é revisão de CORS. Confira os endereços exatos permitidos, sinalize asteriscos e endereços de visualização sem uso, teste a entrada, a consulta de informações de clientes, o salvamento de alterações da conta e a saída no site público real, e produza uma lista final mostrando o que passou, o que falhou e o que ainda precisa de confirmação humana.
Checklist rápido
- 01Liste os endereços exatos dos sites que devem funcionar com o app.
- 02Procure uma regra que libera todos os sites, muitas vezes mostrada como um asterisco.
- 03Remova endereços antigos de testes e visualizações temporárias.
- 04Mantenha a verificação da pessoa conectada sempre que o app retornar informações de clientes.
- 05Teste a entrada, a consulta da conta, o salvamento de mudanças e a saída.
- 06Registre por que cada endereço permitido é necessário.
- 07Repita a revisão sempre que o app ou o endereço do site mudar.
- 08Use o VibeCodeWall para conferir o app público pelo lado de fora e acompanhar mudanças importantes.
FAQ
Limitar a lista de sites deixa meu app privado?
Não. Isso apenas ajuda o navegador a decidir quais sites podem ler respostas. O app ainda precisa confirmar quem entrou e se essa pessoa pode ver ou alterar as informações solicitadas.
Um asterisco é sempre perigoso?
O efeito depende do restante da configuração, mas ele deixa a regra ampla e merece revisão. Quando possível, um app usado por clientes deve trabalhar com endereços exatos e aprovados.
Por que meu site parou de funcionar depois que reduzi a lista?
Pode estar faltando um endereço legítimo ou ele pode estar escrito de outra forma. Confirme o endereço completo que você controla e inclua somente a forma realmente usada pelo app.
O VibeCodeWall consegue examinar meu código privado?
Não. O VibeCodeWall confere o app público pelo lado de fora e acompanha mudanças públicas importantes ao longo do tempo.