Existe um risco que não aparece em nenhum roteiro. Um app de consumo embebe um H5 de terceiros para entregar um serviço — pagamentos, empréstimos, seguros. A página funciona. Mas o código que roda dentro do seu app é uma caixa-preta que você não escreveu, não consegue ler e não pode impedir que mude. Se essa caixa vaza o número do cartão de um usuário, ou serve um formulário de phishing, ou é alterado em trânsito, o regulador e o usuário batem à sua porta. Não à do provedor.
Estive em revisões pós-incidente suficientes para saber como isso se desenrola. O host carrega a marca, a licença e a responsabilidade legal. A página embebida não carrega com nada, e nunca foi desenhada para isso.
Por que o H5 é opaco por construção
Uma página H5 dentro de um webview executa código da origem do provedor. Você não controla seu conteúdo, suas dependências, nem sua cadência de atualização. O provedor pode empurrar um novo build às 2 da manhã e seu app o está servindo uma hora depois. Não há assinatura que você verifique, não há porta de revisão do seu lado, não há inventário de quais scripts ele puxa.
Essa opacidade é exatamente o que os frameworks de segurança apontam. O Mobile Top 10 da OWASP marca qualidade de código fraca e alteração de código como riscos móveis de primeira ordem; o cross-site scripting, o ataque web clássico, vive nativamente dentro de uma superfície H5 porque, afinal, é uma página web. Um webview não isola a página de si mesma — roda qualquer coisa que a origem sirva.
A exposição de conformidade é concreta, não teórica. Fluxos de pagamento que tocam dados de cartão caem sob o PCI DSS, que espera que você saiba para onde vai o dado do titular e o restrinja. Apps financeiros na maioria das jurisdições respondem a um regulador que quer evidência de controle sobre cada componente que maneja dados do cliente — o DORA da UE (Lei de Resiliência Operacional Digital, 2022/2554) torna a resiliência operacional e o risco de terceiros uma obrigação de nível de conselho. Quando o componente de risco é um H5 de terceiros que você não pode auditar, você responde essas perguntas com «confiamos neles».
Frente a frente
| Dimensão | H5 de terceiros embebido | Runtime de mini-programa (do host) |
|---|---|---|
| Visibilidade de código | Origem de terceiros inaudável | Pacote assinado e revisado |
| Controle de atualização | O provedor empurra à vontade | O host revisa cada release |
| Superfície de ataque | XSS, alteração, phishing | Sandbox, capacidade acotada |
| Dados de pagamento | Difícil de restringir | Limites impostos pelo host |
| Postura regulatória | «Confiamos no provedor» | Primeira parte, controle com evidência |
| Resposta a incidentes | Culpar, lento | O host retira na hora |
A diferença é a latência de controle. Com H5, sua resposta mais rápida a um build ruim é uma ligação frenética ao provedor. Com um runtime, o host assina, revisa e pode tirar um pacote não conforme do catálogo em minutos. Essa brecha é a diferença entre um incidente que você gerencia e um que gerencia você.
Um runtime não torna a segurança grátis. O host ainda responde pelo motor, pela linha de revisão e pelo endurecimento do runtime. Mas converte uma superfície de terceiros opaca em uma superfície que você realmente governa: pacotes assinados, APIs graduadas, listas brancas de capacidades e uma baixa que você controla. A caixa-preta vira caixa de vidro.
A linha honesta: se seu app toca dinheiro, saúde ou identidade, «embebemos uma página web» não é uma arquitetura defensável. Um runtime controlável é o que converte essa exposição de um passivo que você herdou em um controle que você possui.
