Une application mobile manipule aujourd’hui des données que peu d’autres canaux numériques concentrent au même endroit : identité, moyens de paiement, géolocalisation, historique de santé ou d’achat, parfois données biométriques. Cette concentration en fait une cible de choix pour les attaquants, alors même que le terminal sur lequel elle s’exécute échappe largement au contrôle de l’entreprise qui l’édite. Contrairement à un serveur hébergé en interne, un smartphone peut être perdu, volé, rooté ou jailbreaké, connecté à un réseau public non sécurisé, ou analysé statiquement par quiconque récupère le binaire publié sur un store. Sécuriser une application mobile ne relève donc pas d’une simple case à cocher en fin de projet, mais d’une discipline à intégrer dès la conception. Depuis 2012, Aventique conçoit et développe des applications mobiles pour des clients aux exigences de sécurité élevées — dont Sephora, Thales ou Audi — ce qui nourrit une approche exigeante et outillée de ces sujets, détaillée dans cet article.

Pourquoi la sécurité mobile est un enjeu stratégique

Les conséquences d’une faille de sécurité mobile dépassent largement le seul incident technique. Une fuite de données personnelles expose l’entreprise à des sanctions au titre du RGPD, dont l’amende peut atteindre plusieurs pourcents du chiffre d’affaires mondial selon la gravité du manquement constaté par la CNIL ou son équivalent européen. Au-delà de la sanction pécuniaire, c’est la confiance des utilisateurs qui est en jeu : une application compromise, relayée dans la presse ou sur les réseaux sociaux, subit une perte de crédibilité difficile à reconstruire, en particulier pour des marques grand public où la réputation constitue un actif central.

L’enjeu est également contractuel et commercial. De nombreux appels d’offres, notamment dans les secteurs bancaire, industriel ou de la santé, imposent désormais des exigences de sécurité précises — audits de code, certification, conformité à des référentiels comme l’OWASP MASVS — comme prérequis à la signature. Une application mal sécurisée dès l’origine engendre en outre des coûts de remédiation bien supérieurs à ceux d’une prise en compte native du sujet : corriger une faille d’architecture après mise en production impose souvent de revoir des pans entiers du code, alors qu’un choix de conception initial coûte proportionnellement peu.

Les grandes familles de risques : comprendre l’OWASP Mobile Top 10

L’OWASP (Open Web Application Security Project) publie un référentiel des risques les plus fréquents sur mobile, régulièrement mis à jour, qui sert de base commune à la plupart des audits de sécurité. Il structure utilement la réflexion en distinguant plusieurs familles de vulnérabilités récurrentes.

Le stockage non sécurisé des données arrive systématiquement en tête : tokens, identifiants ou données personnelles enregistrés en clair dans des fichiers locaux, des bases SQLite non chiffrées ou les logs système, accessibles à quiconque a un accès physique ou logique à l’appareil. Les communications réseau non chiffrées ou mal validées constituent un deuxième risque majeur, exposant les échanges à l’interception. L’authentification faible — mots de passe stockés côté client, absence de limitation des tentatives, sessions qui n’expirent jamais — permet à un attaquant d’usurper une identité sans grand effort. Le reverse engineering, facilité par la nature même des applications mobiles distribuées en binaire sur le terminal de l’utilisateur, permet d’extraire la logique métier, des clés d’API ou des secrets embarqués par erreur. Enfin, les injections côté client et l’usage de composants tiers vulnérables ou obsolètes complètent ce panorama de risques qu’une démarche de sécurisation doit couvrir méthodiquement.

Sécuriser le stockage des données sur l’appareil

La règle de base consiste à ne jamais stocker en clair une donnée sensible sur le terminal. iOS et Android proposent chacun un mécanisme dédié à cet effet : le Keychain sur iOS et le Keystore sur Android permettent de stocker des identifiants, tokens ou clés cryptographiques dans un espace protégé par le système d’exploitation, isolé des autres applications et généralement adossé à une puce sécurisée matérielle (Secure Enclave sur iOS, TEE ou StrongBox sur Android selon les modèles). Ces mécanismes doivent être systématiquement privilégiés aux préférences partagées (SharedPreferences) ou aux fichiers texte, qui n’offrent aucune protection réelle.

Pour les données qui, par nécessité fonctionnelle, doivent être persistées localement en base (mode hors ligne, cache applicatif), un chiffrement au repos s’impose, avec des bibliothèques éprouvées plutôt qu’une implémentation cryptographique maison — SQLCipher pour les bases SQLite chiffrées, par exemple. Il convient également de limiter la durée de vie des données locales au strict nécessaire, de purger les caches sensibles lors de la déconnexion de l’utilisateur, et de porter une attention particulière aux captures d’écran automatiques du système (aperçu multitâche) qui peuvent exposer des informations sensibles affichées à l’écran au moment de la mise en arrière-plan.

Protéger les communications réseau

Toute application mobile échange en permanence avec un ou plusieurs backends, et ce canal doit être protégé de bout en bout. L’usage exclusif de HTTPS avec TLS constitue un prérequis non négociable : aucun échange sensible ne doit transiter en clair, y compris pour des appels internes ou de télémétrie apparemment anodins. Il est également recommandé de désactiver explicitement les versions obsolètes de TLS et les suites de chiffrement faibles côté serveur, afin de fermer la porte aux attaques par rétrogradation de protocole.

Le certificate pinning constitue une protection complémentaire précieuse contre les attaques de type man-in-the-middle, y compris lorsque l’attaquant est parvenu à installer un certificat racine frauduleux sur l’appareil — un scénario réaliste sur un terminal compromis ou dans certains contextes d’entreprise avec proxy d’inspection. Le pinning consiste à faire vérifier par l’application elle-même que le certificat ou la clé publique présentée par le serveur correspond à une valeur attendue, codée ou distribuée de façon sécurisée, plutôt que de se reposer uniquement sur la chaîne de confiance du système. Cette pratique doit toutefois être mise en œuvre avec un mécanisme de mise à jour des certificats pinnés, sous peine de bloquer l’application entière lors d’un renouvellement de certificat côté serveur.

Mettre en place une authentification robuste

L’authentification est souvent le maillon le plus exposé d’une application mobile, car elle constitue la porte d’entrée vers l’ensemble des données et fonctionnalités du compte utilisateur. Les standards ouverts et éprouvés comme OAuth2 et OpenID Connect doivent être privilégiés à des implémentations propriétaires, car ils bénéficient d’un examen de sécurité continu par la communauté et d’un écosystème d’outils matures.

La biométrie (Face ID, Touch ID, empreinte digitale sur Android) apporte un niveau de confort et de sécurité appréciable en complément — jamais en remplacement pur et simple — d’une authentification serveur, en s’appuyant sur les API natives sécurisées de chaque plateforme plutôt que sur une implémentation custom. La gestion des tokens mérite une attention particulière : un token d’accès doit avoir une durée de vie courte, être renouvelé via un refresh token stocké de façon sécurisée, et être révocable côté serveur en cas de compromission suspectée ou de déconnexion explicite. Un token qui n’expire jamais, ou un refresh token stocké sans protection, annule une grande partie des efforts de sécurisation par ailleurs.

Se prémunir contre le reverse engineering

Un binaire mobile distribué publiquement peut être décompilé, désassemblé et analysé par quiconque dispose des outils adéquats — largement accessibles gratuitement. Cette réalité impose de ne jamais considérer le code côté client comme un secret en soi, mais de mettre en œuvre des mesures qui compliquent significativement cette analyse et retardent, sans prétendre l’empêcher totalement, l’extraction de logique sensible.

Sur Android, des outils comme ProGuard ou son successeur R8 permettent d’obfusquer et de minifier le code au moment de la compilation, rendant la décompilation nettement plus ardue à exploiter. Sur iOS, des techniques d’obfuscation de symboles et de chaînes de caractères jouent un rôle comparable. Pour les applications manipulant des données particulièrement sensibles, une détection de l’état root (Android) ou jailbreak (iOS) de l’appareil permet d’adapter le comportement de l’application — restriction de certaines fonctionnalités, avertissement à l’utilisateur — dès lors que l’intégrité du système d’exploitation ne peut plus être garantie.

Gérer les secrets, sécuriser le backend et maintenir les dépendances

Une erreur fréquente, y compris dans des équipes expérimentées, consiste à coder en dur des clés d’API ou des secrets directement dans le binaire de l’application. Or un secret embarqué dans le code, aussi obfusqué soit-il, finit statistiquement par être extrait. La bonne pratique consiste à ne jamais exposer de secret nécessitant une confidentialité forte côté client : les appels qui en ont besoin doivent transiter par un backend qui détient et protège ces secrets, l’application mobile se contentant d’appeler des endpoints authentifiés.

Cette logique rappelle une évidence souvent sous-estimée : la sécurité d’une application mobile ne se limite jamais au client. Le backend consommé par l’application doit appliquer les mêmes exigences que n’importe quelle API exposée — validation stricte des entrées, autorisation systématique à chaque appel plutôt qu’une confiance implicite dans le client, limitation du débit pour prévenir les abus. Enfin, les bibliothèques et frameworks tiers intégrés à l’application doivent faire l’objet d’une veille et d’une mise à jour régulières : une dépendance obsolète comportant une vulnérabilité connue est l’une des portes d’entrée les plus exploitées, précisément parce qu’elle est publiquement documentée.

Tester, auditer et sensibiliser les équipes

Aucune de ces pratiques n’a de valeur durable sans un dispositif de vérification continue. Les tests de pénétration mobile, réalisés par des experts en sécurité indépendants de l’équipe de développement, permettent de challenger l’application dans des conditions proches de celles d’un attaquant réel et de détecter des failles qu’une revue de code seule ne révèle pas toujours. Ces audits gagnent à être menés à intervalles réguliers, et systématiquement avant toute mise en production d’une fonctionnalité sensible (paiement, gestion d’identité, données de santé).

La sécurité reste enfin, avant tout, une affaire humaine. Sensibiliser les équipes de développement aux réflexes de base — revue de code orientée sécurité, connaissance des pièges classiques de l’OWASP, culture du moindre privilège — réduit fortement l’apparition de vulnérabilités en amont, à un coût sans commune mesure avec celui d’une correction en production.

Comment Aventique intègre la sécurité dès la conception des projets mobiles

Chez Aventique, la sécurité n’est pas traitée comme une étape de fin de chaîne, mais comme un critère de conception au même titre que l’expérience utilisateur ou la performance. Sur les projets mobiles réalisés pour des clients aux exigences élevées — retail, industrie, finance — les équipes appliquent systématiquement les standards natifs de stockage sécurisé (Keychain, Keystore), imposent HTTPS/TLS sur l’ensemble des échanges et évaluent au cas par cas la pertinence du certificate pinning selon la sensibilité des données manipulées.

L’architecture applicative est pensée pour que les secrets et la logique métier critique restent côté serveur, avec des API authentifiées et autorisées à chaque appel. Sur les projets impliquant des données personnelles ou de santé, une attention particulière est portée à la conformité RGPD dès les spécifications, en amont du développement. Grâce à son organisation combinant équipes en France et réseau nearshore au Maghreb, Aventique peut mobiliser rapidement des profils spécialisés en sécurité applicative pour renforcer un projet en cours ou réaliser un audit ponctuel, sans les délais d’un recrutement classique.

Questions fréquentes

Le certificate pinning est-il indispensable pour toute application mobile ?

Non, il est surtout recommandé pour les applications manipulant des données très sensibles (paiement, santé, identité). Pour une application moins critique, un TLS correctement configuré peut suffire, le pinning ajoutant une complexité de maintenance à mettre en balance avec le niveau de risque réel.

Faut-il chiffrer toutes les données stockées localement sur l’appareil ?

Toute donnée sensible ou personnelle doit être protégée, via le Keychain/Keystore ou un chiffrement dédié. Les données non sensibles, purement fonctionnelles, n’exigent pas nécessairement ce niveau de protection, mais une revue au cas par cas reste préférable à une règle générale non vérifiée.

L’obfuscation du code rend-elle une application inviolable ?

Non. L’obfuscation ralentit et complique significativement le reverse engineering, mais ne le rend pas impossible. Elle doit être combinée à d’autres mesures — pas de secrets côté client, backend sécurisé — plutôt que considérée comme une protection suffisante à elle seule.

Quelle est la différence entre authentification biométrique et authentification serveur ?

La biométrie authentifie l’utilisateur auprès de l’appareil localement ; elle ne remplace pas une authentification côté serveur qui vérifie l’identité et les droits associés au compte. Les deux mécanismes sont complémentaires, la biométrie servant souvent à déverrouiller un token déjà émis par le serveur.

À quelle fréquence faut-il réaliser un test de pénétration mobile ?

Une bonne pratique consiste à en réaliser un avant chaque mise en production majeure impliquant des fonctionnalités sensibles, puis à intervalles réguliers (annuel a minima) pour couvrir l’évolution du code et des menaces.

Le RGPD s’applique-t-il différemment aux applications mobiles qu’aux sites web ?

Les principes du RGPD sont les mêmes, mais leur mise en œuvre technique diffère : consentement pour les accès aux capteurs (localisation, appareil photo), gestion des identifiants publicitaires, et sécurisation du stockage local, qui n’a pas d’équivalent direct côté web.

Comment savoir si une application existante présente des failles de sécurité critiques ?

Un audit de sécurité mobile, combinant revue de code et test de pénétration, permet d’établir un diagnostic factuel et priorisé. C’est souvent le point de départ le plus efficace avant d’engager des travaux de remédiation.

Aventique peut-elle intervenir sur une application existante, pas seulement sur un nouveau projet ?

Oui. Aventique accompagne aussi bien la conception de nouvelles applications que l’audit et le renforcement de la sécurité d’applications déjà en production, en mode projet ou par la mobilisation de consultants en régie.