Une application mobile d'entreprise transporte dans la poche de vos équipes des données clients, des tarifs, des accès à votre système d'information. La sécurité application mobile ne se résume donc pas à un mot de passe à la connexion : elle se joue dans le stockage sur le téléphone, dans les échanges avec le serveur et dans ce qui se passe quand un appareil est perdu. Voici les sept contrôles que nous vérifions chez Pulsar Forge avant de mettre une application entre les mains de vos collaborateurs.

Pourquoi la sécurité d'une application mobile est un sujet à part

Un site web vit sur un serveur que vous maîtrisez. Une application mobile, elle, s'exécute sur des appareils que vous ne contrôlez qu'en partie : téléphones personnels, versions de système variées, réseaux Wi-Fi publics, appareils oubliés dans un train. Le code de l'application est lui-même distribué : n'importe qui peut récupérer le fichier installé et l'analyser.

Conséquence directe : tout ce qui est embarqué dans l'application doit être considéré comme lisible par un tiers motivé. Les défenses sérieuses se placent donc côté serveur, et l'application se contente de ne rien exposer d'inutile.

Les deux référentiels à connaître : OWASP Mobile Top 10 et MASVS

La fondation OWASP publie deux documents de référence, gratuits et largement utilisés par les auditeurs.

  • Le Mobile Top 10, dont la version finale 2024 classe les dix risques les plus fréquents. Le premier rang revient désormais à la mauvaise gestion des identifiants (mots de passe, jetons, clés d'API codés en dur ou mal protégés), suivi de la sécurité insuffisante de la chaîne d'approvisionnement, c'est-à-dire des bibliothèques tierces intégrées à l'application.
  • Le MASVS (Mobile Application Security Verification Standard), organisé en huit familles de contrôles : stockage, cryptographie, authentification, réseau, interaction avec la plateforme, qualité du code, résistance à l'analyse et vie privée. Son guide de test associé, le MASTG, décrit comment vérifier chaque point.

Pour une PME, inutile de viser l'exhaustivité dès le premier jour. Ces référentiels servent surtout de langage commun avec votre prestataire et, le cas échéant, avec l'auditeur qui fera un pentest application mobile.

Les 7 contrôles essentiels pour une application d'entreprise

1. Aucun secret dans le code

Une clé d'API, un mot de passe de base de données ou un identifiant de service glissé dans le code finira tôt ou tard par être extrait. L'application doit obtenir des jetons temporaires auprès de votre serveur, après authentification de l'utilisateur, et jamais porter de secret permanent.

2. Un stockage local réduit et chiffré

Ne conservez sur le téléphone que ce dont l'utilisateur a besoin, y compris pour le travail hors connexion. Les éléments sensibles (jetons de session, clés) vont dans les coffres prévus par le système : Keychain sur iOS, Keystore sur Android. Les fichiers et bases locales contenant des données clients doivent être chiffrés et purgés dès qu'ils ne servent plus.

3. Des échanges réseau verrouillés

Toutes les communications passent en HTTPS, sans exception pour les environnements de test oubliés en production. Pour les applications les plus exposées, l'épinglage de certificat empêche une interception sur un réseau Wi-Fi piégé, au prix d'une gestion rigoureuse du renouvellement.

4. Une authentification adaptée au terrain

Vos techniciens ne saisiront pas un mot de passe de seize caractères vingt fois par jour. L'authentification biométrique (empreinte, visage) déverrouille un jeton conservé dans le coffre de l'appareil : la sécurité reste forte, la friction disparaît. Prévoyez aussi l'expiration des sessions et la reconnexion après une inactivité prolongée.

5. Des droits vérifiés côté serveur

Masquer un bouton dans l'application ne protège rien. Chaque requête doit être contrôlée par le serveur : cet utilisateur a-t-il le droit de voir ce client, de valider cette commande ? C'est le prolongement mobile de la gestion des droits d'accès de toute application métier sur mesure.

6. Des bibliothèques tierces suivies

Une application mobile embarque souvent des dizaines de composants externes : cartographie, statistiques, paiement, notifications. Tenez-en l'inventaire, mettez-les à jour régulièrement et méfiez-vous des kits de statistiques qui collectent plus de données que nécessaire, ce qui pose aussi une question de conformité au RGPD.

7. Un plan pour l'appareil perdu

Un téléphone disparaît : que se passe-t-il ? Il faut pouvoir révoquer à distance les sessions de l'utilisateur côté serveur et, si les appareils sont gérés par un outil de gestion de flotte, effacer les données de l'application. Ce scénario doit être écrit et testé avant le premier incident, pas pendant.

Quel niveau d'effort selon votre application ?

Toutes les applications n'appellent pas le même investissement. Une application de consultation de catalogue sans données personnelles se contente des contrôles de base. Une application qui manipule des données de santé, des informations bancaires ou des accès à votre ERP justifie un niveau supérieur : résistance à l'analyse du code, détection des appareils modifiés, audit application mobile par un tiers avant la mise en production.

La bonne approche consiste à classer les données traitées dès le cahier des charges, puis à choisir les contrôles en conséquence. La sécurité se conçoit au départ : l'ajouter après coup coûte nettement plus cher.

Les erreurs que nous rencontrons le plus souvent

  • Faire confiance à l'application pour appliquer les règles métier, alors que le serveur accepte toute requête bien formée.
  • Laisser des journaux de débogage actifs en production, qui écrivent jetons ou données clients dans les logs de l'appareil.
  • Oublier les captures d'écran et l'aperçu dans le sélecteur d'applications, qui peuvent exposer des informations sensibles.
  • Ne jamais révoquer les accès des collaborateurs partis, dont l'application reste connectée.
  • Tester uniquement le parcours nominal, sans jamais essayer de contourner l'application avec des requêtes modifiées.

Questions fréquentes

Faut-il obligatoirement faire un pentest de son application mobile ?

Ce n'est pas une obligation légale générale, mais c'est fortement recommandé dès que l'application traite des données personnelles sensibles ou donne accès à votre système d'information. Un test d'intrusion avant la mise en production révèle les failles que les tests fonctionnels ne voient pas.

Une application interne, non publiée sur les stores, est-elle moins exposée ?

Elle est moins visible, mais pas moins vulnérable. Le fichier d'installation circule, les téléphones se perdent et les échanges réseau restent interceptables. Les mêmes contrôles s'appliquent.

L'authentification biométrique est-elle suffisante ?

Elle est excellente pour déverrouiller l'accès au quotidien, à condition de reposer sur un jeton stocké dans le coffre sécurisé de l'appareil et contrôlé par le serveur. Une première connexion forte, par exemple via l'authentification unique de l'entreprise, reste nécessaire.

Que sont l'OWASP Mobile Top 10 et le MASVS ?

Ce sont deux référentiels gratuits de la fondation OWASP. Le Mobile Top 10 liste les risques les plus fréquents, le MASVS détaille les exigences de sécurité à vérifier en huit familles de contrôles.

Peut-on sécuriser une application mobile existante ?

Oui, en commençant par un audit qui hiérarchise les risques. Les corrections côté serveur (droits, jetons, révocation) sont souvent rapides ; le stockage local et les bibliothèques demandent une nouvelle version de l'application.

Parlons de la sécurité de votre application

Vous lancez une application mobile pour vos équipes ou souhaitez faire vérifier celle que vous utilisez déjà ? Pulsar Forge conçoit des applications sécurisées dès le cahier des charges et vous accompagne sur l'audit des applications existantes. Parlons de votre projet.