Web vs. Mobile: Quem Está em Perigo? Uma Comparação de Segurança Entre Dois Mundos

Web vs. Mobile: Quem Está em Perigo? Uma Comparação de Segurança Entre Dois Mundos

Spoiler: ambos, mas de maneiras diferentes – e isso é crucial de entender.

Sempre que ouvimos "nossa segurança está bem, não somos um banco", algo em nós se contrai. Por trás dessa frase, geralmente encontramos tokens de autenticação em SharedPreferences, consultas SQL sem parametrização e Firebase sem regras de acesso. Este artigo é uma tentativa de comparar honestamente os dois mundos, encontrar pontos de intersecção e entender por que alguns problemas são os mesmos, enquanto outros são fundamentalmente diferentes.

Dados de Origem:

• OWASP Top 10 Web 2025
• OWASP Mobile Top 10 2024
• Estatísticas do banco de dados NVD/CVE
• Dados de testes de penetração reais
• IBM Cost of a Data Breach 2024

Escala do Problema: Números que Despertam

De acordo com a OWASP e o NVD, o panorama não tem mudado drasticamente nos últimos anos – apenas os detalhes se alteram. As injeções lideram consistentemente em número de CVEs entre todas as categorias web. Este problema existe desde os anos 90, é descrito em todos os manuais de segurança – e ainda assim, é encontrado diariamente em aplicações de produção.

Falhas de autenticação – credential stuffing, session fixation, falta de MFA em operações críticas. De acordo com a OWASP, vulnerabilidades de autenticação são encontradas em dezenas de milhares de aplicações anualmente. Erros criptográficos – MD5 para senhas, chaves no código, TLS 1.0 em produção. E o mais importante, as soluções corretas existem e são bem documentadas há muitos anos.

Quebras de controle de acesso (web) – de acordo com a OWASP, são detectadas em mais de 90% das aplicações testadas. É por isso que esta categoria ocupa o primeiro lugar no Web Top 10 por três classificações consecutivas. O cenário para aplicações mobile não é mais animador. Pesquisas no âmbito do OWASP Mobile Security Testing Guide mostram que a maioria das aplicações mobile contém pelo menos uma vulnerabilidade do Mobile Top 10. O armazenamento inseguro de dados (tokens em armazenamentos desprotegidos, bancos de dados não criptografados) é uma das descobertas mais frequentes em auditorias. Chaves de API hardcoded são detectadas com análise estática de APKs com uma frequência significativamente maior do que gostaríamos de pensar.

As consequências são reais: vazamentos de dados pessoais, perdas financeiras, multas regulatórias (152-FZ, GDPR). De acordo com o IBM Cost of a Data Breach 2024, o custo médio de um vazamento de dados foi de US$ 4,88 milhões, e o tempo médio para detecção e contenção de uma violação foi de cerca de 194 dias. E isso sem contar o dano à reputação.

OWASP Top 10: Comparação Detalhada

Antes de entrarmos em detalhes, vamos olhar para as duas listas lado a lado e encontrar imediatamente o que têm em comum.

OWASP Top 10: Comparação

Apesar das diferentes plataformas, aplicações web e mobile sofrem do mesmo conjunto de vulnerabilidades fundamentais: controle de acesso fraco e erros de autenticação permitem que atacantes ajam em nome de terceiros ou obtenham dados sem permissão; criptografia inadequada – seja por algoritmos fracos ou armazenamento local não criptografado – torna dados sensíveis legíveis; configuração insegura abre pontos de entrada desnecessários em ambas as plataformas; problemas na cadeia de suprimentos significam que software de terceiros se torna um vetor de ataque muito antes de chegar à produção; finalmente, a validação de entrada insuficiente e as injeções permanecem um problema crônico onde quer que os dados do usuário cheguem a um interpretador sem saneamento – seja um navegador ou uma aplicação mobile.

No web, as ameaças únicas se concentram em torno da lógica do servidor e da observabilidade: design não confiável significa que falhas arquitetônicas são incorporadas desde o estágio de projeto dos processos de negócios e não podem ser corrigidas sem reescrita; falhas na integridade de software e dados afetam os pipelines de CI/CD e os mecanismos de atualização automática; e a falta de logging e monitoramento adequados torna o ataque invisível – um atacante pode permanecer dentro do perímetro por meses enquanto ninguém olha os logs. O tratamento incorreto de exceções completa o quadro: stack traces e mensagens de erro internas vazam para o navegador, dando ao atacante um mapa da infraestrutura interna.

No mobile, as ameaças se deslocam para o próprio dispositivo e o ecossistema da aplicação: interação insegura através de canais IPC desprotegidos, deep links e intents entre processos abrem ataques que simplesmente não existem na web; proteção insuficiente do código binário permite engenharia reversa da aplicação, extração de chaves hardcoded e reempacotamento do APK com conteúdo malicioso; controle de privacidade insuficiente reflete a especificidade das permissões mobile – geolocalização, câmera, contatos vazam através de SDKs de terceiros sem que o usuário perceba. Todos estes são problemas que um desenvolvedor web nem sequer considera como um vetor de ameaça.

Arquitetura Define Ameaças

Por que as listas diferem torna-se mais claro quando olhamos para a arquitetura.

Conclusão chave do diagrama: na web, um atacante ataca o servidor, usando o navegador como ferramenta. No mobile, um atacante pode atacar a própria aplicação – baixar, descompilar, modificar, executar em um dispositivo com root e interceptar tráfego. Ao mesmo tempo, o backend é comum – tanto clientes mobile quanto web interagem com a mesma API. Uma vulnerabilidade no servidor é perigosa para ambos.

Vulnerabilidades Comuns: Onde os Riscos São Iguais

1. Autenticação e Autorização Este é o maior conjunto de problemas, igualmente relevante para ambas as plataformas. Erros típicos:

   • IDOR – modificação de dados de terceiros (API mobile): [Link para o código aqui]
   • Gerenciamento seguro de sessão (PHP): [Link para o código aqui]

2. Injeções Encontradas onde quer que haja entrada do usuário e um interpretador.

   • SQL Injection (Python): [Link para o código aqui]
   • XSS (JavaScript/PHP): [Link para o código aqui]
   • Injeção em WebView (Android/Kotlin) – intersecção web e mobile: [Link para o código aqui]

3. Dependências Inseguras (Supply Chain) Ataques de supply chain ganharam uma categoria separada em ambos os tops – e isso não é por acaso: um pacote comprometido dá ao atacante acesso a milhares de organizações simultaneamente.

   Como verificar dependências (SCA - Software Composition Analysis) Dependências inseguras são fáceis de detectar com a abordagem SCA – basta escanear a árvore de pacotes. Em JS/Node.js, execute npm audit; em Python, pip-audit; e em PHP, use o comando embutido composer audit ou a utilidade externa local-php-security-checker. Adicione o Dependabot ao repositório para atualizações automáticas e configure o CI/CD para falhar na compilação em caso de vulnerabilidades High/Critical – isso reduz significativamente os riscos e traz tranquilidade. Experimente em seu próprio projeto, aguardamos o resultado.

Especificidades de Aplicações Mobile

Armazenamento Local: Hierarquia de Segurança A maioria dos erros no desenvolvimento mobile é armazenar dados sensíveis onde qualquer pessoa com um telefone com root pode acessar.

• Armazenamento correto de token no Android (Kotlin) usando EncryptedSharedPreferences: [Link para o código aqui]
• iOS – Keychain (Swift): [Link para o código aqui]

Certificate Pinning: Proteção de Tráfego de Rede Sem pinning, qualquer pessoa com acesso à rede (ou ao próprio dispositivo) pode interceptar tráfego via proxy.

• Android Network Security Config (sem código): [Link para o código aqui]

Proteção do Código Binário: Problema Único do Mobile Na web, os códigos-fonte estão no servidor e inacessíveis. No mobile, o APK pode ser baixado da loja, descompilado via jadx e o código lido quase como um código-fonte Java.

Especificidades de Aplicações Web

Configuração Insegura: Pecados de Infraestrutura Com o aumento da complexidade da infraestrutura (Kubernetes, nuvem, microsserviços), a configuração incorreta se tornou a #2 no OWASP Web 2025. Exemplos da vida real:

• Conjunto mínimo de cabeçalhos de segurança (Express.js): [Link para o código aqui]

Design Não Confiável: O Que Não Pode Ser Corrigido com Refatoração Esta categoria apareceu no OWASP 2021 e permanece – porque o problema é real. Algumas vulnerabilidades surgem não de código ruim, mas de más decisões arquitetônicas. Exemplo: se o sistema aceita o preço de um produto do cliente, nenhuma validação de entrada ajudará – o design precisa ser alterado. Se o mecanismo de recuperação de senha é baseado em "perguntas secretas" – é uma falha de design.

Plataformas: O Que Oferecem e o Que Não Oferecem

Conclusões

• O problema não é a plataforma, mas a abordagem. A maioria das vulnerabilidades não são exóticas. Chaves hardcoded, falta de validação, hashing fraco – elas existem não porque os desenvolvedores não sabem como fazer corretamente, mas porque "funciona, vamos corrigir depois".
• O backend é um ponto comum de responsabilidade. Uma aplicação mobile e um site podem interagir com a mesma API. Se a API for vulnerável a IDOR, ambos os clientes são vulneráveis. A segurança do lado do servidor é mais importante do que a proteção de um cliente específico.
• Mobile é mais complexo em termos de segurança do lado do cliente. Um desenvolvedor web não precisa pensar em descompilar seu código ou roubar dados com acesso físico ao dispositivo. Um desenvolvedor mobile tem essa responsabilidade – precisa escolher os armazenamentos corretos, criptografar dados, proteger o binário.
• Supply chain é a nova realidade. Tanto na web (npm) quanto no mobile (CocoaPods, Maven), dependências são código externo em que confiamos. Escaneamento automático (SCA) e SBOM não são uma opção, mas uma necessidade.
• Logging e monitoramento – o que todos esquecem. A OWASP destaca isso em uma categoria separada não por acaso. O tempo médio de detecção de uma violação é superior a 200 dias. Uma aplicação sem monitoramento adequado é uma aplicação com a porta da frente aberta.

Checklist Prático

Para Backend (Comum)

• Consultas parametrizadas ou ORM onde houver entrada do usuário.
• Autorização verificada no servidor, não no cliente.
• ID do usuário obtido do token, não do corpo da requisição.
• Rate limiting em endpoints críticos (login, recuperação de senha).
• Logging de eventos de segurança com alertas.
• Auditoria regular de dependências (npm audit, pip-audit, dependabot).

Para Frontend Web

• CSP sem 'unsafe-inline' para scripts.
• SameSite=Strict para cookies de autorização.
• Flags HttpOnly + Secure.
• Tokens CSRF em formulários de alteração de estado.
• HSTS com includeSubDomains.
• Nenhum innerHTML com dados do usuário.

Para Mobile

• Tokens – apenas em Keystore/Keychain, não em SharedPreferences/UserDefaults.
• Certificate pinning com backup-pin e prazo de atualização no calendário.
• R8/ProGuard em builds de release.
• FLAG_SECURE em telas com dados sensíveis (proteção contra screenshots).
• Nenhum segredo no código – nem mesmo ofuscado.
• Verificação de root/jailbreak – como camada adicional, não principal.

O Que Ler e Estudar Mais

• OWASP Web Security Testing Guide (WSTG) – guia abrangente para testes web, gratuito.
• OWASP Mobile Application Security (MAS) – MASVS (padrão) + MASTG (guia de testes) + MAS Checklist.
• OWASP MobSF – análise estática e dinâmica automática de aplicações mobile.
• CWE/SANS Top 25 – lista das classes de vulnerabilidades mais perigosas, independentemente da plataforma.
• iOS Security Guide da Apple – documentação oficial sobre mecanismos de segurança do iOS.
• Android Security Guidelines do Google – recomendações oficiais para desenvolvedores Android.
• PortSwigger Web Security Academy – laboratórios práticos gratuitos sobre vulnerabilidades web.

Autores do artigo:

• Ilya Novikov, CTO @inova99
• Danil Manuilov, Maxim Bykov, Linar Ogay, Maxim Savchenko, Team Leads
• Timofey Ischenko, Frontend Development Lead (direção web) @Is_Tim
• Daniil Nikolaev, Frontend Developer (direção web)

Se o artigo ressoou com você – compartilhe nos comentários quais descobertas não óbvias você teve em testes de penetração e auditorias. O mais interessante em segurança são justamente os casos não padronizados, que não estão no OWASP.