Sécuriser une application mobile en entreprise : les bases non négociables

Introduction

Une application mobile d'entreprise manipule rarement des données anodines : identifiants, informations clients, parfois données de santé ou données financières. Une faille n'est donc pas seulement un incident technique — c'est un risque juridique, financier et de réputation qui peut menacer la survie d'une PME.

La bonne nouvelle : la sécurité mobile n'est pas un art mystérieux réservé aux grandes entreprises. Elle repose sur des référentiels publics et éprouvés, et sur quelques bases non négociables. Cet article présente les trois piliers d'une application mobile défendable : le OWASP Mobile Top 10, la OWASP MASVS (Mobile Application Security Verification Standard), et les obligations de conformité — Loi 25 au Québec et RGPD en Europe.

Le référentiel de base : OWASP Mobile Top 10 (2024)

L'OWASP (Open Worldwide Application Security Project) publie une liste des dix catégories de risques les plus courants pour les applications mobiles. L'édition 2024 (OWASP Mobile Top 10) sert de grille de lecture universelle, reconnue par les auditeurs et les clients grands comptes.

Les dix catégories

• M1 — Improper Credential Usage : mauvaise gestion des identifiants et des secrets.
• M2 — Inadequate Supply Chain Security : sécurité insuffisante de la chaîne d'approvisionnement (dépendances, SDK tiers, outils).
• M3 — Insecure Authentication/Authorization : authentification et autorisation défaillantes.
• M4 — Insufficient Input/Output Validation : validation insuffisante des entrées et sorties.
• M5 — Insecure Communication : communications non sécurisées.
• M6 — Inadequate Privacy Controls : contrôles de confidentialité inadéquats.
• M7 — Insufficient Binary Protections : protection insuffisante du binaire (absence d'obfuscation, de détection de manipulation).
• M8 — Security Misconfiguration : mauvaise configuration de sécurité.
• M9 — Insecure Data Storage : stockage non sécurisé des données.
• M10 — Insufficient Cryptography : cryptographie insuffisante.

Utiliser cette liste comme checklist d'architecture, dès la conception, coûte infiniment moins cher que de corriger après une fuite. Pour une PME, elle a un second mérite : elle structure le dialogue avec un client ou un auditeur qui demande « comment gérez-vous la sécurité ? ».

MASVS : le catalogue de contrôles vérifiables

Le OWASP MASVS (MASVS) va plus loin : il détaille les contrôles à mettre en place, organisés en huit groupes. C'est la référence à citer dans un cahier des charges.

• STORAGE — stockage sécurisé des données sensibles.
• CRYPTO — usage correct de la cryptographie.
• AUTH — authentification et gestion de session.
• NETWORK — sécurité des communications.
• PLATFORM — interactions sécurisées avec les API et composants de la plateforme.
• CODE — qualité et sécurité du code (injections, gestion des erreurs, secrets).
• RESILIENCE — résistance à la manipulation, au débogage et à l'ingénierie inverse.
• PRIVACY — respect de la vie privée et des données personnelles.

L'intérêt du MASVS est qu'il est vérifiable : chaque contrôle se prête à un test ou à une preuve. Une PME peut demander à son prestataire non pas « votre app est-elle sécurisée ? » (question inutile), mais « quels contrôles MASVS sont couverts, et comment le prouvez-vous ? ».

Stockage sécurisé : Keychain et Keystore

C'est la base la plus souvent mal faite. Règle simple : aucun secret en clair.

• Ne jamais stocker de jeton d'authentification, de clé API ou de mot de passe en clair dans les préférences locales (SharedPreferences sur Android, UserDefaults sur iOS) ni dans un fichier.
• Utiliser les mécanismes de stockage sécurisé fournis par l'OS : le Keychain sur iOS et le Keystore sur Android. Les clés y sont gérées par le système, et la protection matérielle (Secure Enclave côté Apple, StrongBox côté Android, quand elle est disponible) empêche leur extraction même en cas de compromission du système.
• Chiffrer les données locales sensibles, et ne jamais placer la clé de chiffrement à côté des données.
• Se souvenir que l'obfuscation n'est pas de la sécurité : cacher un secret ne le protège pas.

Ces recommandations recoupent directement les catégories M9 (Insecure Data Storage), M10 (Insufficient Cryptography) et M1 (Improper Credential Usage) du Top 10.

Authentification, réseau et code

Authentification (M3). Exiger une authentification forte (authentification multifacteur quand le contexte le justifie), des sessions à durée courte, des jetons révocables, et un mécanisme de déconnexion à distance (déconnexion côté serveur, pas seulement côté app).

Communications (M5). Tout le trafic doit passer par TLS. On ne met jamais de clé API secrète dans une application mobile : le code d'une app peut être extrait, donc tout secret embarqué doit être considéré comme public. C'est une erreur classique et coûteuse.

Code et chaîne d'approvisionnement (M2, M4, M7, M8). Verrouiller les dépendances, auditer les SDK tiers, valider toutes les entrées, signer et protéger le binaire, et durcir les configurations par défaut. La chaîne d'approvisionnement (M2) est une préoccupation montante : une bibliothèque tierce compromise peut contaminer une application par ailleurs bien écrite.

Conformité : Loi 25 (Québec) et RGPD

La sécurité technique ne suffit pas : elle doit s'articuler avec les obligations légales.

Loi 25 (Québec)

La Loi 25 (« Loi modernisant des dispositions législatives en matière de protection des renseignements personnels ») encadre le traitement des renseignements personnels au Québec. Elle impose notamment :

• la désignation d'un responsable de la protection des renseignements personnels ;
• une politique de confidentialité accessible et rédigée en termes clairs ;
• un consentement valide, manifeste, libre et éclairé, recueilli séparément pour certaines finalités ;
• la notification des incidents de confidentialité présentant un risque de préjudice sérieux, à la Commission d'accès à l'information (CAI) et aux personnes concernées ;
• les droits d'accès et de rectification, ainsi qu'un droit à la portabilité de certaines informations ;
• une évaluation des facteurs relatifs à la vie privée (EFVP) pour certains projets ;
• un encadrement de la communication de renseignements hors Québec, avec une évaluation du niveau de protection offert.

Pour une application mobile, cela se traduit directement dans le produit : écrans de consentement, politique accessible depuis l'app, gestion des demandes de suppression, et cartographie des données collectées.

RGPD (Union européenne)

Le RGPD repose sur des principes qui se transposent presque mot pour mot aux mêmes exigences : licéité, minimisation, limitation des finalités, exactitude, limitation de conservation, intégrité et confidentialité. Il ajoute des obligations structurantes — registre des traitements, analyse d'impact (AIPD/DPIA) pour les traitements à risque, encadrement des transferts hors de l'Union (clauses contractuelles types, décisions d'adéquation) — et un régime de sanctions administratives pouvant atteindre, pour les manquements les plus graves, un montant plafonné à 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu (article 83 du RGPD).

Pour une PME québécoise qui sert des clients européens, la Loi 25 et le RGPD se cumulent : la rigueur est dictée par le régime le plus exigeant applicable au traitement concerné.

Une checklist minimale non négociable

1. Aucun secret en clair : tout identifiant passe par Keychain/Keystore.
2. TLS partout, sans exception, et aucune clé secrète embarquée dans l'app.
3. Authentification forte et sessions révocables côté serveur.
4. Politique de confidentialité accessible depuis l'application.
5. Consentements recueillis, tracés et modifiables.
6. Dépendances et SDK tiers inventoriés et suivis.
7. Journalisation sans données personnelles en clair.
8. Procédure d'incident : qui notifie, à qui, dans quels délais.
9. Test de sécurité avant chaque mise en production majeure (analyse statique, tests d'intrusion selon le risque).
10. Cartographie des données : où vont les données, qui y accède, combien de temps sont-elles conservées.

Cette liste ne remplace pas un audit, mais elle sépare les projets sérieux des projets dangereux.

Conclusion

La sécurité d'une application mobile d'entreprise n'est ni un luxe ni un mystère. Elle repose sur trois socles publics : le OWASP Mobile Top 10 (2024) pour identifier les risques, la MASVS pour les contrôles vérifiables, et le stockage sécurisé natif (Keychain/Keystore) comme premier réflexe technique. À cela s'ajoute la conformité — Loi 25 au Québec et RGPD en Europe — qui transforme ces bonnes pratiques en obligations légales.

Pour une PME, l'approche rationnelle est de traiter ces bases dès la conception, pas après la première faille. Le coût d'une ligne de sécurité bien posée au départ est sans commune mesure avec celui d'une violation de données : sanctions, perte de confiance, réputation entamée. La sécurité n'est pas un frein au produit — c'est ce qui rend le produit vendable à des clients exigeants.