Escolha Quais Sites Podem Ler as Respostas do Seu App

Imagine que você usou uma ferramenta de IA para criar um agendamento, uma loja ou uma área do cliente. A página pede a outra parte do app informações como horários, dados do pedido ou informações do cliente. O navegador da pessoa recebe a resposta e mostra o resultado. A dúvida é se apenas páginas dos endereços que você aprovou podem ler essa resposta ou se uma página de um site sem relação com você também consegue lê-la.

Os navegadores têm uma regra para decidir quando uma página de um site pode ler uma resposta vinda de outro endereço. O nome técnico é CORS, sigla de Cross-Origin Resource Sharing. O app envia instruções ao navegador com os endereços aprovados. O navegador lê essas instruções antes de entregar a resposta à página. Essa regra reduz compartilhamentos indesejados entre sites, mas representa apenas uma parte da proteção do app.

Projetos iniciais gerados por IA às vezes incluem uma configuração que deixa páginas de qualquer site ler determinadas respostas. Isso pode eliminar uma mensagem confusa do navegador durante um teste rápido. Também pode passar despercebido quando o app começa a atender clientes reais. Se a resposta contém informações de clientes, histórico de pedidos, dados da conta ou resultado de uma ação paga, a liberação para todos os sites precisa ser revista.

Algumas informações são oferecidas de propósito para uso público, como horários de funcionamento ou um painel de clima aberto. Nesses casos, uma configuração ampla pode fazer sentido para aquelas respostas específicas. Ela deve ser uma escolha que você consegue explicar, não uma sobra conveniente. Separe respostas públicas daquelas ligadas a clientes. Nas demais, use a menor lista possível de endereços exatos e retire prévias que sua equipe não controla mais.

Essa regra do navegador não decide quem entrou na conta, quem é dono de um pedido ou quem pode alterar uma assinatura. Ela também não impede uma pessoa ou outro programa de computador de falar com o app sem usar uma página comum. Às vezes, o pedido chega ao app mesmo quando o navegador impede a página de ler a resposta. Por isso, o app precisa conferir a identidade e a permissão antes de mostrar informações ou concluir uma ação importante.

O trabalho sensível deve acontecer na parte remota do app que visitantes não conseguem baixar. Os desenvolvedores chamam esse computador de servidor e costumam chamar esse local de lado do servidor. Senhas, chaves de pagamento e códigos de acesso que abrem dados ou permitem gastar dinheiro devem ficar ali. O servidor também precisa confirmar que a pessoa pode usar o cadastro solicitado. Restringir endereços não corrige uma conferência ausente nem protege uma chave colocada em arquivos baixáveis.

O navegador pode lembrar que um cliente entrou na conta e anexar automaticamente uma prova dessa sessão aos pedidos seguintes. O nome técnico dessas informações anexadas é credenciais. Quando o app as aceita, uma lista ampla de sites exige mais cuidado, pois as respostas podem estar ligadas a uma conta real. Aprove somente os endereços exatos que precisam desse comportamento e confirme que cada um continua sob seu controle.

Um símbolo comum que significa liberar todos não funciona corretamente com respostas que aceitam essas informações de sessão. Não contorne a mensagem do navegador copiando qualquer endereço solicitante para a resposta nem aceitando um padrão vago. Ações como trocar um endereço, fazer um pedido ou atualizar uma assinatura também precisam confirmar que a pessoa quis e podia realizar a mudança. A regra de compartilhamento entre sites não faz essas conferências.

Revise a lista sempre que adicionar um endereço público, substituir uma prévia, incluir entrada em conta, conectar pagamentos ou criar uma nova resposta para o navegador. Depois de restringir a lista, teste os recursos normais pelo site verdadeiro. Teste também por um endereço não aprovado e confirme que a página dele não consegue ler a resposta. Se algo parar, inclua somente o endereço verificado que precisa funcionar, sem reabrir a permissão para todos.

Mantenha um registro curto dos endereços aprovados, seus responsáveis e o motivo de cada um. O VibeCodeWall pode conferir a versão pública do app por fora, sem ver código particular, e acompanhar mudanças importantes ao longo do tempo. Combine essa conferência externa com seus próprios testes de conta e permissão. A revisão contínua importa porque uma configuração segura pode ser substituída, copiada de forma errada ou ampliada durante uma mudança futura.