Diga ao navegador como proteger seu app publicado
Seu app publicado pode dizer ao navegador o que carregar, onde suas páginas podem aparecer e quais recursos do aparelho podem ser usados.
antes de começar
O VibeCodeWall verifica o app público por fora e acompanha mudanças importantes ao longo do tempo. Ele não precisa ver seu código particular.
Controle o que seu app pode carregar
em palavras simples
Dê ao navegador uma lista curta de lugares confiáveis para carregar imagens, fontes, pagamentos e outros conteúdos.
Quando alguém abre seu app, o navegador pode buscar arquivos e informações em vários lugares. Suas páginas talvez usem um serviço de fontes, um local para guardar imagens, uma empresa de pagamentos, um serviço de métricas, um mapa ou um chat de suporte. Cada lugar adicional cria uma nova dependência. Se um endereço desconhecido for permitido sem um motivo claro, ele poderá influenciar o que o visitante vê ou o que o navegador executa. Comece identificando os serviços externos intencionais e a função de cada um.
Seu app pode enviar instruções junto com cada página. Desenvolvedores chamam essas instruções de headers de segurança, ou cabeçalhos de segurança. Uma delas manda o navegador carregar conteúdo apenas do próprio app e de uma pequena lista aprovada. O nome técnico é Content Security Policy, abreviado como CSP. Ela pode criar regras separadas para imagens, fontes, conexões e pequenos arquivos de programa que tornam a página interativa. Uma boa política deve refletir seu app, não ser copiada de um projeto sem relação com ele.
Comece com a menor lista que mantém o produto funcionando. Teste a página inicial, a entrada na conta, a recuperação de conta, os formulários, os pagamentos, os downloads, as imagens, os mapas e as telas administrativas. Se algo parar, descubra o endereço exato usado pelo serviço necessário. Não resolva liberando qualquer site ou todos os endereços de uma grande empresa. Também peça uma explicação para cada exceção, pois uma permissão sem explicação será difícil de revisar depois. Essas instruções criam uma barreira adicional, mas não tornam confiável um serviço externo que já era duvidoso.
- ▸Permita o endereço do próprio app e somente os endereços externos necessários para funções que você reconhece.
- ▸Repita os testes sempre que adicionar pagamentos, chat, métricas, mapas, fontes ou vídeo.
risco comum
Um novo item de marketing é adicionado às pressas, e o navegador recebe permissão para carregar pequenos arquivos de programa de quase qualquer lugar. Uma mudança posterior em um desses lugares pode alterar o que os clientes veem.
o que fazer agora
Peça à ferramenta de IA que examine o app publicado, identifique cada fonte externa necessária, crie uma regra restrita e explique todo endereço que não conseguir reconhecer.
peça isto à sua IA
Primeiro, explique em linguagem simples de quais lugares meu app publicado carrega imagens, fontes, pagamentos, métricas, mapas, chat, vídeo e arquivos de programa interativos. Depois, examine o projeto e a configuração da hospedagem. Crie uma Content Security Policy, também chamada de CSP, que permita somente o próprio app e as fontes externas que você confirmar como necessárias. Evite curingas amplos e exceções inseguras. Se uma fonte não estiver clara, não tente adivinhar: liste-a para minha decisão. Aplique a política no local correto da hospedagem e forneça testes exatos para página inicial, entrada na conta, recuperação de conta, formulários, pagamentos, imagens, downloads, mapas e telas administrativas.
Mantenha toda visita em uma conexão protegida
em palavras simples
Garanta que cada visitante chegue à versão protegida de todos os endereços públicos, inclusive os antigos e alternativos.
As informações percorrem um caminho entre o navegador do visitante e seu app. Uma conexão protegida dificulta que outras pessoas nesse caminho leiam ou alterem o conteúdo enviado. Os navegadores costumam mostrar um cadeado quando ela está ativa. Sua empresa de hospedagem talvez já ofereça essa versão, mas isso é apenas o começo. Alguém ainda pode digitar um endereço antigo sem proteção, usar um favorito salvo ou visitar um endereço alternativo configurado de outra maneira.
Primeiro, faça cada endereço sem proteção levar imediatamente à versão protegida correspondente. Confira o domínio principal, endereços de páginas importantes, domínios alternativos e endereços menores que aparecem antes do domínio principal. Desenvolvedores chamam esses endereços menores de subdomínios. Confirme que cada endereço incluído possui um certificado digital válido, que funciona como a comprovação usada pelo navegador para reconhecer a conexão protegida. Renove esses certificados antes do vencimento.
Depois que todos os endereços incluídos funcionarem corretamente, você poderá mandar o navegador lembrar que deve usar a versão protegida. O nome técnico é HTTP Strict Transport Security, abreviado como HSTS. Aplique essa instrução com cuidado, pois o navegador pode guardá-la por bastante tempo. Não inclua todos os subdomínios antes de verificar cada um. Uma ferramenta antiga de suporte ou uma área esquecida de clientes pode ficar inacessível se não aceitar a conexão protegida. Revise tudo ao trocar a hospedagem, mudar o domínio ou adicionar um subdomínio.
- ▸Digite cada endereço sem o prefixo protegido e confirme que ele leva diretamente à versão protegida.
- ▸Verifique cada subdomínio antes de aplicar uma única regra a todos eles.
risco comum
A página principal usa uma conexão protegida, mas uma área antiga de clientes não. Uma pessoa abre um favorito salvo e chega ao endereço que ficou esquecido.
o que fazer agora
Faça uma lista de todos os domínios e subdomínios públicos, confira a versão protegida e o certificado de cada um e só depois ative a instrução de proteção lembrada pelo navegador.
peça isto à sua IA
Primeiro, liste todos os domínios e subdomínios públicos usados por este app e explique quais já aceitam conexões protegidas do navegador. Faça cada endereço sem proteção levar diretamente à versão protegida. Depois de confirmar certificados válidos para todos os endereços incluídos, adicione HTTP Strict Transport Security, também chamado de HSTS, com duração e alcance cautelosos. Não inclua todos os subdomínios sem verificar cada um. Mostre as mudanças exatas de configuração e forneça testes no navegador para o domínio principal, domínios alternativos, páginas importantes e todos os subdomínios encontrados.
Impeça que sites enganosos cerquem suas páginas
em palavras simples
Evite que sites desconhecidos coloquem seu app verdadeiro dentro de uma página enganosa controlada por eles.
Um site pode mostrar outro site dentro de uma área retangular da própria página. Isso é útil quando você decide colocar um formulário de agendamento no site de um parceiro confiável. Em muitos apps, porém, não há motivo para permitir essa prática. Um site desconhecido poderia cercar sua verdadeira tela de entrada ou pagamento com uma marca falsa e instruções enganosas. A tela interna pertence a você, mas os textos, botões e promessas ao redor não.
O nome técnico dessa área retangular é frame, e a configuração defensiva é chamada de proteção contra frames. Uma política moderna de carregamento pode declarar que nenhum outro site tem permissão para colocar suas páginas nessa área ou que apenas parceiros nomeados podem fazer isso. Uma instrução mais antiga do navegador se chama X-Frame-Options. Sua ferramenta de IA deve escolher configurações que funcionem juntas, sem criar regras contraditórias.
Bloqueie esse comportamento por padrão nas telas de entrada, recuperação de conta, informações de clientes, pagamentos e administração. Se um parceiro realmente precisar mostrar uma página, permita somente o endereço exato do site dele e apenas a página necessária, quando sua plataforma conseguir aplicar essa diferença. Registre o motivo comercial e teste tanto em um site permitido quanto em uma página de teste não aprovada. Um logotipo ou endereço parecido com o conhecido não basta para confiar no parceiro; confirme o acordo com a pessoa responsável pela parceria.
- ▸Bloqueie a exibição externa de páginas com senhas, pagamentos, informações de clientes ou ações administrativas.
- ▸Quando essa exibição for necessária, informe o parceiro confiável exato em vez de permitir qualquer site.
risco comum
Uma página falsa de descontos cerca sua verdadeira tela de entrada com instruções que pedem ao cliente uma ação desnecessária. A pessoa pode confiar na tela interna real e não perceber que a página ao redor é desonesta.
o que fazer agora
Decida se alguma página tem um motivo documentado para aparecer no site de um parceiro e bloqueie esse comportamento em todos os outros casos.
peça isto à sua IA
Primeiro, explique se alguma página do meu app foi criada para aparecer dentro de outro site. Depois, adicione proteção contra frames para impedir que sites desconhecidos coloquem minhas páginas dentro das páginas deles. Use a regra moderna frame-ancestors na Content Security Policy do app e acrescente X-Frame-Options somente quando ela oferecer suporte compatível. Bloqueie esse comportamento nas páginas de entrada, recuperação de conta, informações de clientes, pagamentos e administração. Se o projeto já tiver uma exceção documentada para parceiro, preserve apenas o endereço exato desse site confiável e explique o motivo. Forneça passos para testar um caso permitido e um caso bloqueado.
Desative comportamentos que seu app não precisa
em palavras simples
Limite tentativas de adivinhar arquivos, compartilhamento de endereços, uso da câmera, localização e outros comportamentos desnecessários.
Os navegadores tentam ajudar. Eles podem adivinhar como abrir um arquivo, compartilhar parte do endereço atual quando o visitante segue um link ou permitir que uma página peça câmera, microfone ou localização. Esses comportamentos podem apoiar funções reais, mas não deveriam ficar disponíveis apenas porque ninguém os desativou. Anote o que seu produto realmente precisa. Por exemplo, uma agenda de consultas provavelmente não precisa do microfone, enquanto um app de atendimento por vídeo provavelmente precisa.
Seu app pode enviar instruções separadas para essas escolhas. Os nomes técnicos são X-Content-Type-Options, Referrer-Policy e Permissions-Policy. A primeira manda o navegador não reinterpretar um arquivo como se fosse de outro tipo apenas porque seu conteúdo parece diferente. A segunda controla quanto do endereço da página atual é compartilhado quando alguém segue um link. A terceira determina quais recursos do navegador e do aparelho as páginas podem solicitar. Escolha configurações conservadoras e só permita um recurso quando o produto realmente depender dele.
Essas instruções são defesas adicionais, não substitutos para um app bem construído. Senhas, chaves de pagamento, códigos de acesso e informações de clientes ainda devem permanecer em um sistema protegido no servidor e ser entregues somente a quem pode recebê-los. Atualizações, cópias de segurança, verificações de permissão e testes continuam importantes. Depois de publicar uma mudança, examine o app público por fora para confirmar que as instruções realmente estão presentes. O VibeCodeWall pode fazer essa verificação externa e acompanhar mudanças importantes ao longo do tempo sem ver seu código particular.
- ▸Desative câmera, microfone, localização e outros recursos do aparelho que o produto não utiliza.
- ▸Verifique novamente as instruções públicas após mudanças de hospedagem ou a inclusão de novas funções.
risco comum
Um arquivo para baixar recebe uma identificação pouco clara, e o navegador tenta interpretá-lo de uma forma inesperada. Em outra página, o app pede um recurso do aparelho que o cliente nunca esperava usar.
o que fazer agora
Peça configurações conservadoras, teste todas as funções usadas pelos clientes e continue acompanhando o app público para encontrar instruções ausentes ou alteradas sem intenção.
peça isto à sua IA
Primeiro, identifique quais recursos do navegador e do aparelho este app realmente usa, incluindo câmera, microfone, localização, exibição em tela cheia e pagamentos. Depois, adicione X-Content-Type-Options com uma configuração que impeça tentativas de adivinhar o tipo do arquivo, escolha uma Referrer-Policy voltada à privacidade e crie uma Permissions-Policy que desative todo recurso não utilizado. Preserve apenas os recursos ligados a uma necessidade existente do produto. Explique cada decisão em linguagem simples, aplique as configurações no local correto da hospedagem e forneça testes exatos para depois da publicação. Confirme também que senhas, chaves de pagamento, códigos de acesso e informações de clientes não aparecem em arquivos enviados aos visitantes.
Checklist rápido
- 01Liste os serviços externos que seu app usa de propósito, incluindo pagamentos, fontes, imagens, métricas, mapas, chat e vídeo.
- 02Peça à ferramenta de IA que permita conteúdo somente do seu app e dos serviços externos que ela confirmar como necessários.
- 03Teste entrada na conta, formulários, pagamentos, imagens, downloads e páginas de conta depois de mudar as regras.
- 04Digite a versão sem proteção de cada endereço e confirme que ela leva imediatamente à versão protegida.
- 05Impeça sites desconhecidos de colocar suas páginas de entrada, pagamento, conta e administração dentro das páginas deles.
- 06Desative câmera, microfone, localização e outros recursos do aparelho quando seu app não precisar deles.
- 07Mantenha senhas, chaves de pagamento, códigos de acesso e informações de clientes em um sistema protegido no servidor, não em arquivos enviados aos visitantes.
- 08Verifique novamente o app público ao mudar hospedagem, domínio, pagamentos, métricas, chat, mapas ou vídeos incorporados.
FAQ
Essas instruções deixam meu app totalmente seguro?
Não. Elas reduzem riscos específicos ligados ao navegador. Você ainda precisa verificar permissões, proteger informações de clientes, manter atualizações e cópias de segurança e testar o app.
Posso copiar as configurações de outro app?
Use outro app apenas como referência. Pagamentos, imagens, mapas, chat e hospedagem podem ser diferentes, então as configurações devem refletir seu produto e ser testadas nele.
Por que uma ferramenta de pagamento ou um item externo parou de funcionar?
A nova regra de carregamento talvez não inclua um endereço realmente necessário. Peça à ferramenta de IA que identifique o endereço exato e sua finalidade. Adicione somente esse endereço e repita os testes importantes.
O que o VibeCodeWall verifica?
O VibeCodeWall verifica o app público por fora e pode acompanhar mudanças importantes ao longo do tempo. Ele não precisa ver seu código particular e não instala as configurações por você.