Sécurité des applications mobiles : risques et solutions

Identifiants codés en dur, données stockées en clair, échanges mal chiffrés, SDK non maîtrisés : les risques du Mobile Top 10 de l'OWASP et les protections à activer sur iOS et Android. Avec une checklist avant publication et les recommandations de la CNIL.

La sécurité d’une application mobile repose sur un principe simple : tout ce qui est installé sur le téléphone peut être lu, modifié ou détourné par un attaquant. Les failles les plus courantes, recensées par l’OWASP dans son Mobile Top 10 de 2024, sont les identifiants mal protégés, les dépendances et SDK non maîtrisés, une authentification contrôlée côté appareil, des échanges réseau mal chiffrés et des données stockées en clair. Les solutions existent et sont documentées par Apple, Google et l’OWASP : il faut les prévoir dès la conception, pas après la mise en ligne.

On détaille les risques un par un, avec pour chacun ce qu’il faut faire concrètement sur iOS et Android, puis une checklist à vérifier avant publication et les obligations côté vie privée rappelées par la CNIL. L’objectif : vous permettre de poser les bonnes questions à votre prestataire, ou de relire votre propre projet.

Pourquoi la sécurité mobile est-elle un sujet à part ?
Quels sont les 10 principaux risques selon l’OWASP ?
Comment bien utiliser les protections d’iOS et d’Android ?
Comment protéger les données stockées sur le téléphone ?
Comment sécuriser les échanges avec le serveur ?
Pourquoi l’authentification doit-elle être vérifiée côté serveur ?
Comment limiter l’ingénierie inverse et la falsification ?
Code, dépendances, SDK : où se cachent les autres failles ?
Quelles obligations côté vie privée ?
Quelle checklist avant de publier ?
Questions fréquentes
Sources

Pourquoi la sécurité mobile est-elle un sujet à part ?

Sur un site web, l’essentiel du code sensible tourne sur votre serveur. Une application mobile, elle, est un paquet de code installé sur des milliers d’appareils que vous ne contrôlez pas. Trois conséquences :

Le code est entre les mains de l’utilisateur. N’importe qui peut télécharger l’application, la décompiler et étudier son fonctionnement.
L’appareil peut être perdu, volé, rooté ou « jailbreaké ». Les données stockées localement ne sont protégées que si vous les avez protégées.
Le mode hors ligne déplace de la logique côté client. Une application qui doit fonctionner sans connexion embarque des données et des traitements qui, sur le web, resteraient sur le serveur.

Ces contraintes valent pour les applications natives comme pour les applications hybrides. Pour comparer les approches, voyez notre article sur la différence entre application native et application web.

Quels sont les 10 principaux risques selon l’OWASP ?

L’OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif dont les référentiels servent de base à l’industrie. Sa liste Mobile Top 10 a été mise à jour en 2024, la précédente datant de 2016 :

Rang	Risque (intitulé OWASP)	En clair
M1	Improper Credential Usage	Mots de passe, clés d’API ou jetons codés en dur ou mal protégés
M2	Inadequate Supply Chain Security	Bibliothèques, SDK ou chaîne de compilation compromis ou non maîtrisés
M3	Insecure Authentication/Authorization	Contrôles d’identité ou de droits contournables
M4	Insufficient Input/Output Validation	Données entrantes non filtrées (injections, liens profonds piégés)
M5	Insecure Communication	Échanges réseau non chiffrés ou certificats mal vérifiés
M6	Inadequate Privacy Controls	Données personnelles collectées, stockées ou transmises sans nécessité
M7	Insufficient Binary Protections	Application facile à décompiler ou à modifier
M8	Security Misconfiguration	Mode débogage actif, composants exposés, permissions excessives
M9	Insecure Data Storage	Données sensibles stockées en clair sur l’appareil
M10	Insufficient Cryptography	Algorithmes faibles, clés mal gérées

Pour aller plus loin, l’OWASP publie aussi le MASVS (Mobile Application Security Verification Standard), un référentiel d’exigences organisé en huit groupes (stockage, cryptographie, authentification, réseau, plateforme, code, résilience, vie privée), et le MASTG, son guide de tests pour Android et iOS. C’est un excellent support pour rédiger un cahier des charges ou commander un audit.

Comment bien utiliser les protections d’iOS et d’Android ?

iOS et Android fournissent des mécanismes de sécurité solides. Beaucoup de failles viennent du fait qu’ils sont ignorés ou mal utilisés, souvent par méconnaissance de la plateforme. Les points à connaître :

Sur les deux plateformes

Demander le minimum de permissions (localisation, contacts, caméra) et seulement au moment où la fonction en a besoin.
Utiliser les coffres de clés du système plutôt que d’inventer son propre stockage de secrets.
Traiter les liens profonds et les données reçues d’autres applications comme non fiables et les valider.

Sur iOS

Le trousseau (Keychain Services) est la base de données chiffrée prévue par Apple pour stocker de petits secrets : mots de passe, jetons, clés, certificats. Il protège bien à condition de choisir des attributs d’accessibilité adaptés (par exemple, rendre un élément accessible uniquement quand l’appareil est déverrouillé).

Sur Android

Google recommande d’utiliser le Keystore Android pour les clés et une bibliothèque éprouvée comme Tink pour le chiffrement. Autre point critique : les composants de l’application (activités, services, récepteurs, fournisseurs de contenu) doivent déclarer explicitement l’attribut android:exported. Un service devient exporté par défaut dès qu’on lui ajoute un filtre d’intention, et un fournisseur de contenu exporté par erreur peut exposer une base de données à n’importe quelle autre application. Enfin, si une WebView n’a pas besoin de JavaScript, ne l’activez pas.

Avant d’écrire la moindre ligne, une modélisation des menaces aide beaucoup : l’équipe liste ce qui a de la valeur dans l’application (données, paiements, accès), qui pourrait vouloir s’en prendre à elle et par où. Ce travail oriente ensuite les choix techniques et les tests.

Comment protéger les données stockées sur le téléphone ?

C’est le risque M9 de l’OWASP et l’un des plus fréquents, en particulier pour les applications qui fonctionnent hors ligne. Si un téléphone sans code de verrouillage est perdu, ou si l’appareil est compromis, tout ce qui est stocké en clair est lisible. Les règles de base :

Ne stocker que ce qui est nécessaire. La donnée la mieux protégée est celle qui n’est pas sur l’appareil.
Utiliser le stockage interne de l’application. Sur Android, les fichiers créés dans le stockage interne ne sont accessibles qu’à l’application par défaut ; le stockage externe est lisible par d’autres applications et ne doit contenir aucune donnée sensible.
Chiffrer les bases locales qui contiennent des informations personnelles, avec des clés gardées dans le trousseau ou le Keystore.
Surveiller les fuites indirectes : journaux de débogage, captures d’écran automatiques dans le sélecteur d’applications, presse-papiers, cache des WebView. Google rappelle qu’une journalisation maladroite peut divulguer des données utilisateur.

Comment sécuriser les échanges avec le serveur ?

Les téléphones se connectent souvent à des réseaux Wi-Fi publics : toute donnée non chiffrée peut être interceptée ou modifiée en chemin. La règle est donc le chiffrement systématique, sans exception « parce que cette donnée n’est pas importante ».

Sur iOS, App Transport Security (ATS) est actif par défaut pour les applications compilées avec le SDK iOS 9 ou ultérieur : il exige notamment TLS 1.2 minimum et bloque les connexions qui ne respectent pas ces exigences. Apple recommande de corriger le serveur plutôt que d’ajouter des exceptions, dont certaines doivent être justifiées lors de la soumission sur l’App Store.
Sur Android, le trafic en clair (HTTP) est désactivé par défaut depuis Android 9. La configuration de sécurité réseau (Network Security Config) permet de préciser les règles par domaine.
Épingler le certificat (certificate pinning) renforce la protection contre les interceptions, mais demande une vraie procédure de renouvellement : un certificat épinglé qui expire sans mise à jour de l’application coupe la connexion de tous vos utilisateurs.
Ne pas compter sur une clé symétrique codée en dur comme unique protection : elle se retrouve en quelques minutes dans le code décompilé.

Pourquoi l’authentification doit-elle être vérifiée côté serveur ?

Une application qui décide seule, sur le téléphone, si l’utilisateur a le droit d’accéder à une fonction peut être modifiée pour répondre « oui » à tous les coups. C’est le cœur du risque M3. La règle : l’application affiche, le serveur décide. Chaque appel à votre API doit vérifier l’identité (jeton valide, non expiré) et les droits de l’utilisateur sur la ressource demandée.

Côté identifiants (risque M1), aucun secret ne doit être intégré en dur dans le code : clés d’API privées, mots de passe de service, jetons d’administration. Google recommande de ne jamais les versionner dans le dépôt de code source. Pour la connexion des utilisateurs, s’appuyer sur un fournisseur d’identité éprouvé est souvent plus sûr que de tout développer ; notre article sur l’authentification unique (SSO) explique le principe.

Comment limiter l’ingénierie inverse et la falsification ?

Avec des outils de décompilation, un attaquant peut lire le code d’une application, comprendre sa logique, puis en publier une version modifiée (fonctions premium débloquées, contrôles supprimés). On ne peut pas l’empêcher totalement, mais on peut le rendre coûteux et surtout détectable :

Obscurcir et réduire le code. Sur Android, l’outil R8 intégré à la chaîne de compilation assure la réduction, l’optimisation et l’obscurcissement (renommage des classes et méthodes) en version de production. L’obscurcissement ralentit l’analyse, il ne protège pas un secret.
Vérifier l’intégrité de l’application côté serveur. L’API Play Integrity de Google permet à votre serveur de vérifier que la requête vient de votre binaire non modifié, installé depuis Google Play, sur un appareil Android certifié. Côté Apple, le service App Attest du framework DeviceCheck joue un rôle comparable.
Garder la logique critique sur le serveur : calcul d’un prix, validation d’un paiement, attribution de droits.

Code, dépendances, SDK : où se cachent les autres failles ?

Une application moderne embarque des dizaines de bibliothèques tierces et de SDK (mesure d’audience, publicité, paiement, notifications). Chacun est une porte d’entrée potentielle, c’est le risque M2 sur la chaîne d’approvisionnement. Quelques réflexes :

tenir un inventaire des dépendances et les mettre à jour régulièrement ;
n’intégrer un SDK que si son éditeur est identifié et sa collecte de données comprise ;
publier en mode « release » et jamais en mode débogage, avec une application signée par un certificat dont la clé est conservée en lieu sûr ;
intégrer des tests de sécurité dans le cycle de développement plutôt qu’en fin de projet, selon l’approche DevSecOps ;
s’appuyer sur les pratiques de codage sécurisé de l’OWASP et faire relire le code sensible par une seconde personne.

Le serveur mérite la même attention : une application mobile sûre qui parle à une API vulnérable reste vulnérable. Les principes sont détaillés dans notre article sur la sécurité des applications web.

Quelles obligations côté vie privée ?

En France, la sécurité des données personnelles est aussi une obligation légale au titre du RGPD. La CNIL a publié le 24 septembre 2024 des recommandations dédiées aux applications mobiles (mises à jour le 8 avril 2025), qui s’adressent à tous les acteurs : éditeurs, développeurs, fournisseurs de SDK, de systèmes d’exploitation et de magasins d’applications. Elle a annoncé une campagne de contrôles spécifique à partir de 2025.

Concrètement, cela rejoint le risque M6 de l’OWASP : collecter le minimum, expliquer clairement à quoi servent les permissions, recueillir le consentement quand il est requis (notamment pour les traceurs publicitaires) et savoir précisément quelles données vos SDK transmettent.

Quelle checklist avant de publier ?

Aucun secret (clé d’API privée, mot de passe) dans le code ni dans le dépôt.
Toutes les communications en HTTPS, sans exception ATS ou Network Security Config injustifiée.
Données sensibles chiffrées, clés dans le trousseau iOS ou le Keystore Android.
Authentification et droits vérifiés sur le serveur à chaque appel.
Composants Android déclarés avec android:exported explicite, permissions réduites au minimum.
Build de production signé, sans mode débogage ni journaux verbeux, code réduit et obscurci.
Dépendances et SDK à jour et inventoriés.
Vérification d’intégrité (Play Integrity, App Attest) sur les actions sensibles.
Politique de confidentialité à jour et consentement recueilli quand il est nécessaire.
Tests de sécurité réalisés, idéalement en s’appuyant sur le MASVS.

Vous préparez une application et voulez que ces points figurent dans le projet dès le départ ? On conçoit des applications web et mobiles sur mesure et on peut vous aider à cadrer les exigences de sécurité. Premier contact par e-mail à contact@osmova.com ou via le formulaire de contact.

Questions fréquentes

iOS est-il plus sûr qu’Android pour une application ?

Les deux plateformes offrent des protections sérieuses (bac à sable, coffre de clés, chiffrement réseau par défaut). La sécurité de votre application dépend surtout de la façon dont elle les utilise et de la solidité de votre serveur.

L’obscurcissement du code suffit-il à protéger une application ?

Non. Il ralentit l’analyse mais ne cache pas durablement un secret. La vraie protection consiste à ne rien laisser de sensible dans l’application et à contrôler côté serveur, éventuellement avec une vérification d’intégrité.

Une application hors ligne est-elle moins sûre ?

Elle expose davantage, car elle embarque des données et de la logique sur l’appareil. Il faut alors limiter les données en cache, les chiffrer et resynchroniser en vérifiant tout côté serveur.

Faut-il faire réaliser un audit de sécurité ?

Pour une application qui manipule des données personnelles, de santé ou des paiements, oui. Un audit basé sur le MASVS et le MASTG de l’OWASP donne un cadre reconnu et des résultats comparables d’une version à l’autre.

Une PWA a-t-elle les mêmes risques qu’une application native ?

En partie : elle hérite des risques du web (injection, sécurité de l’API) et, si elle fonctionne hors ligne, de ceux du stockage local. Notre article sur les progressive web apps détaille leur fonctionnement.

Sécurité des applications mobiles : risques courants et solutions

Pourquoi la sécurité mobile est-elle un sujet à part ?

Quels sont les 10 principaux risques selon l’OWASP ?