Liste de contrôle de sécurité pour application Android

Phase 0 : Gouvernance, environnement et CI/CD

Appliquer les portes de validation CI (CI gates)

Exécuter des analyses statiques sur chaque PR : ktlint / Android Lint, tests unitaires/UI, audit des dépendances (Gradle, SBOM).
Bloquer la version en cas de résultats SAST/SCA/DAST de niveau Élevé/Critique ; zéro erreur de lint sur les branches de version.

Gestion des secrets

Aucun secret dans le code source, BuildConfig, AndroidManifest.xml, les ressources ou les journaux.
Utiliser un gestionnaire d'environnement/de secrets (par ex., Gradle secrets, cloud KMS) ; masquer les secrets dans les analyses (analytics).
Effectuer une rotation des clés/jetons périodiquement et en cas de suspicion de fuite.

Preuves et traçabilité

Archiver les rapports d'analyse, la SBOM, les journaux de compilation et les notes de version avec chaque artefact.

Automatisation des analyses

Intégrer une plateforme SAST/DAST/SCA mobile dans la CI/CD à exécuter sur chaque PR et pré-version, et faire échouer automatiquement les portes de validation en cas de problèmes de niveau Élevé/Critique.

Phase 1 : Modélisation des menaces (Threat modeling), classification des données et inventaire

Classifier les données (PII, informations d'identification, jetons, paiement) et cartographier la collecte, le traitement, le stockage (SharedPreferences, fichiers, bases de données, Keystore) et la transmission.
Identifier les limites de confiance (appareil, bac à sable de l'application, Keystore, IPC/Binder, WebView, bibliothèques natives, API backend).
Inventorier les SDK tiers ; privilégier les SDK bien maintenus, signés et respectant le principe du moindre privilège ; minimiser leur nombre.

Phase 2 : Renforcement de la compilation et de la configuration (Gradle + Manifest)

Paramètres de compilation/version (Gradle/Release settings)

Utiliser des versions de production avec réduction/obfuscation de code (minifyEnabled true, shrinkResources true).
Supprimer les symboles de débogage de l'APK/AAB livré.
Conserver les fichiers de mappage côté serveur.
Exclure les bibliothèques de test/débogage de la version de production.
Supprimer les points de terminaison de développement et les indicateurs de fonctionnalités (feature flags) des versions de production.

Signature et autorisations

Protéger les clés de signature (keystores matériels, accès restreint).
Utiliser des configurations de signature dédiées aux versions de production.
Ne déclarer que les autorisations nécessaires dans AndroidManifest.xml.
Éviter les autorisations dangereuses excessives.

Configuration de la sécurité réseau

Utiliser networkSecurityConfig pour appliquer le protocole TLS.
Interdire le trafic en clair (android:usesCleartextTraffic="false").
Utiliser les dérogations de configuration de domaine uniquement lorsque cela est nécessaire et dans un délai limité.

Hygiène du Manifest

Ne pas définir les composants avec exported="true" à moins que cela ne soit strictement nécessaire ; restreindre avec des autorisations lors de l'exportation.
Supprimer les indicateurs de débogage (android:debuggable="false" en production, pas de allowBackup="true" à moins que cela ne soit nécessaire avec un chiffrement approprié).
Fournir un texte explicatif précis (dans l'application) pour toutes les autorisations d'exécution (runtime permissions).

Phase 3 : Stockage local et sécurité du Keystore

Utilisation du Keystore

Stocker les clés de longue durée dans le Keystore Android avec la protection la plus forte possible (matérielle lorsque disponible, authentification de l'utilisateur si l'UX le permet).
Utiliser setUserAuthenticationRequired(true) pour les clés hautement sensibles ; contrôler les opérations avec la biométrie/l'écran de verrouillage, le cas échéant.
Supprimer les secrets protégés par le Keystore lors de la déconnexion ou du changement d'appareil.
Envisager la liaison à l'appareil (device-binding) pour les jetons à haut risque.

Fichiers, SharedPreferences et bases de données

Éviter de stocker des secrets ou des PII sensibles dans des fichiers en texte clair ou dans SharedPreferences.
Chiffrer les bases de données/fichiers sensibles (par ex., SQLCipher ou chiffrement de fichier équivalent).
Utiliser le stockage privé de l'application (MODE_PRIVATE).
Appliquer les indicateurs de protection de fichiers lorsqu'ils sont pris en charge.
S'assurer que les sauvegardes ne contiennent pas de secrets non chiffrés.

Caches et données dérivées

Éviter de conserver des PII dans les caches/fichiers temporaires.
Purger les caches/fichiers temporaires lors de la déconnexion et dans le cadre de la mise en arrière-plan, le cas échéant.
Ne jamais écrire de secrets dans les journaux ou SharedPreferences, même temporairement.

Phase 4 : Mesures de protection de la confidentialité (UI, presse-papiers, captures d'écran)

Masquer l'UI sensible dans les captures d'écran du sélecteur d'applications (par ex., utiliser FLAG_SECURE sur les Activities/Views sensibles).
Pour les flux hautement sensibles, envisager un masquage supplémentaire ou des activités distinctes en « mode sécurisé ».
Éviter de lire le presse-papiers au lancement de l'application ; ne jamais placer de mots de passe/jetons de longue durée dans le presse-papiers.

Phase 5 : Sécurité réseau et TLS/épinglage (pinning)

Application HTTPS/TLS

Appliquer HTTPS vers des hôtes de confiance ; rejeter les certificats/noms d'hôtes invalides ; désactiver les retours (fallbacks) à HTTP.
Configurer des délais d'attente stricts, un backoff exponentiel avec gigue (jitter) et échouer par défaut (fail closed) en cas d'erreurs TLS.

Épinglage de certificat (Certificate pinning)

Privilégier les épingles SPKI SHA-256 ; inclure au moins une épingle de secours par hôte.
Mettre en œuvre l'épinglage via OkHttp / TrustManager personnalisé ou networkSecurityConfig.
Valider contre les scénarios MITM et les certificats feuilles expirés/renouvelés.
Planifier une rotation sécurisée des épingles ; inclure une télémétrie sur les échecs d'épinglage.

Cookies et jetons

Pour les flux web, utiliser des cookies sécurisés, HttpOnly, SameSite.
Éviter les jetons porteurs (bearer tokens) de longue durée sur l'appareil.
Effacer les cookies et les données WebView après les sessions sensibles.

Phase 6 : Authentification, autorisation et session

Flux d'authentification

Utiliser OAuth2/OIDC avec PKCE pour les clients publics ; ne jamais intégrer de secrets client dans l'application.
Privilégier l'authentification basée sur le système/le navigateur (Chrome Custom Tabs / navigateur par défaut) plutôt que la WebView intégrée à l'application pour la connexion.

Jetons

Utiliser des jetons d'accès (access tokens) de courte durée.
Stocker les jetons d'actualisation (refresh tokens) uniquement dans un stockage chiffré lié aux clés du Keystore.
Effectuer une rotation et invalider les jetons lors de la déconnexion, du changement d'appareil et en cas d'activités suspectes.
Lier les sessions au risque de l'appareil (device risk), le cas échéant.

Autorisation

Appliquer l'autorisation côté serveur ; considérer les vérifications côté client uniquement comme consultatives.
Tester et prévenir les vulnérabilités IDOR/BOLA et l'élévation des privilèges sur l'ensemble des API backend utilisées par l'application.

Phase 7 : Renforcement de WebView

Utiliser WebView uniquement lorsque cela est nécessaire ; privilégier le navigateur pour l'authentification et le paiement dans la mesure du possible.

Valeurs par défaut

Désactiver JavaScript à moins que cela ne soit strictement nécessaire.
Si JavaScript est activé, restreindre les capacités et désactiver setAllowFileAccessFromFileURLs et setAllowUniversalAccessFromFileURLs.
Ne pas activer addJavascriptInterface avec des objets qui exposent des méthodes sensibles, en particulier sur l'API < 17.
Appliquer des listes d'autorisation de navigation (hôtes/chemins) ; bloquer file://, javascript: et les schémas non fiables.
Utiliser un stockage WebView non persistant pour les sessions sensibles dans la mesure du possible.
Effacer les cookies, le cache et l'historique lors de la déconnexion.

Sécurité du contenu

Servir le contenu web propriétaire uniquement via HTTPS.
Interdire le contenu mixte (MIXED_CONTENT_NEVER_ALLOW).
S'assurer que l'intégrité du contenu distant est vérifiée et contrôlée (aucun script tiers non fiable à moins que cela ne soit strictement nécessaire).

Phase 8 : Communication inter-applications et liens profonds (deep links)

Privilégier les App Links (liens vérifiés) pour les liens profonds ; valider les origines et les paramètres des liens entrants.

Schémas et intentions (intents) personnalisés

Si des schémas personnalisés ou des intentions implicites sont utilisés, garantir l'unicité et une validation robuste de toutes les données entrantes.
Protéger les Activities/Services/BroadcastReceivers exportés avec des autorisations ou des intentions explicites ; éviter les filtres d'intention excessivement larges.
Se défendre contre l'usurpation d'intention (intent spoofing), le détournement d'URL et les redirections ouvertes en vérifiant l'identité de l'appelant et les paramètres.

Phase 9 : Rétro-ingénierie et résistance à l'altération (tampering)

Réduire les fuites statiques

Supprimer les versions de débogage, les journaux détaillés, les menus de débogage et les points de terminaison de test des versions de production.
Obfusquer et réduire le code (ProGuard/R8) et les ressources.
Éviter de laisser des chaînes de caractères significatives (clés d'API, secrets) dans les ressources ou les bibliothèques natives.

Vérifications de l'environnement

Détecter les indicateurs de root/hooking/débogueur (chemins root courants, répertoires système inscriptibles, frameworks d'instrumentation) et enregistrer les signaux.
Répondre de manière proportionnelle (fonctionnalité réduite, vérification supplémentaire ou blocage) en fonction du risque, tout en maintenant l'UX.

Tests d'altération (Tamper testing)

S'assurer que les applications reconditionnées ou re-signées échouent aux contrôles d'intégrité ou à l'attestation du serveur (par ex., API de sécurité/d'attestation).
Traiter les signaux côté client comme des indications pour le backend ; jamais comme l'unique contrôle de sécurité.

Phase 10 : Cryptographie et caractère aléatoire

Utiliser les primitives cryptographiques fournies par la plateforme (Java Cryptography Architecture, Android Keystore) ; ne pas créer d'algorithmes personnalisés.
Utiliser des modes AEAD modernes comme AES-GCM/ChaCha20-Poly1305 pour le chiffrement authentifié.
Utiliser des fonctions de dérivation de clé (KDF) reconnues (PBKDF2/HKDF) avec des paramètres et des sels appropriés.
Générer des clés/Vecteurs d'Initialisation (IVs) avec un RNG sécurisé (SecureRandom ou les API de la plateforme).
Ne jamais réutiliser les IV/nonces.
Conserver les clés dans le Keystore ou chiffrées au repos.

Phase 11 : Autorisations, notifications et identifiants

Demander les autorisations minimales, au moment de l'utilisation, avec des explications claires en contexte de la valeur pour l'utilisateur.

Autorisations liées à la confidentialité

Limiter l'accès à l'emplacement, aux contacts, à la caméra, au microphone, au stockage et à l'état du téléphone au strict nécessaire.
Gérer le refus et la révocation de manière fluide.
Éviter les modèles de conception trompeurs (dark patterns) qui font pression sur les utilisateurs.

Identifiants et suivi

Privilégier les identifiants limités à l'application ou réinitialisables ; éviter de créer un profilage (fingerprinting) persistant à travers les applications.
Utiliser les identifiants publicitaires ou d'analyse uniquement conformément aux politiques de la plateforme.
Ne jamais utiliser d'identifiants matériels interdits pour le suivi.

Notifications

Minimiser les données sensibles dans le contenu des notifications.
Utiliser une formulation générique et masquer les détails sur l'écran de verrouillage dans la mesure du possible.

Phase 12 : Journalisation, analyses (analytics) et rapports de plantage

Utiliser une journalisation structurée avec des niveaux de gravité ; désactiver la journalisation détaillée/de débogage dans les versions de production.
Masquer les PII et les secrets dans les journaux, les événements d'analyse et les rapports de plantage.
Agréger et échantillonner les analyses dans la mesure du possible.
S'assurer que les fichiers de symboles/de mappage pour les versions obfusquées sont stockés en toute sécurité côté serveur pour la dés-obfuscation des plantages.
Ne pas inclure de fichiers de symboles/de mappage dans l'application.

Phase 13 : Tests, DAST et vérification d'exécution

Tests d'interception du trafic

Vérifier la résistance aux MITM (certificats invalides, non-correspondance du nom d'hôte, CA non fiable).
Vérifier que l'épinglage bloque l'interception lorsqu'il est configuré.

Inspection d'exécution

Confirmer qu'aucun secret/PII n'apparaît dans les journaux.
Vérifier que les données sensibles sont chiffrées au repos.
Examiner le comportement de WebView à l'exécution (navigation, JS, stockage).
Examiner le comportement du stockage local à l'exécution (fichiers, SharedPreferences, bases de données).
Valider que les clés sauvegardées dans le Keystore sont utilisées là où cela est prévu.
Valider que les contrôles d'accès pour les clés du Keystore se comportent comme prévu.

Tests d'abus d'API

Tester la limitation de débit (rate limiting).
Tester la protection contre le rejeu (replay protection).
Tester les limites de pagination.
Tester l'affectation massive (mass assignment).
Tester l'hygiène des messages d'erreur pour les API backend.

Analyse dynamique

Exécuter un DAST mobile tout en parcourant les flux principaux pour mettre en évidence les mauvaises configurations de transport, les problèmes WebView, les fuites de stockage et les problèmes de journalisation.
Exporter les preuves du DAST pour le tri et les re-tests.

Phase 14 : SBOM et preuves

SBOM et dépendances

Générer une SBOM pour tous les modules Gradle et SDK intégrés.
Suivre les CVE et mettre à jour les dépendances régulièrement.
Surveiller l'état de santé des dépendances dans le cadre de l'état de préparation à la sortie.
Surveiller la conformité des licences dans le cadre de l'état de préparation à la sortie.

Dossier de preuves

Joindre les artefacts d'analyse au dossier de version.
Joindre la SBOM au dossier de version.
Joindre les différences du manifest au dossier de version.
Joindre les listes d'autorisations et d'exportation de composants au dossier de version.
Joindre les rapports de tests automatisés/manuels au dossier de version.

Phase 15 : Rapports et alignement sur les normes

Rapport

Fournir un résumé exécutif, la portée/méthodologie, des conclusions détaillées avec PoC/preuves, les évaluations des risques, des conseils de remédiation et les résultats des re-tests.

Correspondance des normes (exemple)

Référence rapide pour le praticien

Manifest/Network : Aucun trafic en clair en production ; domaines networkSecurityConfig stricts ; éviter d'exporter des composants sans justification solide.
Secrets & stockage : Utiliser le Keystore Android pour les clés de longue durée ; chiffrer la base de données/les fichiers ; ne jamais stocker de secrets dans SharedPreferences ou les journaux.
Network : HTTPS uniquement ; épinglage de certificat/SPKI avec des sauvegardes pour les points de terminaison critiques ; vérifier que les tentatives MITM échouent.
Auth : OIDC + PKCE ; jetons d'accès de courte durée ; jetons d'actualisation dans un stockage chiffré ; autorisation côté serveur ; tester IDOR/BOLA.
WebView : Privilégier le navigateur pour l'authentification ; si WebView, JS désactivé par défaut, restreindre les interfaces, navigation sur liste d'autorisation, stockage non persistant pour les flux sensibles.
Confidentialité : Utiliser FLAG_SECURE pour les écrans sensibles ; éviter les secrets dans le presse-papiers ; minimiser les autorisations et fournir des explications claires.
Hygiène de la version : Obfusquer et réduire ; supprimer les journaux/menus/points de terminaison de test de débogage ; valider les autorisations et les composants exportés à chaque version.