Sécurité application mobile : la check-list avant production

Sécuriser une application mobile d’entreprise se joue avant la mise en production, en quatre temps : cadrer les données et le RGPD, développer avec les protections du système, faire tester l’application par un tiers indépendant, puis organiser mises à jour, journalisation et plan d’incident. Rattrapée au dernier sprint, la sécurité coûte toujours plus cher.

Phase 1 : cadrer avant la première ligne de code

La plupart des failles d’une application se décident en réunion de lancement, quand personne ne pose la question des données. La sécurité application mobile commence donc par un inventaire, pas par un outil.

• Lister les données que l’application manipule : personnelles, sensibles, secrets commerciaux, accès au système d’information interne.
• Supprimer celles qui ne servent pas. L’article 25 du règlement général sur la protection des données impose la protection des données dès la conception et par défaut.
• Classer l’application selon son exposition : un catalogue interne n’appelle pas les mêmes exigences qu’une application de paiement ou de gestion de dossiers clients.
• Limiter les autorisations demandées au téléphone (localisation, contacts, appareil photo) à celles qui servent une fonction réelle.
• Écrire ces exigences dans le cahier des charges de l’application, au même titre que les fonctionnalités, pour qu’elles entrent dans le devis et dans la recette.

Pour fixer le niveau d’exigence, le référentiel communautaire OWASP MASVS décrit ce qu’une application mobile doit vérifier en matière de stockage, de cryptographie, d’authentification, de réseau et de résistance à l’analyse. La CNIL a publié de son côté, le 24 septembre 2024, une recommandation sur les applications mobiles, mise à jour le 8 avril 2025, qui détaille les obligations de chaque acteur, éditeur en tête.

Phase 2 : développer avec les protections du système

Le choix de la technologie, natif ou hybride, se fait sur le projet ; il est détaillé dans notre article sur les méthodes et budgets de développement d’une application mobile. Quelle que soit l’option retenue, les mêmes points reviennent.

• Authentification : aucun mot de passe stocké en clair sur l’appareil, des jetons de session à durée courte, révocables côté serveur, et la biométrie utilisée via les interfaces fournies par le système.
• Stockage local : les secrets dans le coffre de clés du système, les données sensibles chiffrées, rien de confidentiel dans les journaux, les caches ou les aperçus d’écran.
• Communications : chiffrement de bout en bout du trafic, sans exception de confort laissée pour la recette.
• API : chaque requête vérifiée côté serveur, droits contrôlés objet par objet, limitation du nombre d’appels. Le serveur ne fait jamais confiance à ce que l’application lui envoie.
• Secrets de développement : aucune clé d’API sensible embarquée dans l’application, qui peut être décompilée par n’importe quel curieux.
• Dépendances : un inventaire des bibliothèques et des kits tiers, avec une vérification automatique des vulnérabilités connues à chaque version.

Le point le plus souvent négligé reste l’API. Une application parfaitement verrouillée qui interroge un serveur permissif offre à l’attaquant un chemin plus simple que l’application elle-même.

Phase 3 : faire tester l’application par un regard extérieur

L’équipe qui a écrit le code est la moins bien placée pour en trouver les failles : elle connaît le chemin prévu et teste rarement les autres. L’audit indépendant se confie donc à un prestataire extérieur spécialisé en tests d’intrusion, ou à un cabinet de conseil et d’audit en cybersécurité comme Ad Confirma, basé près de Lyon, qui organise ce type de test avec des partenaires et le rattache à une démarche plus large de gestion des risques. Le rapport sert alors autant à corriger qu’à décider ce qui peut partir en production.

Avant ce test d’intrusion, deux vérifications internes dégrossissent le travail :

• une revue de code centrée sur la sécurité, menée par un développeur qui n’a pas écrit la partie relue ;
• une analyse automatique du code et des dépendances, rejouée à chaque version.

Le test lui-même se prépare comme une mission. Une convention fixe le périmètre (application, API, interface d’administration), les comptes de test, les dates et les techniques autorisées. Le testeur examine l’application installée, ce qu’elle laisse sur l’appareil, ce qu’elle échange avec le serveur et la solidité de la logique métier : un utilisateur peut-il consulter le dossier d’un autre client en modifiant un identifiant, contourner une étape de validation, rejouer une requête de paiement ?

Le livrable attendu est un rapport qui classe chaque vulnérabilité par gravité, la démontre et propose une correction. Prévoyez dès le départ une seconde passe, plus courte, pour vérifier que les corrections ont réellement fermé les failles. Un rapport sans contre-vérification ne prouve que l’existence des problèmes.

Trois approches coexistent, et le choix se fait selon ce que vous voulez apprendre. En boîte noire, le testeur part de l’application publiée, comme un attaquant extérieur, sans documentation. En boîte grise, il dispose de comptes de différents niveaux et d’une description de l’API, ce qui lui permet de tester les droits de chaque profil en profondeur. En boîte blanche, il accède au code source et à l’architecture. Pour un premier audit de sécurité d’application métier, la boîte grise offre en général le meilleur rapport entre temps passé et failles trouvées, parce qu’elle concentre l’effort sur la logique d’autorisation, là où se cachent les défauts les plus graves.

Côté entreprise, la préparation compte autant que le test. Un environnement de recette fidèle à la production, alimenté par des données fictives, évite de mettre en jeu de vraies informations clients. Une personne joignable pendant la mission débloque les questions du testeur en quelques minutes plutôt qu’en quelques jours. Et une plage réservée dans le planning de l’équipe de développement permet de corriger avant la date de lancement, au lieu de publier en connaissance de cause une version vulnérable.

Phase 4 : exploiter sans baisser la garde

La mise en production ouvre une période plus longue que le développement. Quatre sujets la structurent.

Les mises à jour d’abord. Les bibliothèques publient des correctifs, les systèmes des téléphones évoluent, et une application figée vieillit mal. Prévoyez un mécanisme qui impose une version minimale lorsqu’une faille grave est corrigée. Fixez aussi la liste des versions de système que l’application accepte encore : un téléphone qui ne reçoit plus de correctifs de son constructeur devient un point faible que l’application ne compensera jamais entièrement.

La journalisation ensuite, côté serveur : connexions, échecs d’authentification, actions sensibles, avec une durée de conservation définie et sans collecter plus de données personnelles que nécessaire. Des journaux que personne ne lit ne servent qu’après coup ; quelques alertes simples, comme une série d’échecs de connexion sur un même compte ou un volume anormal de téléchargements, transforment ces traces en signal exploitable.

Le plan d’incident, surtout. Qui peut retirer une version des magasins d’applications, révoquer tous les jetons de session, prévenir les utilisateurs ? En cas de violation de données personnelles, la notification à la CNIL doit intervenir dans les 72 heures prévues par l’article 33 du règlement général sur la protection des données, sauf absence de risque pour les personnes. Ces décisions se préparent à froid.

La gestion de la flotte enfin, pour les applications internes distribuées aux salariés : terminaux inscrits dans un outil de gestion des mobiles, possibilité d’effacer les données professionnelles d’un appareil perdu, rappel régulier des réflexes de base, comme ceux de notre article sur les réflexes pour protéger ses données.

Les erreurs qui annulent la check-list

Certaines décisions défont en une ligne le travail de plusieurs semaines.

• Repousser la sécurité « après la version 1 », qui devient la version de production pour deux ans.
• Tester l’application sans tester l’API qu’elle appelle.
• Laisser un environnement de recette accessible depuis internet avec des données réelles.
• Ajouter un kit d’analyse ou de publicité sans examiner ce qu’il collecte.
• Conserver des comptes de test aux droits d’administrateur après la mise en ligne.
• Confier la publication dans les magasins d’applications à un compte personnel de développeur, que l’entreprise ne contrôle plus le jour où ce développeur part.
• Désactiver la vérification des certificats pour faciliter la recette, puis oublier de la réactiver.

Aucune de ces erreurs n’est technique au sens strict. Toutes relèvent d’un arbitrage de calendrier ou de budget pris sans voir le risque. C’est pourquoi la check-list doit être relue par la personne qui arbitre le calendrier, pas seulement par l’équipe qui code : c’est elle qui décidera, sous pression, de publier ou d’attendre.

Qui porte la sécurité dans le projet

Dans une PME, trois acteurs se partagent la responsabilité, et chacun doit la connaître par écrit.

Le commanditaire fixe le niveau d’exigence et arbitre les risques résiduels. Le prestataire de développement s’engage contractuellement sur la correction des vulnérabilités découvertes, la remise du code source et la documentation. Le testeur indépendant vérifie, sans avoir participé à la construction. Si l’application traite des données personnelles, le référent chargé de la protection des données valide les choix de collecte et de conservation.

Le contrat de développement mérite une relecture sous cet angle. Trois clauses changent tout le jour d’un incident : l’obligation de corriger les vulnérabilités découvertes pendant une durée définie après la livraison, la remise du code source et des accès aux comptes de publication, et l’engagement de signaler sans délai toute faille connue dans les composants utilisés. Sans elles, l’entreprise découvre qu’elle possède une application mobile d’entreprise qu’elle ne peut ni corriger seule ni faire corriger rapidement.

Reste le budget. Vouloir sécuriser une application après coup coûte plus cher que de l’avoir prévu, parce que chaque correction tardive oblige à retoucher un code déjà testé et publié. Réserver dès le chiffrage initial une ligne pour la revue de sécurité, le test indépendant et sa contre-vérification évite le choix, toujours mauvais, entre la date de lancement et la sécurité.

La même logique vaut pour une application web installable : une progressive web app hérite des contraintes du web et de ses propres points d’attention, présentés dans notre article sur la progressive web app en entreprise. L’accessibilité, autre exigence non fonctionnelle, gagne à être écrite dans le même cahier des charges, selon les règles d’accessibilité numérique d’une application.

Prochaine étape

Reprenez le cahier des charges de votre application et ajoutez-y une page intitulée « exigences de sécurité », organisée selon ces quatre phases. Ce qui n’y figure pas ne sera ni chiffré, ni développé, ni testé.