Segurança de dados locais no Android costuma aparecer tarde demais no projeto. O app começa guardando um token, depois adiciona cache de perfil, preferências, fila offline, histórico de pedidos, dados financeiros ou informações de saúde. Quando o produto cresce, a pergunta muda: o que acontece se esse dispositivo for perdido, roubado, rooteado, restaurado de backup ou analisado por alguém com acesso físico? Em apps Android feitos com Kotlin, proteger armazenamento local precisa fazer parte da arquitetura, não apenas de uma checklist antes de publicar na Play Store.

O ponto principal é simples: armazenamento local melhora experiência e performance, mas também aumenta responsabilidade. Um app offline-first com Kotlin pode depender de Room, DataStore, WorkManager e cache HTTP para funcionar em rede ruim. Isso é ótimo para produto. Porém, nem todo dado merece ficar salvo em texto claro. Tokens de autenticação, dados pessoais, documentos, mensagens, coordenadas, informações financeiras e registros corporativos precisam de uma estratégia explícita.

Este guia mostra como pensar segurança local em 2026 usando Kotlin, Android Jetpack, Room, SQLCipher, EncryptedSharedPreferences, Keystore, backups, logs e sincronização. A ideia não é vender “criptografe tudo” como solução mágica. A ideia é separar riscos, escolher ferramentas adequadas e evitar erros que aparecem em entrevistas, auditorias e incidentes reais.

O que conta como dado local sensível?

Antes de escolher biblioteca, classifique os dados. Em muitos projetos, “sensível” vira sinônimo de senha, mas o problema é mais amplo. Em um app Android, dados locais podem incluir:

  • access token, refresh token e chaves de sessão;
  • email, CPF, telefone, endereço e identificadores internos;
  • dados de pagamento, assinatura, pedidos ou saldo;
  • mensagens, anexos e fotos capturadas pelo usuário;
  • localização, rotas, visitas e histórico de uso;
  • cache de APIs com informações de terceiros;
  • filas offline com operações ainda não sincronizadas;
  • flags de feature, permissões e contexto de autorização.

Nem todos têm o mesmo risco. Um tema escuro salvo localmente não exige criptografia. Um refresh token sim. Um catálogo público pode ficar em Room sem proteção especial. Uma fila offline com dados de cliente talvez precise ser criptografada, expirar e sair do dispositivo no logout.

Essa classificação deve acontecer perto da modelagem. Se o time só pergunta “onde vamos guardar?” depois de já ter entidades, repositories e workers prontos, a segurança vira remendo.

Camadas de armazenamento no Android

Apps Kotlin costumam misturar várias camadas locais:

  • Room para dados relacionais, listas, entidades e cache reativo;
  • DataStore Preferences para preferências simples e tipadas;
  • SharedPreferences legadas ou integrações antigas;
  • arquivos internos para anexos, imagens ou documentos;
  • cache HTTP via OkHttp;
  • banco próprio com SQLDelight em projetos multiplataforma;
  • Keystore para proteger chaves criptográficas.

Cada camada pede uma decisão diferente. Room é excelente para consulta e reatividade, mas o SQLite padrão não criptografa o arquivo. DataStore melhora ergonomia sobre preferências, mas não deve virar cofre de secrets por padrão. Keystore protege chaves, não substitui banco local. Cache HTTP pode salvar respostas completas sem você perceber se a configuração for permissiva demais.

Para um app sério, documente a regra por categoria: “tokens ficam no armazenamento criptografado”, “dados públicos podem ficar no Room normal”, “dados pessoais offline expiram em X dias”, “anexos sensíveis não entram no backup”, “logout limpa banco, cache e fila”. Essa clareza evita decisões inconsistentes por tela.

Tokens: onde guardar access token e refresh token?

Tokens merecem cuidado especial porque funcionam como credenciais temporárias. A regra prática é: minimize duração, escopo e exposição.

Para muitos apps Android, EncryptedSharedPreferences ou uma solução equivalente baseada em Android Keystore é um caminho pragmático para tokens. O Keystore protege a chave mestra; as preferências armazenam valores cifrados. Em Kotlin, a inicialização fica parecida com isto:

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val securePrefs = EncryptedSharedPreferences.create(
    context,
    "auth_secure_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM,
)

securePrefs.edit()
    .putString("refresh_token", refreshToken)
    .apply()

O exemplo mostra o conceito, mas a arquitetura não deve espalhar securePrefs pelo app inteiro. Crie uma fronteira clara:

interface TokenStore {
    suspend fun salvar(tokens: AuthTokens)
    suspend fun carregar(): AuthTokens?
    suspend fun limpar()
}

class AndroidTokenStore(
    private val prefs: SharedPreferences,
) : TokenStore {
    override suspend fun salvar(tokens: AuthTokens) {
        prefs.edit()
            .putString("access_token", tokens.accessToken)
            .putString("refresh_token", tokens.refreshToken)
            .apply()
    }

    override suspend fun carregar(): AuthTokens? {
        val access = prefs.getString("access_token", null) ?: return null
        val refresh = prefs.getString("refresh_token", null) ?: return null
        return AuthTokens(access, refresh)
    }

    override suspend fun limpar() {
        prefs.edit().clear().apply()
    }
}

Essa interface facilita teste, troca de implementação e integração com login biométrico quando necessário. Também evita que interceptors, ViewModels e repositories acessem detalhes de criptografia diretamente.

Access token em memória, refresh token persistido

Quando possível, reduza persistência. Uma estratégia comum é manter access token curto em memória e persistir apenas refresh token protegido. Ao abrir o app, você usa o refresh token para obter uma sessão nova. Isso reduz o tempo em que um access token válido fica salvo em disco.

Nem sempre essa abordagem cabe no produto. Alguns apps precisam sobreviver a processo morto sem reautenticar toda hora. Mesmo assim, vale perguntar:

  • o access token precisa mesmo ficar salvo?
  • qual é a expiração real?
  • o refresh token tem rotação?
  • logout invalida token no servidor?
  • troca de senha derruba sessões antigas?
  • o app trata 401 sem loop infinito?

Segurança local não compensa backend frágil. Token armazenado com cuidado ainda é perigoso se nunca expira ou se o servidor aceita refresh token antigo depois de rotação.

Room e SQLite: quando criptografar o banco?

Room usa SQLite. Por padrão, o arquivo do banco fica no sandbox do app, protegido pelo modelo de permissões do Android. Isso já bloqueia acesso casual entre apps. Mas não é criptografia. Em cenários com dados pessoais fortes, dispositivo comprometido, uso corporativo ou requisitos regulatórios, pode fazer sentido usar SQLCipher ou outra camada de banco criptografado.

Com SQLCipher, a ideia é abrir o banco com uma chave. Em projetos Android, essa chave costuma ser derivada ou protegida por Keystore, não escrita fixa no código. Um desenho simplificado:

val passphrase: ByteArray = obterChaveDoKeystore()
val factory = SupportFactory(passphrase)

val db = Room.databaseBuilder(
    context,
    AppDatabase::class.java,
    "app.db",
)
    .openHelperFactory(factory)
    .build()

O detalhe importante é operacional: criptografar banco muda backup, migração, performance, recuperação e suporte. Você precisa testar abertura do banco depois de atualização, rotação de chave, logout, reinstalação e restauração de backup. Também precisa evitar logar a chave, salvar passphrase em arquivo ou usar constante hardcoded.

Criptografar tudo sem critério pode piorar a manutenção. Uma alternativa é separar bancos: um Room normal para dados públicos ou reconstruíveis e um armazenamento criptografado para dados sensíveis. Outra é criptografar campos específicos antes de salvar, quando consultas SQL sobre esses campos não são necessárias.

DataStore é bom para preferências, não para segredos por padrão

DataStore Preferences é ótimo para configurações: tema, idioma, onboarding visto, filtros de tela, preferências de notificação e flags simples. Ele é mais moderno que SharedPreferences, funciona bem com coroutines e Flow, e evita vários problemas de escrita síncrona.

Mas DataStore não deve virar depósito automático de secrets. Se você precisa guardar token ou informação sensível, use uma camada criptografada ou uma solução que combine DataStore com criptografia cuidadosamente revisada. Para aprender a base de uso, veja o tutorial de DataStore Preferences com Kotlin; para segurança, trate secrets como outra categoria.

Uma divisão saudável fica assim:

DataStore:
  - tema
  - filtros
  - onboarding
  - preferências não sensíveis

TokenStore criptografado:
  - access token, se persistido
  - refresh token
  - session id sensível

Room/SQLCipher:
  - entidades offline
  - filas de sincronização
  - cache com dados pessoais quando necessário

Essa separação deixa a arquitetura mais legível para quem chega no time e reduz o risco de alguém salvar um secret no lugar errado por conveniência.

Arquivos, anexos e cache HTTP

Muitos vazamentos locais não estão no banco. Estão em arquivos temporários, anexos, imagens redimensionadas, logs ou cache HTTP. Se o app baixa comprovantes, contratos, imagens privadas ou documentos, defina regras para armazenamento interno, criptografia, expiração e limpeza.

No Android, prefira armazenamento interno privado para arquivos do app. Evite salvar dados sensíveis em diretórios públicos sem necessidade. Se o usuário exporta um arquivo, deixe claro que ele saiu da proteção do sandbox do app.

Para cache HTTP, revise a configuração do OkHttp e os headers do backend. Algumas respostas não deveriam ser armazenadas em disco. Em endpoints com dados pessoais, use Cache-Control adequado no servidor e cuidado com interceptors que gravam bodies em log. O tutorial de Retrofit com Kotlin já discute autenticação, retry e logs; a mesma disciplina vale para armazenamento local de respostas.

Backups automáticos podem reintroduzir risco

O Android pode fazer backup automático de dados do app dependendo da configuração, versão e política. Isso é útil para experiência do usuário, mas perigoso para secrets, bancos criptografados sem estratégia de chave e dados que não deveriam sobreviver a troca de aparelho.

Revise allowBackup, regras de dataExtractionRules e exclusões de backup. Não trate backup como detalhe de manifesto. Pergunte:

  • tokens entram no backup?
  • banco local entra no backup?
  • a chave criptográfica também entra ou fica presa ao hardware antigo?
  • restauração em outro aparelho quebra abertura do banco?
  • logout limpa dados que já foram copiados?

Em alguns produtos, faz sentido excluir bancos e tokens de backup e reconstruir estado a partir do servidor. Em outros, como apps offline corporativos, pode haver uma estratégia própria de exportação e recuperação. O importante é não deixar o comportamento padrão decidir sozinho.

Logout precisa limpar mais do que token

Um logout seguro não remove apenas access_token. Ele deve limpar o conjunto de dados associados à sessão. Dependendo do app, isso inclui:

  • tokens e session ids;
  • banco local do usuário;
  • filas de sincronização pendentes;
  • anexos baixados;
  • cache HTTP;
  • imagens temporárias;
  • chaves locais relacionadas à sessão;
  • jobs agendados no WorkManager.

Em Kotlin, centralize essa limpeza em um caso de uso ou coordenador de sessão:

class LogoutUseCase(
    private val tokenStore: TokenStore,
    private val database: AppDatabase,
    private val cacheCleaner: CacheCleaner,
    private val workManager: WorkManager,
) {
    suspend fun executar() {
        workManager.cancelAllWorkByTag("sync-usuario")
        database.clearAllTables()
        cacheCleaner.limparArquivosDaSessao()
        tokenStore.limpar()
    }
}

A ordem pode variar. Se há operações offline pendentes, talvez o produto precise avisar o usuário antes de descartar. Em apps corporativos, logout remoto ou bloqueio administrativo pode exigir limpeza imediata. Documente a decisão.

Logs, analytics e crash reports

Mesmo com banco criptografado, você pode vazar dado em log. Isso acontece quando o app imprime DTO completo, request body, token, exceção com payload, URL com query sensível ou objeto de domínio no crash report.

Regras práticas:

  • nunca logue token, senha, refresh token ou authorization header;
  • evite logar CPF, email, telefone e endereço completos;
  • use correlation id e endpoint lógico em vez de body inteiro;
  • configure redaction no OkHttp logging interceptor;
  • trate crash reports como ambiente externo;
  • revise eventos de analytics para não enviar PII sem necessidade.

Para observabilidade, o objetivo é conseguir investigar sem transformar ferramentas de monitoramento em cópia paralela do banco. Em apps Android, isso é ainda mais importante porque logs podem circular por suporte, QA, aparelho de teste e relatórios de crash.

Offline-first e segurança: conflito real

Arquitetura offline-first aumenta a quantidade de dados locais. Isso cria um conflito saudável entre experiência e segurança. Um vendedor em campo precisa abrir pedidos sem internet. Um app financeiro não deveria guardar extrato completo indefinidamente. Um app de saúde pode precisar funcionar offline, mas cada registro local tem alto risco.

Algumas decisões úteis:

  • salve apenas campos necessários para a experiência offline;
  • expire dados antigos depois de uma janela clara;
  • criptografe filas com PII ou operações sensíveis;
  • use sync incremental para não baixar histórico desnecessário;
  • limpe dados no logout e em bloqueio remoto;
  • mostre ao usuário quando algo ainda está pendente de sincronização.

O repository é um bom lugar para aplicar essa política. Ele já coordena Room, API, cache e fila. Em vez de deixar cada tela decidir o que guardar, o repository deve receber modelos de domínio e transformar em entidades locais com apenas os campos aprovados.

Checklist para revisar um app Kotlin

Use esta lista como ponto de partida antes de publicar ou refatorar uma área sensível:

  1. Liste dados locais por categoria: público, pessoal, credencial, financeiro, corporativo.
  2. Separe preferências simples de secrets.
  3. Proteja tokens com Keystore ou armazenamento criptografado.
  4. Defina se Room precisa de SQLCipher ou se basta separar dados sensíveis.
  5. Revise arquivos temporários, anexos e cache HTTP.
  6. Configure backup e exclusões conscientemente.
  7. Garanta que logout limpa dados da sessão, não só token.
  8. Reduza logs, analytics e crash reports com PII.
  9. Teste atualização, reinstalação, restauração, logout e rotação de token.
  10. Documente a política para o próximo dev não quebrar por conveniência.

Essa revisão conversa diretamente com temas de segurança no Spring com JWT e OAuth2, Retrofit no Android e testes Android com Kotlin. Segurança local só funciona bem quando app, API e processo de qualidade estão alinhados.

Erros comuns

O primeiro erro é salvar token em SharedPreferences comum porque “o sandbox já protege”. O sandbox ajuda, mas token é credencial. Use proteção adicional quando possível.

O segundo erro é criptografar banco e esquecer logs. Um token removido do SQLite, mas impresso por interceptor em produção, continua vazando.

O terceiro erro é salvar dados demais offline. Se a tela só precisa dos últimos 30 itens, talvez não faça sentido manter anos de histórico no dispositivo.

O quarto erro é não testar restauração. Banco criptografado pode abrir bem no aparelho original e falhar depois de backup/restauração se a chave não acompanha o dado.

O quinto erro é tratar logout como navegação para tela de login. Logout é operação de segurança e limpeza de estado.

Conclusão

Segurança de dados locais no Android com Kotlin é uma decisão de arquitetura. Room, DataStore, SQLCipher, EncryptedSharedPreferences e Keystore são ferramentas úteis, mas a parte mais importante é classificar dados, reduzir persistência, limpar sessão, controlar backups e evitar vazamento por logs.

Em 2026, apps Android profissionais precisam equilibrar offline-first, performance e privacidade. O melhor caminho não é guardar tudo nem apagar tudo: é salvar apenas o necessário, proteger o que é sensível e deixar a política clara no código. Assim, o app continua rápido e útil sem transformar o dispositivo em um ponto frágil do produto.