Checklist pour le stockage sécurisé en Kotlin : choisir entre Android Keystore, EncryptedSharedPreferences et le chiffrement de base de données pour tokens, clés et données personnelles.
Le stockage sécurisé dans une application métier signifie une chose : si quelqu'un récupère le téléphone (ou les fichiers de votre app), il ne doit pas pouvoir lire ou réutiliser ce que vous avez sauvegardé. Cela concerne les données au repos (sur le disque) mais aussi les fuites via les sauvegardes, les logs, les rapports de crash ou les outils de debug.
Un test mental simple : que peut faire un inconnu s'il ouvre le dossier de stockage de votre app ? Dans de nombreuses apps, les éléments les plus précieux ne sont pas des photos ou des réglages. Ce sont de petites chaînes qui déverrouillent l'accès.
Le stockage sur l'appareil inclut souvent des tokens de session (pour maintenir la connexion), des refresh tokens, des clés d'API, des clés de chiffrement, des données personnelles (PII) comme les noms et emails, et des enregistrements métier mis en cache pour une utilisation hors ligne (commandes, tickets, notes clients).
Voici des modes de défaillance courants :
C'est pourquoi « juste stocker dans SharedPreferences » n'est pas acceptable pour tout ce qui accorde l'accès (tokens) ou peut nuire aux utilisateurs et à votre entreprise (PII). Plain SharedPreferences, c'est comme écrire des secrets sur un post-it dans l'app : pratique, mais facile à lire si quelqu'un en a l'occasion.
Le point de départ le plus utile est de nommer chaque élément stocké et de se poser deux questions : est-ce que ça déverrouille quelque chose, et est-ce problématique si ça devient public ? Le reste (Keystore, preferences chiffrées, base chiffrée) découle de ça.
Le stockage sécurisé devient plus simple quand vous arrêtez de traiter toutes les « données sensibles » de la même façon. Commencez par lister ce que l'app enregistre et ce qui se passerait si cela fuyait.
Les tokens ne sont pas équivalents aux mots de passe. Les access tokens et refresh tokens sont conçus pour être stockés afin que l'utilisateur reste connecté, mais ce sont tout de même des secrets de grande valeur. Les mots de passe ne devraient pas être stockés du tout. Si vous avez besoin de login, conservez uniquement ce qui est nécessaire pour maintenir une session (généralement des tokens) et déléguez la vérification du mot de passe au serveur.
Les clés sont d'une autre catégorie. Les clés d'API, de signature et de chiffrement peuvent déverrouiller des systèmes entiers, pas seulement un compte utilisateur. Si quelqu'un les extrait d'un appareil, il peut automatiser des abus à grande échelle. Une bonne règle : si une valeur peut être utilisée en dehors de l'app pour usurper l'app ou déchiffrer des données, traitez-la comme plus risquée qu'un token utilisateur.
PII couvre tout ce qui peut identifier une personne : email, téléphone, adresse, notes client, identifiants gouvernementaux, données de santé. Même des champs qui paraissent anodins deviennent sensibles lorsqu'ils sont combinés.
Un système d'étiquetage rapide utile en pratique :
Android Keystore est optimal quand vous devez protéger des secrets qui ne devraient jamais quitter l'appareil en clair. C'est un coffre pour des clés cryptographiques, pas une base de données pour vos données.
Ce pour quoi il est utile : générer et garder des clés utilisées pour chiffrer, déchiffrer, signer ou vérifier. Typiquement, vous chiffrez un token ou des données hors ligne ailleurs, et une clé Keystore est ce qui le déverrouille.
Sur de nombreux appareils, les clés Keystore peuvent être matérielles. Cela veut dire que les opérations sur la clé se déroulent dans un environnement protégé et que le matériel de la clé ne peut pas être extrait. Cela réduit le risque lié à un malware pouvant lire les fichiers de l'app.
Le support matériel n'est pas garanti sur tous les appareils, et le comportement varie selon le modèle et la version d'Android. Concevez en supposant que les opérations sur les clés peuvent échouer.
Keystore peut exiger la présence de l'utilisateur avant d'autoriser l'utilisation d'une clé. C'est ainsi que vous liez l'accès à la biométrie ou aux identifiants de l'appareil. Par exemple, vous pouvez chiffrer un token d'export et ne le déchiffrer qu'après confirmation par empreinte ou code PIN.
Keystore est fortement adapté quand vous voulez une clé non exportable, une approbation biométrique ou par identifiants pour des actions sensibles, et des secrets par appareil qui ne doivent pas se synchroniser ou voyager avec les sauvegardes.
Prévoyez les écueils : les clés peuvent être invalidées après des changements d'écran de verrouillage, des modifications biométriques ou des événements de sécurité. Anticipez les échecs et implémentez un contournement propre : détecter les clés invalides, effacer les blobs chiffrés et demander à l'utilisateur de se reconnecter.
EncryptedSharedPreferences est un bon choix par défaut pour un petit ensemble de secrets en forme clé-valeur. C'est « SharedPreferences, mais chiffré », donc on ne peut pas simplement ouvrir un fichier et lire les valeurs.
En interne, il utilise une clé maître pour chiffrer et déchiffrer les valeurs. Cette clé maître est protégée par Android Keystore, donc votre app ne stocke pas la clé de chiffrement brute en clair.
C'est généralement suffisant pour quelques petits éléments lus fréquemment, comme les access et refresh tokens, les IDs de session, les IDs d'appareil, des flags d'environnement ou de petits états comme l'heure de dernière synchro. C'est aussi acceptable pour de minuscules fragments de données utilisateur si vous devez absolument les stocker, mais ça ne doit pas devenir votre dépôt pour la PII.
Ce n'est pas adapté pour des données volumineuses ou structurées. Si vous avez besoin de listes hors ligne, de recherche ou de requêtes par champs (clients, tickets, commandes), EncryptedSharedPreferences devient lent et maladroit. C'est à ce moment-là que vous voulez une base de données chiffrée.
Une règle simple : si vous pouvez lister chaque clé stockée sur un écran, EncryptedSharedPreferences est probablement suffisant. Si vous avez besoin de lignes et de requêtes, passez à la suite.
Le chiffrement de la base devient important quand vous stockez plus qu'un petit réglage ou un token. Si votre app garde des données métier sur l'appareil, supposez qu'elles peuvent être extraites d'un téléphone perdu à moins que vous ne les protégiez.
Une base de données a du sens quand vous avez besoin d'accès hors ligne à des enregistrements, d'un cache local pour la performance, d'historiques/traçabilité, ou de notes et pièces jointes longues.
Chiffrement complet de la base (souvent de type SQLCipher) chiffre le fichier entier au repos. Votre app l'ouvre avec une clé. C'est simple à raisonner car vous n'avez pas à vous souvenir quelles colonnes sont protégées.
Chiffrement au niveau applicatif des champs chiffre seulement certains champs avant écriture, puis les déchiffre après lecture. Cela peut fonctionner si la plupart des enregistrements ne sont pas sensibles, ou si vous essayez de conserver un format de base sans changer le fichier.
Le chiffrement complet cache tout sur le disque, mais une fois la base déverrouillée, votre app peut interroger normalement.
Le chiffrement des champs protège des colonnes spécifiques, mais vous perdez la recherche et le tri faciles sur des valeurs chiffrées. Trier par un nom de famille chiffré ne fonctionne pas de façon fiable, et la recherche devient soit « rechercher après déchiffrement » (lent) soit « stocker des index supplémentaires » (plus de complexité et des fuites potentielles).
La clé de la base ne doit jamais être codée en dur ou fournie avec l'app. Un schéma courant consiste à générer une clé de base de données aléatoire, puis à la stocker enveloppée (chiffrée) en utilisant une clé conservée dans Android Keystore. À la déconnexion, vous pouvez supprimer la clé enveloppée et traiter la base locale comme jetable, ou la conserver si l'app doit fonctionner hors ligne entre les sessions.
Vous ne choisissez pas « l'option la plus sécurisée » en général. Vous choisissez l'option la plus sûre qui convient à la façon dont votre app utilise les données.
Questions qui déterminent le bon choix :
Un mappage pratique :
EncryptedSharedPreferences car ils sont petits et lus souvent.Les données mixtes sont normales dans les apps métier. Un pattern pratique est de générer une clé de chiffrement des données (DEK) aléatoire pour votre base locale ou fichier, de ne stocker que la DEK enveloppée avec une clé Keystore, et de la faire tourner quand c'est nécessaire.
Si vous doutez, choisissez la voie la plus sûre et simple : stockez moins. Évitez la PII hors ligne sauf si c'est nécessaire, et gardez les clés dans Keystore.
Commencez par écrire tout ce que vous prévoyez de stocker sur l'appareil et la raison exacte pour laquelle cela doit y être. C'est le moyen le plus rapide d'éviter le stockage « au cas où ».
Avant d'écrire du code, décidez de vos règles : combien de temps chaque élément doit vivre, quand il doit être remplacé, et ce que signifie « déconnexion ». Un access token peut expirer en 15 minutes, un refresh token durer plus longtemps, et la PII hors ligne peut nécessiter une règle « supprimer après 30 jours ».
Implémentation maintenable :
EncryptedSharedPreferences, clés protégées par Android Keystore, et jeux de données hors ligne plus volumineux dans une base de données chiffrée.Testez ensuite les cas fastidieux qui cassent souvent le stockage sécurisé en production : restauration depuis une sauvegarde, mise à jour depuis une ancienne version, changements des paramètres de verrouillage de l'appareil, migration vers un nouveau téléphone. Assurez-vous que les utilisateurs ne se retrouvent pas coincés dans une boucle où les données stockées ne peuvent pas être déchiffrées mais l'app continue d'essayer.
Enfin, consignez les décisions sur une page que toute l'équipe peut suivre : ce qui est stocké, où, les périodes de rétention et ce qu'il faut faire en cas d'échec de déchiffrement.
La plupart des échecs ne viennent pas d'avoir choisi la mauvaise librairie. Ils surviennent quand un petit raccourci copie discrètement des secrets dans des endroits non prévus.
Le plus grand signal d'alerte est un refresh token (ou token de session longue durée) sauvegardé en clair n'importe où : SharedPreferences, un fichier, un cache « temporaire » ou une colonne de base locale. Si quelqu'un obtient une sauvegarde, un dump d'un appareil rooté ou un artefact de build debug, ce token peut survivre au mot de passe.
Les secrets fuient aussi par la visibilité, pas seulement le stockage. Logger des headers complets, imprimer des tokens pendant le debug, ou attacher un contexte « utile » aux rapports de crash et aux événements analytics peut exposer des identifiants hors de l'app. Traitez les logs comme publics.
La gestion des clés est un autre point faible fréquent. Utiliser une seule clé pour tout augmente le rayon d'impact. Ne pas faire de rotation signifie qu'anciennes compromissions restent valables. Prévoyez un plan pour versionner les clés, les faire tourner et gérer les anciennes données chiffrées.
Le chiffrement ne stoppe pas les sauvegardes cloud qui copient les données locales de l'app. Il n'empêche pas les captures d'écran ou enregistrements d'écran de récupérer de la PII. Il n'empêche pas des builds de debug avec des paramètres relâchés ou des fonctions d'export (CSV/partage) qui fuient des champs sensibles. Le presse-papiers peut aussi divulguer des codes à usage unique ou des numéros de compte.
Aussi, le chiffrement ne corrige pas l'autorisation. Si votre app affiche de la PII après qu'un utilisateur s'est déconnecté, ou garde en cache des données accessibles sans ré-authentification, c'est un bug de contrôle d'accès. Verrouillez l'UI, effacez les caches sensibles à la déconnexion et revérifiez les permissions avant d'afficher des données protégées.
Le stockage sécurisé, ce n'est pas seulement l'endroit où vous mettez les secrets. C'est leur comportement dans le temps : quand l'app dort, quand un utilisateur se déconnecte et quand l'appareil est verrouillé.
Pour les tokens, planifiez le cycle de vie complet. Les access tokens doivent être de courte durée. Les refresh tokens doivent être traités comme des mots de passe. Si un token est expiré, rafraîchissez-le silencieusement. Si un rafraîchissement échoue (révocation, mot de passe changé, appareil supprimé), arrêtez les boucles de retry et forcez une reconnexion propre. Supportez aussi la révocation côté serveur. Un stockage local parfait n'aide pas si vous n'invalidez jamais des identifiants volés.
Utilisez la biométrie pour la ré-authentification, pas pour tout. Demandez-la quand l'action présente un vrai risque (voir de la PII, exporter des données, modifier des détails de paiement, montrer une clé à usage unique). Ne la demandez pas à chaque ouverture d'app.
À la déconnexion, soyez strict et prévisible :
Les cas limites comptent dans les apps métier : plusieurs comptes sur un même appareil, profils professionnels, sauvegarde/restauration, transfert d'appareil à appareil et déconnexions partielles (changer d'entreprise/espace de travail plutôt que déconnexion complète). Testez l'arrêt forcé, les upgrades OS et les changements d'heure car la dérive temporelle peut casser la logique d'expiration.
La détection de falsification est un compromis. Des contrôles basiques (builds débogables, flags d'émulateur, signaux root simples, verdicts Play Integrity) réduisent les abus occasionnels, mais un attaquant déterminé peut les contourner. Traitez ces signaux comme des entrées de risque : limitez l'accès hors ligne, demandez une ré-authentification et journalisez l'événement.
Utilisez ceci avant la mise en production. Cela cible les endroits où le stockage sécurisé échoue dans les apps métier réelles.
Une validation rapide est le test « mauvais jour » : un utilisateur se déconnecte, change son mot de passe, restaure une sauvegarde sur un nouveau téléphone et ouvre l'app en avion. Le résultat doit être prévisible : soit les données se déchiffrent pour le bon utilisateur, soit elles sont effacées et re-téléchargées après identification.
Imaginez une app de commerciaux terrain utilisée dans des zones de faible signal. Les commerciaux se connectent le matin, consultent hors ligne leurs clients assignés, ajoutent des notes de visite, puis synchronisent plus tard. C'est là qu'une checklist de stockage arrête d'être théorique et commence à prévenir des fuites réelles.
Une répartition pratique :
EncryptedSharedPreferences.Ajoutez maintenant deux fonctionnalités et le risque change.
Si vous ajoutez « se souvenir de moi », le refresh token devient la porte principale pour revenir dans le compte. Traitez-le comme un mot de passe. Selon vos utilisateurs, vous pouvez exiger le déverrouillage de l'appareil (PIN/pattern/biométrie) avant de le déchiffrer.
Si vous activez le mode hors ligne, vous ne protégez plus seulement une session. Vous protégez une liste complète de clients qui a une valeur intrinsèque. Cela vous pousse en général vers le chiffrement de base de données plus des règles claires de logout : effacer la PII locale, ne garder que l'essentiel pour la prochaine connexion et annuler la synchronisation en arrière-plan.
Testez sur des appareils réels, pas seulement des émulateurs. Au minimum, vérifiez le comportement verrouillage/déverrouillage, la réinstallation, la sauvegarde/restauration et la séparation multi-utilisateur ou profil professionnel.
Le stockage sécurisé ne fonctionne que si c'est une habitude. Rédigez une politique de stockage courte que votre équipe peut suivre : quoi où (Keystore, EncryptedSharedPreferences, base chiffrée), ce qui n'est jamais stocké, et ce qui doit être effacé à la déconnexion.
Intégrez-la dans la livraison quotidienne : définition de prêt, revue de code et contrôles de release.
Une checklist légère pour le relecteur :
Si votre équipe utilise AppMaster (appmaster.io) pour construire des apps métier et exporte du source Kotlin pour le client Android, gardez la même approche SecureStorage pour que le code généré et le code personnalisé suivent une politique cohérente.
Construisez un petit POC qui stocke un token d'auth et un enregistrement PII (par exemple le numéro de téléphone d'un client nécessaire hors ligne). Testez ensuite installation propre, upgrade, déconnexion, changements d'écran de verrouillage et effacement des données de l'app. Élargissez seulement quand le comportement d'effacement est correct et reproductible.
What’s the simplest “safe default” for storing tokens and user data in a Kotlin business app?Commencez par lister exactement ce que vous stockez et pourquoi. Mettez les petits secrets de session comme les access et refresh tokens dans EncryptedSharedPreferences, gardez les clés cryptographiques dans Android Keystore, et utilisez une base de données chiffrée pour les enregistrements métier et les données personnelles (PII) hors ligne dès que vous avez plus que quelques champs ou besoin de requêtes.
Why isn’t plain SharedPreferences OK for tokens or PII?Les SharedPreferences en clair écrivent des valeurs dans un fichier qui peut souvent être lu via des sauvegardes d'appareil, un accès à un appareil rooté ou des artefacts de debug. Si la valeur est un token ou des PII, la traiter comme un simple réglage la rend beaucoup plus facile à copier et réutiliser hors de l'application.
When should I use Android Keystore instead of just encrypting a file myself?Utilisez Android Keystore pour générer et conserver des clés cryptographiques qui ne doivent pas être extraites. Vous utilisez en général ces clés pour chiffrer d'autres données (tokens, clés de base de données, fichiers) et vous pouvez exiger une authentification utilisateur (biométrie ou identifiants de l'appareil) avant d'autoriser l'utilisation de la clé.
What does “hardware-backed” Keystore actually protect me from?Cela signifie que les opérations sur la clé peuvent se produire dans un matériel protégé, de sorte que le matériel de la clé est plus difficile à extraire, même si un attaquant peut lire les fichiers de l'application. N'assumez pas que c'est toujours disponible ni que son comportement est identique sur tous les appareils ; concevez un flux de récupération quand les clés sont indisponibles ou invalidées.
Is EncryptedSharedPreferences enough for most apps?EncryptedSharedPreferences suffit généralement pour un petit ensemble de secrets clé-valeur lus fréquemment, comme les access/refresh tokens, les identifiants de session et de petites pièces d'état. Ce n'est pas adapté aux données volumineuses, aux enregistrements structurés hors ligne ou à tout ce que vous devez interroger et filtrer comme des clients, tickets ou commandes.
When do I need database encryption instead of encrypted preferences?Choisissez une base de données chiffrée quand vous stockez des données métier hors ligne ou des PII à grande échelle, que vous avez besoin de requêtes/recherches/tri, ou que vous conservez un historique pour une utilisation hors ligne. Elle réduit le risque qu'un appareil perdu expose des listes entières de clients ou des notes, tout en permettant à l'app de fonctionner hors ligne avec une stratégie de clés claire.
Should I use full database encryption or encrypt only specific fields?Le chiffrement complet de la base protège tout le fichier au repos et est plus simple à raisonner car vous n'avez pas à suivre quelles colonnes sont sensibles. Le chiffrement au niveau des champs peut fonctionner pour quelques colonnes mais rend la recherche et le tri difficiles, et il est facile de fuites accidentelles via des index ou des champs dérivés.
What’s a practical way to manage encryption keys without hardcoding anything?Générez une clé de base de données aléatoire, puis stockez-la uniquement sous forme chiffrée (wrapped) en utilisant une clé Keystore. Ne codez jamais de clés en dur ni ne les incluez dans l'application, et définissez ce qui arrive à la déconnexion ou à l'invalidation de clé (souvent : supprimer la clé wrapped et traiter les données locales comme jetables).
What should my app do when Keystore keys get invalidated and decryption fails?Les clés peuvent être invalidées par des changements d'écran de verrouillage, des modifications biométriques, des événements de sécurité OS ou des scénarios de restauration/migration. Gérez-le explicitement : détectez les échecs de déchiffrement, effacez les blobs chiffrés ou la base locale en toute sécurité, et demandez à l'utilisateur de se reconnecter plutôt que d'essayer en boucle ou de retomber sur du stockage en clair.
What are the most common mistakes that still leak secrets even if I use encryption?La plupart des fuites ont lieu « en dehors du coffre » : logs, rapports de crash, événements d'analytics, impressions de debug, caches HTTP, captures d'écran, presse-papiers et chemins de sauvegarde/restauration. Traitez les logs comme publics, n'enregistrez jamais de tokens ou de PII complètes, désactivez les voies d'export accidentelles et assurez-vous que la déconnexion efface les données en mémoire et sur disque.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
