Isolado por design: como um runtime de mini-programas isola código de terceiros

A porta que o WebView deixa aberta

Um WebView não é um sandbox: é um motor de navegador completo solto dentro do seu app com os privilégios do seu app. O Android documenta o WebView abertamente como essencialmente um motor de navegador de todas as funções (Chromium) com uma pegada de memória significativa e uma arquitetura multiprocesso complexa. Como a página roda com a identidade do app que a incorpora, qualquer capacidade que o host conceda — acesso a arquivos, credenciais salvas, a ponte nativa — é alcançável por qualquer JavaScript que a página carregue. A ponte que permite que a web chame o nativo é, por construção, uma porta aberta: a página é ao mesmo tempo o conteúdo não confiável e a superfície privilegiada.

Esse é o cerne do problema do sandbox no WebView: não há um muro sólido entre o documento web e o app nativo. Uma página maliciosa ou simplesmente com bugs pode atravessar a ponte, ler o armazenamento compartilhado e abusar das permissões do host. É exatamente por isso que os navegadores isolam cada site em seu próprio processo de render, e que o iOS atribui a cada app seu próprio contêiner reforçado por um sandbox MAC em nível de kernel: a plataforma sabe que código não confiável deve ser cercado.

O isolamento como propriedade de primeira ordem

Um runtime de mini-programas inverte o padrão. Em vez de conceder ao documento incorporado poder nativo, coloca cada mini-programa dentro de seu próprio sandbox de execução e intermedia cada chamada privilegiada pela plataforma. O modelo do WeChat — aquele que todo o ecossistema copiou — divide um programa em uma camada lógica e uma camada de visão, ambas sob o controle do cliente, sem DOM direto e sem alça nativa direta. Como descrevem as análises de engenharia de plataforma, a camada lógica não tem acesso ao DOM e não pode ler nem modificar a árvore de página, enquanto a camada de visão não executa a lógica de negócio escrita pelo desenvolvedor. Elas só se encontram por uma ponte de mensagens serializada.

Sob o ponto de vista da segurança, esse limite é o ponto inteiro: o JavaScript de um programa não pode tocar os dados de outro programa, não pode alcançar o host e não pode chamar uma API sensível sem a intermediação explícita e declarada da plataforma. O isolamento não é uma configuração que o desenvolvedor lembra de ativar: é a forma do próprio runtime.

O que os muros realmente bloqueiam

Concretamente, um sandbox reforçado pelo runtime detém três coisas que um WebView não pode:

Risco	WebView	Runtime de mini-programas
Dados entre programas	Um contexto web compartilhado	Armazenamento isolado por programa
Poder nativo	Ponte JS aberta	Capacidade intermediada pela plataforma
Execução dinâmica	eval / código remoto	Removido no nível do runtime

A camada lógica normalmente remove por completo document, window e a execução tipo eval dinâmico, de modo que a rota clássica de escalada de XSS para nativo não existe. As requisições de rede são forçadas pela lista de domínios permitidos da plataforma sobre HTTPS, o que elimina a rota silenciosa de exfiltração. APIs sensíveis — localização, câmera, pagamento, arquivos — são declaradas em um manifesto, revisadas no envio e intermediadas, para que um programa de terceiros não pegue em silêncio o que o host nunca pensou em compartilhar.

O dividendo de conformidade

Essa é a propriedade que torna financeável abrir o app a parceiros. Sem isolamento, convidar código de terceiros para sua superfície mais confiável significa herdar o risco e a responsabilidade de cada terceiro. Com isolamento, o host mantém a conta, a carteira e o canal de notificação, enquanto cada mini-programa vive em uma caixa cercada da qual não pode escapar. Segurança de conteúdo, residência de dados e controles anti-abuso deixam de ser esperança e passam a ser responsabilidade da plataforma.

Reflete o mesmo princípio que os fabricantes de sistemas operacionais já aplicam: o App Sandbox da Apple e as políticas MAC do kernel do iOS dão a cada app uma área privada do sistema de arquivos e bloqueiam o acesso entre apps em nível de kernel, precisamente para que um app vulnerável ou malicioso não se mova lateralmente. Um runtime de mini-programas aplica essa mesma disciplina um nível abaixo: não apenas app contra app, mas programa contra programa dentro de um único app.

Como o Cross Mini App o reforça

O Cross Mini App é construído como um runtime genérico com o isolamento como primitiva. Cada mini-programa recebe seu próprio limite de execução sandbox, uma superfície de API wx.* uniforme e mediada por capacidades, e uma rota de distribuição governada — revisão de envio, segurança de conteúdo e controles anti-abuso — antes que qualquer código alcance um usuário. Um programa escrito uma vez roda em cada host que adote o runtime, mas roda dentro do muro, nunca fora dele.

Essa é a diferença entre incorporar web e incorporar um runtime: a web traz a porta aberta; um runtime traz a cerca — e a cerca é o que torna um catálogo aberto seguro de operar.