O Endpoint da Webview: Lendo uma API Interna a Partir do HTML da Webview

Segurança Mobile Nível 2/4 ~3 min 17 de agosto de 2026

O desafio

Esta tela dentro de um app móvel é na verdade uma página web carregada numa webview. O app chama uma API interna a partir dela, mas nunca mostra esse endereço na tela. Abra o código-fonte, encontre o link escondido para o endpoint interno e o envie.

O que você vai aprender

  • Entender que muitas telas de apps mobile são páginas web dentro de uma webview
  • Ler o código-fonte HTML de uma tela renderizada por uma webview
  • Encontrar um link escondido que aponta para um host de back-end interno
  • Extrair a URL completa de um endpoint de API interna a partir do código-fonte
  • Explicar por que endpoints internos não deveriam ser entregues em markup renderizado no cliente

Habilidades testadas

Reconhecimento de webview e mobileInspeção de código-fonte (view-source)Descoberta de endpoints internos

Pré-requisitos

  • Noção básica do que é uma webview em um app mobile
  • Familiaridade com URLs e hostnames

Como funciona

Uma quantidade surpreendente das telas de um app mobile não é nativa de jeito nenhum - são páginas web carregadas dentro de uma webview, um componente de navegador embutido no app. Para o usuário, parece parte do app, mas por baixo dos panos é HTML, CSS e JavaScript, e esse HTML pode ser inspecionado exatamente como o de qualquer site.

Para fazer essas telas funcionarem, desenvolvedores costumam embutir referências ao back-end com o qual a tela se comunica. Neste desafio, a tela de carteira faz prefetch de configuração a partir de um host interno ao carregar, e o endereço é armazenado como um link configurado para ficar invisível: https://api.acme.example/v1/internal/config. Um comentário no código-fonte até observa "webview prefetches config from the internal host on load; do not surface to user." O usuário nunca o vê na tela, mas ele está no texto da página.

Isso importa porque endpoints internos, especialmente os com nomes como /internal/config, são um alvo forte para um atacante mapeando o back-end de um app. Descobri-los mostra onde a lógica real está. Como uma webview é apenas um navegador, tudo que está embutido em seu markup fica tão exposto quanto ficaria em um site público - o wrapper nativo não oferece nenhum sigilo.

Erros comuns

  • Assumir que as telas do app são opacas. Tratar uma tela mobile como uma caixa-preta nativa quando na verdade é HTML inspecionável.
  • Ler apenas os links visíveis. Notar os links de adicionar saldo e histórico, mas deixar passar o link interno invisível.
  • Enviar uma URL parcial. Descartar o esquema ou o host e digitar apenas /internal/config em vez do endpoint completo pedido.
  • Ignorar o comentário. Pular o comentário do código-fonte que confirma o prefetch interno.

Como se proteger

Trate o HTML da webview como totalmente público e mantenha endereços internos fora dele. A tela deve se comunicar com o back-end por meio de uma camada que não revele hostnames ou rotas internas ao cliente.

  • Não embuta URLs de API interna no HTML da webview ou no JavaScript do cliente; resolva-as no lado do servidor.
  • Coloque endpoints somente internos atrás de autenticação e controles de rede, de modo que um endereço vazado não seja suficiente para alcançá-los.
  • Remova comentários de desenvolvedor e links não utilizados das páginas de webview entregues em produção.
  • Direcione o tráfego do cliente por um gateway público e mantenha os hosts internos inacessíveis a partir do dispositivo.

Solução completa

Membros Pro e Max desbloqueiam o passo a passo completo.

Assinar Pro

Estatísticas da comunidade

153 resoluções
90% taxa de sucesso
Hope Primeiro sangue

Hacks de hoje relacionados

24.000+ Hackers 100+ Labs & Cursos Grátis
Comece Grátis