Um WebView executa o conteúdo web com todos os privilégios do app host, e a ponte JavaScript é uma superfície de escalonamento de privilégios sem muros. No Android, o addJavascriptInterface injeta um objeto Java em cada frame —incluindo iframes— sem forma de verificar a origem de quem chama; antes do Android 4.2 era execução remota de código direta, e hoje uma ponte ampla mais conteúdo refletido ainda é XSS que executa código nativo com as permissões do seu app. O web.dev confirma que o WebView não tem isolamento de site real e entrega ao host seus cookies e seu DOM. Em 2026, a CVE-2026-103922 (Capacitor, CVSS 9.6) mostrou a falha do limite de mesma origem em um app híbrido em produção. Um runtime próprio do host traça o muro: mínimo privilégio, por origem, com controle de capacidades.
A ponte confia em quem a chama
A ponte nativa é a porta entre a web e o nativo, e por padrão está destrancada. O addJavascriptInterface do Android expõe um objeto Java a cada frame do WebView, incluído qualquer iframe, e a própria plataforma avisa que não há mecanismo para verificar a origem do frame que chama. A consequência é direta: injete um frame malicioso em uma página legítima e esse frame pode invocar seus métodos nativos. Apps voltados para API 16 ou anterior podiam ser controlados por completo pelo JavaScript; mesmo hoje, refletir conteúdo de usuário não confiável em um WebView com ponte habilitada é uma rota de XSS que executa Java com as permissões do app host —escalonamento de privilégios, não um defeito menor. Pontes baseadas em MessageChannel só são mais seguras se você mesmo adicionar a verificação de origem; sem ela, mensagens de qualquer remetente são aceitas.
Sem isolamento de site não há muros reais
Um navegador reforçado separa páginas não confiáveis em processos isolados para que uma aba não leia os cookies nem a memória de outra. O WebView não é isso. Segundo o web.dev, antes do Android 8.0 o renderizador rodava no mesmo processo do app, e mesmo em sistemas novos todas as páginas e todas as instâncias de WebView ainda compartilham um único processo —o isolamento de site real é impossível. Foi isso que expôs bilhões de dispositivos ao Meltdown e ao Spectre: uma página maliciosa podia tentar ler dados de origem cruzada que jamais deveria ver. O WebView também entrega ao host acesso completo ao conteúdo renderizado, incluídos cookies e DOM, e carece dos indicadores de segurança de um navegador real —a barra de endereços que o usuário vê pode não coincidir com a página exibida, mesmo sobre HTTPS, sem API para detectar.
Uma falha de 2026 tornou isso real
Não é teoria. Em 2026, o Capacitor —um framework híbrido amplamente usado— publicou a CVE-2026-103922, com pontuação CVSS 9.6. Sua guarda de navegação verificava o esquema e o host da URL, mas não sua rota, então um link manipulado podia alcançar um endpoint proxy interno servido na própria origem do app. A camada nativa então buscava conteúdo controlado pelo atacante e o devolvia sob a origem confiável do app, permitindo que JavaScript malicioso rodasse com privilégios de mesma origem —lendo localStorage, cookies e qualquer capacidade nativa exposta por plugins registrados. Corresponde a CWE-346 (erro de validação de origem) e CWE-441 (confused deputy). Desativar o plugin HTTP não ajudou, porque o manipulador continuava disponível. Um link normal, renderizado dentro do app, virou uma rota de execução de scripts com toda a confiança do app.
A solução do runtime
Um runtime próprio do host trata a web como não confiável por padrão e traça um limite de segurança explícito. A ponte é por origem e de mínimo privilégio: uma página de uma entrada de catálogo não confiável não alcança um manipulador de credenciais ou de dispositivo, apenas as capacidades que o host concede explicitamente. Os contextos web são isolados por entrada, a navegação é verificada quadro a quadro, e a camada nativa verifica, em vez de confiar, cada chamada. O muro é escrito em uma política, não deixado a um padrão que confia em quem bate à porta.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Exposição da ponte | Objeto Java em cada frame, sem origem | Por origem, mínimo privilégio, controle de capacidades |
| Isolamento de processo | Processo único compartilhado, sem isolamento | Contexto web isolado por entrada de catálogo |
| Roubo de origem cruzada | Exposição tipo Meltdown/Spectre | A camada nativa verifica cada chamada |
| Indicadores de segurança | Nenhum; a barra pode não coincidir | Controlado pelo host, confiança verificável |
| Limite de mesma origem | Confiável por padrão (CVE-2026-103922) | Explícito, forçado por origem |
O fio desta série sempre volta a uma palavra: controle. Um WebView confia na web que carrega e entrega a ela os privilégios do app; o limite falha em silêncio e, como mostrou 2026, de forma catastrófica. Um runtime converte o limite em um muro que você constrói —por origem, por capacidade, por página—. Para um catálogo de páginas de terceiros que negociam dentro do seu app, esse muro é a diferença entre uma plataforma e um passivo.
Fontes
- Android Developers — Pontes nativas inseguras no WebView: addJavascriptInterface injeta em cada frame sem verificar origem; pré-API 17 é RCE, conteúdo refletido é XSS com permissões do host — orientação oficial sobre a ponte como superfície de escalonamento de privilégios.
- web.dev — Web no Android: WebView não tem arquitetura multiprocesso nem isolamento de site; processo único compartilhado; acesso completo a cookies/DOM; sem indicadores de segurança — a razão estrutural pela qual o WebView não é um navegador reforçado.
- CVE-2026-103922 (Capacitor), CVSS 9.6 — a guarda de navegação omitiu a rota; o proxy interno na origem do app permitiu execução de conteúdo remoto com confiança de mesma origem (CWE-346, CWE-441) — uma falha de app híbrido em 2026 por limite ausente.
- Android Developers — Acesso a API nativa via ponte JS: addWebMessageListener (lista branca) mais seguro que addJavascriptInterface (sem origem) — por que a ponte padrão é a opção mais fraca.
- OWASP MASTG — Interação de plataforma e riscos de ponte WebView (MASVS-PLATFORM) — pontes e área de transferência mapeadas a requisitos de segurança móvel.
