1. Autenticação não é segurança

Grande parte das aplicações modernas ainda estrutura sua segurança a partir de um modelo centrado em identidade (NIST SP 800-207):

• autenticar o usuário
• estabelecer uma sessão
• aceitar as requisições subsequentes como legítimas

Esse modelo resolve o problema de identidade e atende bem a cenários onde o ambiente é controlado.

No entanto, ele se apoia em uma suposição que raramente é tratada explicitamente:

o cliente é confiável (OWASP MASVS).

Essa suposição não é validada. Ela apenas sustenta todo o fluxo após a autenticação.

1.1. O modelo implícito de confiança

Em uma arquitetura tradicional, após o login, o backend passa a aceitar requisições que contenham um token válido (como um JWT) (RFC 7519 – JSON Web Token) ou uma sessão ativa.

Esse comportamento é esperado. O token funciona como uma prova de autenticação e, a partir dele, o sistema associa a requisição a uma identidade previamente validada.

Esse modelo introduz uma consequência direta. Ao aceitar a requisição com base apenas nesse artefato, o backend passa a depender de suposições não verificadas.

Na prática, isso implica assumir que:

• o dispositivo que originou a requisição é legítimo
• a aplicação está íntegra e executando o código original
• o ambiente de execução não foi comprometido
• a comunicação entre cliente e backend não foi manipulada
• o fluxo da requisição segue o comportamento esperado da aplicação

Essas suposições não fazem parte do contrato da API. Elas não são validadas, nem observadas diretamente. Ainda assim, sustentam todo o funcionamento do sistema após a autenticação.

Esse modelo cria uma separação clara:

• a identidade é verificada explicitamente
• o contexto é assumido implicitamente (NIST SP 800-207)

Enquanto a identidade está ancorada em mecanismos formais (credenciais, assinatura de tokens, validação criptográfica), o contexto depende de confiança indireta no cliente. Essa confiança não possui garantias.

Do ponto de vista do backend, todas as requisições que apresentam um token válido são tratadas de forma equivalente, independentemente de:

• qual dispositivo está sendo utilizado
• em que ambiente a aplicação está executando
• como aquela requisição foi gerada
• se houve interferência no caminho até o servidor

Essa ausência de distinção é central para entender a limitação do modelo.

O sistema não diferencia entre uma requisição legítima, originada de um fluxo normal da aplicação, e uma requisição construída, modificada ou reproduzida fora desse fluxo.

Essa indistinguibilidade não é um detalhe de implementação. Ela é uma consequência direta do modelo de confiança adotado.

1.2. O limite do JWT

Tokens como JWT são amplamente utilizados (RFC 7519 – JSON Web Token), e por bons motivos. Eles permitem autenticação stateless, eliminam a necessidade de armazenamento de sessão no backend e simplificam a comunicação entre serviços distribuídos.

Do ponto de vista de engenharia, são uma solução eficiente para o problema de identidade.

No entanto, existe uma limitação estrutural que raramente é tratada de forma explícita.

JWT valida identidade. Não valida contexto.

Um token válido comprova apenas que, em algum momento, uma identidade foi autenticada com sucesso e recebeu um artefato assinado pelo backend.

A partir desse ponto, qualquer requisição que apresente esse token tende a ser aceita como legítima. Essa legitimidade, no entanto, está restrita à identidade, não ao ambiente em que a requisição é executada.

O JWT não estabelece garantias sobre o contexto de uso. Mesmo quando inclui informações adicionais, esses dados não são intrinsecamente confiáveis sem um mecanismo externo de verificação.

Isso significa que o backend não consegue responder, com base apenas no token, a questões fundamentais como:

• onde a requisição está sendo executada
• em que tipo de dispositivo
• em quais condições a aplicação está rodando
• se o ambiente foi comprometido
• se o comportamento da requisição é consistente com o fluxo esperado

Do ponto de vista de segurança, o JWT é um artefato de autenticação, não um mecanismo de validação de integridade do cliente.

Na prática, ele funciona como um comprovante de autenticação passada, não como uma garantia de segurança no momento da requisição.

Isso introduz uma superfície de risco relevante. Uma vez emitido, o token pode ser reutilizado em contextos distintos daquele em que foi originalmente gerado:

• em outro dispositivo
• em um ambiente instrumentado ou modificado
• por meio de scripts automatizados
• através de interceptação e replay de requisições

Enquanto o token permanecer válido e não for revogado, o backend tende a aceitar essas requisições de forma indistinta.

Esse é o ponto crítico do modelo:

o sistema continua confiando em uma decisão passada, sem qualquer reavaliação do contexto atual (NIST SP 800-207).

Esse comportamento é coerente com o modelo de autenticação tradicional, mas expõe uma limitação clara quando aplicado a ambientes não confiáveis.

Em aplicações mobile, onde o cliente está fora do domínio de controle do backend, essa abordagem deixa de ser suficiente como mecanismo primário de segurança.

1.3. Quando o modelo falha

Na prática, o cliente é um ambiente completamente fora do domínio de controle do backend e, por definição, não pode ser considerado confiável (OWASP MASVS).

Diferente de um servidor, onde há controle sobre infraestrutura, runtime e políticas de segurança, o cliente opera em um ambiente aberto, onde o usuário tem controle direto sobre o dispositivo, o sistema operacional e o próprio binário da aplicação.

Isso altera de forma fundamental a fronteira de confiança do sistema.

Após a autenticação, o backend passa a aceitar requisições originadas de um ambiente que ele não controla, não observa diretamente e não consegue validar de forma contínua.

Nesse contexto, o cliente deixa de ser uma extensão confiável do sistema e passa a ser apenas uma origem de entrada de dados.

Esse ponto é frequentemente negligenciado. O modelo tradicional trata o cliente como parte do fluxo legítimo da aplicação, quando, na prática, ele deve ser tratado como um ambiente potencialmente adversarial.

Isso implica que qualquer elemento proveniente do cliente pode ser:

• modificado antes de ser enviado
• interceptado e reproduzido fora do fluxo original
• gerado por ferramentas externas, sem passar pela aplicação oficial
• executado em ambientes instrumentados ou comprometidos

Essas possibilidades não são exceções. Elas fazem parte do comportamento esperado de um sistema exposto.

Quando o modelo de segurança depende de suposições sobre o comportamento do cliente, ele passa a operar fora do seu limite de validade.

É nesse ponto que as garantias fornecidas pela autenticação deixam de ser suficientes.

A partir daqui, os cenários deixam de ser teóricos e passam a ser operacionais.

1.3.1. Emuladores e dispositivos não confiáveis

A aplicação pode ser executada em emuladores ou ambientes virtualizados que não oferecem garantias de integridade equivalentes às de um dispositivo físico (OWASP MASVS).

Do ponto de vista funcional, o app continua operando normalmente. Do ponto de vista de segurança, no entanto, o cenário é fundamentalmente diferente.

Ambientes emulados ampliam significativamente a capacidade de observação e controle sobre a execução da aplicação. Neles, é possível:

• inspecionar o comportamento da aplicação em tempo de execução
• controlar o sistema operacional e suas respostas
• simular condições específicas, como localização, rede e hardware
• executar fluxos automatizados em larga escala

Além disso, dispositivos comprometidos, como aparelhos com root ou jailbreak, estendem esse nível de controle ao próprio ambiente físico. Nesses casos, o atacante passa a ter acesso privilegiado ao sistema, permitindo:

• leitura e modificação do sistema de arquivos da aplicação
• alteração de comportamento em tempo de execução
• injeção de código e interceptação de funções críticas

Nesse contexto, deixam de existir garantias básicas sobre o cliente. O backend não consegue afirmar que:

• a aplicação está executando o código original
• o ambiente de execução é íntegro
• as respostas do sistema operacional são confiáveis
• os dados produzidos pelo cliente não foram manipulados

Ainda assim, do ponto de vista do backend, essas requisições permanecem indistinguíveis de um uso legítimo, desde que acompanhadas de um token válido.

Esse é o problema central:

o ambiente pode ser totalmente controlado, e o sistema não possui qualquer visibilidade sobre isso.

1.3.2. Aplicação em modo debug ou modificada

Mesmo em dispositivos legítimos, a aplicação pode estar sendo executada em condições que comprometem sua integridade.

Ambientes de debug, builds não oficiais ou versões modificadas do app ampliam significativamente a superfície de ataque, permitindo níveis de observação e controle inexistentes em um cenário padrão de produção.

Ferramentas de instrumentação dinâmica, como frameworks de hooking, permitem:

• interceptar chamadas de função em tempo de execução
• alterar parâmetros antes do envio ao backend
• modificar respostas recebidas
• contornar validações internas da aplicação

Além disso, builds em modo debug frequentemente expõem informações sensíveis e facilitam:

• inspeção de logs e dados internos
• análise detalhada do fluxo de execução
• bypass de verificações implementadas no cliente

Em cenários mais avançados, versões modificadas da aplicação podem ser distribuídas com comportamento alterado, mantendo a mesma interface, mas executando uma lógica diferente da originalmente planejada.

Isso inclui, por exemplo:

• remoção de validações
• alteração de regras de negócio no cliente
• automatização de fluxos de requisição

Nesse contexto, a integridade do código executado deixa de ser garantida.

Do ponto de vista do backend, no entanto, essas diferenças permanecem invisíveis.

Se a requisição estiver bem formada e acompanhada de um token válido, ela tende a ser aceita, independentemente de como foi gerada.

Esse é o ponto crítico:

não há garantia de que o código executado no cliente corresponde ao código originalmente distribuído.

1.3.3. Interceptação e manipulação de requisições

Mesmo quando a aplicação está íntegra e executando em um dispositivo legítimo, o tráfego entre cliente e backend pode ser observado e manipulado.

Ferramentas de proxy HTTP/HTTPS permitem a inserção de um intermediário entre a aplicação e o servidor, possibilitando:

• captura completa de requisições e respostas
• inspeção de headers, payloads e parâmetros
• modificação de dados antes do envio
• reprodução de chamadas fora do fluxo original da aplicação

Na prática, qualquer requisição realizada pelo app pode ser analisada e posteriormente reconstruída, de forma manual ou automatizada.

Isso permite, por exemplo:

• alterar valores de campos antes do envio
• repetir operações múltiplas vezes (replay)
• executar chamadas fora da ordem esperada
• simular o comportamento da aplicação sem utilizá-la diretamente

Mesmo em cenários com HTTPS, essa interceptação permanece possível em ambientes controlados, onde certificados confiáveis são instalados manualmente, permitindo a inspeção do tráfego.

Do ponto de vista do backend, essas requisições continuam válidas:

• possuem estrutura correta
• seguem o contrato da API
• carregam um token legítimo

E, por isso, são aceitas.

Esse é o ponto crítico:

o backend valida a forma da requisição e a identidade associada, mas não possui garantias sobre a origem e o processo de geração dessa requisição.

Sem mecanismos adicionais de validação de contexto, o sistema não distingue:

• uma ação legítima realizada pelo usuário
• de uma requisição reproduzida, modificada ou automatizada

Essa indistinguibilidade não é um detalhe de implementação. Ela é uma limitação direta do modelo baseado exclusivamente em autenticação.

1.3.4. Reexecução de chamadas autenticadas

Mesmo quando uma requisição é originalmente legítima, não há garantias de que ela será utilizada apenas no contexto em que foi gerada.

Uma vez capturada, seja por interceptação de tráfego, logs ou instrumentação do cliente, essa requisição pode ser reproduzida posteriormente, fora do fluxo original da aplicação.

Esse tipo de cenário é conhecido como replay attack (OWASP Transaction Authorization Cheat Sheet).

Na prática, isso permite:

• repetir operações sensíveis sem nova interação do usuário
• executar ações fora do momento em que foram autorizadas
• automatizar chamadas previamente válidas
• reutilizar requisições em contextos distintos, como outro dispositivo, sessão ou ambiente

O ponto crítico é que a requisição preserva todas as características técnicas de uma chamada legítima:

• estrutura válida
• parâmetros corretos
• token de autenticação válido

No entanto, ela perde dois elementos fundamentais:

• o contexto em que foi gerada
• o vínculo temporal e intencional com a ação do usuário

Do ponto de vista do backend, essa diferença não é observável.

Sem mecanismos adicionais, o sistema não distingue:

• uma ação recém autorizada pelo usuário
• de uma requisição reutilizada fora do seu contexto original

Como consequência, ambas tendem a ser aceitas.

validade técnica não implica legitimidade contextual.

Esse é um dos limites mais críticos do modelo baseado exclusivamente em autenticação.

1.4. O problema central

O problema não é a autenticação. O problema é o que acontece depois dela.

Modelos tradicionais tratam a autenticação como um evento suficiente para estabelecer confiança. Uma vez que a identidade é validada, o sistema passa a considerar as ações subsequentes como legítimas.

Essa transição, no entanto, não é acompanhada por uma validação equivalente do contexto.

Após autenticar o usuário, o backend continua sem visibilidade sobre:

• o ambiente em que a aplicação está sendo executada
• a integridade do código no cliente
• o dispositivo que originou a requisição
• as condições sob as quais a ação foi realizada

Ainda assim, essas requisições são aceitas.

Esse comportamento revela uma suposição implícita:

identidade validada implica em contexto confiável (NIST SP 800-207).

Essa é a falha estrutural do modelo.

A autenticação responde quem está interagindo com o sistema, mas não responde:

• onde essa interação ocorre
• como ela está sendo executada
• em que condições ela foi gerada

Sem essas respostas, o sistema toma decisões com base em uma visão parcial do estado real da requisição.

Essa lacuna não é teórica. Ela é operacional.

Todos os cenários apresentados anteriormente, como execução em ambientes controlados, modificação da aplicação, interceptação de tráfego e reexecução de requisições, existem porque o sistema continua confiando no cliente após a autenticação.

Não por validação, mas por ausência de verificação.

autenticar o usuário não significa confiar no ambiente onde ele está.

Enquanto a confiança for derivada exclusivamente da identidade, qualquer comprometimento do ambiente se propaga diretamente para o sistema.

Nesse modelo, o backend não possui meios para distinguir uma ação legítima de uma ação manipulada. Esse é o limite da abordagem tradicional.

É a partir desse ponto que se torna necessário repensar o próprio conceito de confiança dentro da aplicação.

1.4.1. Uma mudança necessária

Sistemas que operam em ambientes não confiáveis, como aplicações mobile, precisam ir além da identidade como único critério de segurança. A autenticação continua sendo necessária, mas deixa de ser suficiente.

Isso exige uma mudança de abordagem: a segurança não pode depender exclusivamente de um evento pontual, como o login, mas deve considerar continuamente o contexto em que cada ação ocorre (NIST SP 800-207).

Na prática, isso implica incorporar novas dimensões na avaliação de cada requisição, incluindo:

• o dispositivo que originou a chamada
• o estado da aplicação em execução
• o ambiente, como debug, emulação e integridade
• o contexto específico daquela operação

Esses elementos não substituem a identidade, mas a complementam e permitem transformar uma decisão binária, autenticado ou não, em uma análise contextual.

Sem essa camada adicional, a segurança permanece ancorada em um único momento no tempo, o instante da autenticação, e todo o restante do fluxo passa a depender de uma confiança que não é reavaliada.

Isso cria um efeito cumulativo de risco: quanto mais tempo uma sessão permanece válida, maior é a superfície de exposição associada a ela.

Uma requisição feita minutos ou horas após o login é tratada da mesma forma que uma ação imediatamente após a autenticação, mesmo que o contexto tenha mudado completamente.

Esse modelo não considera mudanças no ambiente, alterações de comportamento ou transições de risco ao longo da sessão e, por isso, não reage a elas.

A mudança necessária não é apenas tecnológica, mas conceitual. A confiança deixa de ser implícita e passa a ser contextual, dinâmica e continuamente reavaliada.

É essa mudança que abre espaço para um novo modelo de segurança.

1.4.2. O próximo passo

Diante dessas limitações, torna-se necessário adotar uma abordagem diferente.

O modelo baseado exclusivamente em autenticação não é suficiente para lidar com ambientes não confiáveis, especialmente em aplicações mobile, onde o cliente está fora do domínio de controle do backend.

Isso leva à adoção de um princípio mais rigoroso:

não confiar implicitamente em nenhum elemento do sistema.

No contexto mobile, isso implica tratar o próprio cliente não como uma extensão confiável da aplicação, mas como uma fonte de sinais que precisam ser avaliados continuamente.

A segurança deixa de ser baseada apenas na identidade e passa a considerar evidências adicionais a cada interação, incorporando o contexto como parte da decisão.

Esse modelo é conhecido como Zero Trust (NIST SP 800-207).

No próximo artigo, será detalhado como esse conceito pode ser aplicado no contexto de aplicações mobile, especialmente na forma como o cliente participa da construção dessas evidências.