6 risques de sécurité dans le développement Android

 

Android équipe la grande majorité des smartphones dans le monde, ce qui en fait la cible préférée des cybercriminels. Les experts en développement Android doivent donc traiter la sécurité dès la conception de l’application, et pas au moment de la publication. Quels sont les risques de sécurité qui se cachent derrière le robot vert, et comment s’en protéger en 2026 ?

Le contexte a beaucoup changé depuis les premières versions du système. Google filtre davantage les applications, impose des versions cibles récentes et a lancé la vérification d’identité des développeurs. Mais les attaques ont suivi : chevaux de Troie bancaires, kits de développement (SDK) piégés, abus des services d’accessibilité. Voici les six risques à surveiller dans tout projet de développement Android, avec les mesures recommandées par l’OWASP et par la documentation officielle d’Android.

Sommaire

• 1. Les logiciels malveillants ou malware
• 2. La fragmentation du parc Android
• 3. Les surcouches constructeurs et les appareils modifiés
• 4. Les applications installées en dehors de Google Play
• 5. Les applications malveillantes et les SDK tiers
• 6. Les failles introduites pendant le développement
• Sécuriser le développement Android avec l’OWASP MASVS
• Ce qui change avec Android 16 et les règles de Google Play
• Tester la sécurité d’une application Android

1. Les logiciels malveillants ou malware

Les malwares restent la première menace sur Android. Selon le bilan de sécurité 2025 publié par Google, plus de 1,75 million d’applications contraires aux règles ont été bloquées avant leur publication sur Google Play, plus de 80 000 comptes de développeurs malveillants ont été bannis, et Google Play Protect a repéré plus de 27 millions de nouvelles applications malveillantes provenant de l’extérieur du store.

Les familles qui dominent aujourd’hui ne se contentent plus d’envoyer des SMS surtaxés. On trouve surtout :

• Les chevaux de Troie bancaires, qui superposent un faux écran de connexion à l’application de la banque ou détournent les services d’accessibilité pour lire l’écran et valider des opérations.
• Les voleurs de données, qui récupèrent identifiants, codes reçus par SMS, contacts ou photos.
• Les applications reconditionnées : une application légitime est décompilée, modifiée puis redistribuée avec un code malveillant.
• Les logiciels publicitaires et espions, souvent cachés dans des utilitaires (nettoyeurs, lampes de poche, économiseurs de batterie).

Pour le développeur, la conséquence est directe : l’application doit supposer qu’elle peut tourner sur un appareil compromis. Il faut protéger les écrans sensibles contre la capture et la superposition, ne jamais faire confiance aux données venant de l’appareil et vérifier côté serveur, avec l’API Play Integrity, que les requêtes viennent bien de votre application authentique.

2. La fragmentation du parc Android

Les smartphones Android ne fonctionnent pas tous sous la même version du système. Les fabricants arrêtent les mises à jour au bout de quelques années et de nombreux appareils en circulation ne reçoivent plus les correctifs mensuels publiés dans les bulletins de sécurité Android. Une faille corrigée dans une version récente reste donc exploitable sur une partie de vos utilisateurs.

Google a durci les règles pour limiter le problème. Depuis Android 14, une application qui cible une version d’API inférieure à 23 ne peut plus être installée, car de nombreux malwares visaient d’anciennes versions pour contourner le système d’autorisations. Et Google Play impose une version cible récente : depuis le 31 août 2026, les nouvelles applications et les mises à jour doivent cibler Android 16 (API 36).

En pratique, choisissez une version minimale (minSdk) qui écarte les appareils sans correctifs quand votre application manipule des données sensibles, et prévoyez dans le budget la mise à jour annuelle de la version cible. C’est un poste de maintenance à part entière, au même titre que les correctifs fonctionnels.

3. Les surcouches constructeurs et les appareils modifiés

La liberté de personnalisation d’Android a un revers. Les constructeurs (Samsung, Xiaomi, Oppo et bien d’autres) ajoutent leurs propres surcouches et applications système, avec un rythme de correctifs qui varie d’une marque à l’autre. Certains utilisateurs vont plus loin : appareil rooté, ROM alternative ou lanceur tiers téléchargé hors du store. Sur ces appareils, les protections du système ne sont plus garanties et un lanceur malveillant peut, par exemple, rediriger une icône vers une fausse application pour du hameçonnage.

Une application qui manipule de l’argent, des données de santé ou des accès professionnels doit savoir dans quel environnement elle tourne. Le verdict d’intégrité de l’API Play Integrity indique si l’appareil est certifié et si l’application n’a pas été modifiée. À vous de décider ensuite de la réponse : simple avertissement, fonctionnalités limitées ou blocage des opérations sensibles.

4. Les applications installées en dehors de Google Play

Le téléchargement d’applications depuis des sites non officiels reste la principale porte d’entrée des malwares. L’utilisateur cherche une version gratuite d’une application payante et récupère une copie modifiée qui installe un virus. Pour votre application, le risque est double : vos utilisateurs peuvent installer une fausse version qui porte votre nom, et votre code peut être décompilé pour en extraire des clés ou de la logique métier.

Google a lancé en 2026 la vérification des développeurs Android : sur les appareils certifiés, les applications devront provenir de développeurs dont l’identité a été vérifiée, même lorsqu’elles sont distribuées hors de Google Play. Les protections ont démarré le 30 septembre 2026 au Brésil, en Indonésie, à Singapour et en Thaïlande, et doivent s’étendre au monde entier en 2027. Si vous distribuez une application en dehors du store, par exemple une application interne d’entreprise, inscrivez votre compte de développeur dès maintenant.

Côté code, ne stockez aucun secret dans l’application (clé d’API privée, mot de passe de service) : tout ce qui est embarqué dans l’APK finit par être lu. Les secrets restent sur le serveur, et l’application obtient des jetons à durée de vie courte.

5. Les applications malveillantes et les SDK tiers

Publier une application Android sur Google Play reste simple, et des milliers d’applications arrivent chaque jour. Malgré les contrôles automatiques et humains, certaines applications malveillantes passent le filtre et sont retirées après coup. Le risque ne vient pas seulement des autres applications installées sur le téléphone : il peut se trouver dans la vôtre.

Une application Android moderne embarque des dizaines de bibliothèques : analytics, publicité, paiement, cartographie, chat. Chacune a accès aux mêmes autorisations que votre application. Un SDK compromis ou trop curieux peut collecter des données à votre insu, et c’est votre application qui sera retirée du store ou mise en cause au titre du RGPD. C’est le même problème de chaîne d’approvisionnement logicielle que l’OWASP classe désormais parmi les risques majeurs des applications web.

Les bonnes pratiques : n’ajouter que les SDK nécessaires, consulter le Google Play SDK Index avant de choisir une bibliothèque, figer les versions, surveiller les vulnérabilités connues des dépendances et vérifier ce que chaque SDK déclare dans la section « Sécurité des données » de votre fiche Play Store.

6. Les failles introduites pendant le développement

En 2014, la faille Heartbleed dans OpenSSL a montré qu’une bibliothèque largement utilisée pouvait exposer des millions d’applications sans faute de leurs développeurs. Ce risque existe toujours, mais la plupart des incidents viennent aujourd’hui d’erreurs dans le code de l’application elle-même. Les plus fréquentes dans le développement Android :

• Composants exportés par erreur. Depuis Android 12, toute activité, service ou récepteur doté d’un filtre d’intention doit déclarer explicitement l’attribut android:exported. Une valeur à « true » sans contrôle d’accès ouvre l’application aux autres applications installées.
• Données stockées en clair dans les préférences, une base SQLite ou la mémoire externe. Les clés de chiffrement doivent rester dans l’Android Keystore.
• Communications non chiffrées. Depuis Android 9, les principales bibliothèques HTTP refusent le trafic en clair par défaut, mais certaines ne le font pas. La configuration de sécurité réseau permet d’imposer HTTPS partout.
• WebView mal configurées, avec JavaScript activé sans besoin ou accès aux fichiers locaux.
• Authentification maison. Google recommande aujourd’hui Credential Manager et les passkeys plutôt que le stockage d’identifiants sur l’appareil.
• Journaux trop bavards, qui laissent passer des jetons ou des données personnelles dans les logs.

Beaucoup de ces erreurs viennent aussi du comportement des utilisateurs, qui accordent trop vite des autorisations. Nous l’expliquons dans notre article sur la sécurité et les autorisations dans le développement mobile.

Sécuriser le développement Android avec l’OWASP MASVS

Pour ne rien oublier, la référence est l’OWASP MASVS (Mobile Application Security Verification Standard), le standard de l’OWASP pour la sécurité des applications mobiles. Il regroupe les exigences en huit familles, que l’on peut traduire en questions concrètes pour un projet de développement Android :

• MASVS-STORAGE : les données sensibles sont-elles stockées de façon sûre, et exclues des sauvegardes et des journaux ?
• MASVS-CRYPTO : les algorithmes sont-ils à jour et les clés protégées par le Keystore ?
• MASVS-AUTH : l’authentification et les droits sont-ils contrôlés côté serveur ?
• MASVS-NETWORK : toutes les communications passent-elles en TLS, avec une validation correcte des certificats ?
• MASVS-PLATFORM : les intents, les composants exportés et les WebView sont-ils maîtrisés ?
• MASVS-CODE : la version cible est-elle récente, les dépendances à jour et les entrées validées ?
• MASVS-RESILIENCE : l’application résiste-t-elle à la rétro-ingénierie et à la modification, quand c’est nécessaire ?
• MASVS-PRIVACY : l’application ne collecte-t-elle que les données nécessaires, et l’utilisateur garde-t-il le contrôle ?

Le guide de test associé, l’OWASP MASTG, décrit comment vérifier chaque exigence. C’est la grille qu’utilisent la plupart des auditeurs lors d’un test d’intrusion mobile.

Ce qui change avec Android 16 et les règles de Google Play

Chaque version d’Android ajoute des protections qui obligent à adapter le code. Celles d’Android 16 (API 36) concernent directement la sécurité :

• Safer Intents : après Android 15, qui contrôlait l’application émettrice, Android 16 permet à l’application réceptrice d’activer une résolution stricte des intents dans son manifeste. Google prévoit d’en faire le comportement par défaut dans les prochaines versions.
• Accès au réseau local : l’accès aux appareils du réseau local passera derrière une nouvelle autorisation d’exécution. La protection est facultative pour l’instant et sera imposée dans une version ultérieure.
• Version de MediaStore : elle devient propre à chaque application, pour empêcher son usage comme empreinte de l’appareil.

Ajoutez-y les deux règles de Google déjà citées : la version cible Android 16 exigée sur Google Play depuis le 31 août 2026 et la vérification des développeurs, qui s’étend en 2027. Android 17 (API 37) est déjà disponible pour les développeurs : intégrez ses changements de comportement dans votre plan de maintenance avant que Google Play ne l’impose.

Tester la sécurité d’une application Android

Aucun logiciel n’est infaillible. La bonne nouvelle est que la plupart des failles se détectent avant la mise en production, à condition de les chercher. Trois niveaux de contrôle se complètent : l’analyse automatique du code et des dépendances à chaque build, la revue de code sur les fonctions sensibles, et un test d’intrusion mobile avant chaque version majeure.

Un pentest d’application mobile mené selon l’OWASP MASTG coûte en général entre 3 500 et 12 000 € HT selon le nombre d’écrans, les API testées et la profondeur demandée. Le détail des prix par type de test est dans notre guide sur le coût d’un test d’intrusion en France. Fourchettes indicatives de marché, hors TVA. Le prix ferme figure dans la proposition de l’entreprise que vous retenez.

Chez Yeeply, nous travaillons avec des entreprises certifiées spécialisées en développement d’applications Android et iOS, qui intègrent ces contrôles dès la conception et peuvent faire auditer l’application avant sa sortie. Pour recevoir une proposition, cliquez sur « Recevoir un devis » en haut à droite de la page ou écrivez-nous à sales@yeeply.com.