Audit sécurité application mobile avant publication : le guide

Un développeur m'a envoyé la semaine dernière le lien de son app, publiée trois semaines plus tôt. Elle était propre. Bien notée. Et elle exposait sa clé API Stripe en clair dans le bundle Android. Il n'en savait rien. Son prestataire non plus, apparemment.

Ce genre de découverte, je la fais régulièrement quand on me demande de regarder une application avant publication — ou juste après, ce qui est déjà trop tard. Un audit sécurité application mobile avant publication ne consiste pas à cocher une case dans un dossier de mise en production. C'est le seul moment où corriger coûte peu. Une fois l'app en ligne, chaque correctif devient une mise à jour à pousser, un utilisateur à convaincre, une note à rattraper.

Pourquoi l'audit sécurité mobile avant publication n'est pas un luxe

Posez-vous une question simple : combien de temps votre application reste-t-elle sur le store sans être touchée ? Des mois, souvent. Pendant ce temps, le code que vous avez livré tourne chez des milliers de personnes, sur des terminaux que vous ne contrôlez pas. La responsabilité, elle, reste chez vous.

Ce que les stores contrôlent vraiment (et ce qu'ils ignorent)

Il y a une confusion tenace : « c'est bon, Apple l'a validée, donc c'est sécurisé ». Non. La revue Apple vérifie la conformité aux règles de la plateforme, le respect des politiques de confidentialité, l'absence de code manifestement frauduleux. Elle ne fait pas de test d'intrusion dans votre application. Google Play, via Play Protect, détecte des comportements malveillants connus. Ça ne remplace pas une revue de votre logique métier.

Une application peut passer les deux revues avec une base de données accessible sans authentification. Je l'ai vu. Deux fois.

Le coût réel d'une faille en production

Prenons un cas concret que j'ai suivi : une app de réservation avec 4 000 utilisateurs actifs. Un endpoint de l'API renvoyait les données d'un compte sans vérifier que l'appelant était bien ce compte. Trois semaines après la découverte, il fallait notifier les utilisateurs, refaire passer l'app en revue, communiquer. Le correctif lui-même a pris deux jours. Le reste a pris deux mois.

Un test ciblé sur ce seul endpoint, avant publication, aurait coûté une demi-journée.

Comment réaliser un audit d'application ?

La question revient souvent, et elle mérite une réponse honnête : il n'y a pas une méthode unique. Un audit d'application, c'est un diagnostic — on regarde ce qui a été construit, comment ça se comporte, et ce qui ne tient pas. Le périmètre change selon le moment du projet et selon ce que vous voulez savoir.

Définir le périmètre avant tout

Avant de lancer quoi que ce soit, posez trois questions :

• Quel est l'objectif ? Conformité, confiance dans le prestataire, préparation d'une levée de fonds, ou vraie inquiétude sur un point précis.
• Quel est le périmètre technique ? Code natif, framework hybride, back-end inclus ou pas, API tierces.
• Qui a accès au code source ? Sans lui, l'audit devient un test en boîte noire, ce qui change entièrement la donne.

Sans réponse claire à ces trois points, vous payez pour un rapport que personne ne lira.

Les documents à fournir

Un auditeur sérieux demandera : le code source (ou les binaires), la documentation d'architecture, la liste des API et services tiers, les politiques de gestion des secrets, et les éventuels rapports d'audit antérieurs. Si l'équipe n'a pas ces éléments, c'est déjà une information en soi.

Quels sont les 3 types d'audits ?

Trois familles, qui ne répondent pas aux mêmes questions. Les confondre est l'erreur la plus courante que je vois dans les cahiers des charges.

1. L'analyse statique (SAST)

On lit le code sans l'exécuter. Des outils scannent les motifs connus : secrets en dur, fonctions cryptographiques faibles, stockage non sécurisé, journalisation excessive. C'est rapide, automatisable, et ça attrape une bonne partie des erreurs basiques. Ça ne dit rien sur la logique métier.

2. L'analyse dynamique (DAST)

On exécute l'application et on observe. Interception du trafic réseau, modification de requêtes, test des entrées utilisateur, comportement face à un certificat inattendu. C'est là qu'on découvre les vraies failles d'authentification, les contrôles d'accès manquants, les données qui circulent en clair.

3. Le test d'intrusion (pentest)

Un humain attaque l'application avec l'intention de la casser. C'est le plus cher, le plus lent, et souvent le plus révélateur — à condition d'être réalisé par quelqu'un qui connaît le mobile, pas par un pentester web qui applique sa recette habituelle.

Le bon enchaînement, en pratique, c'est SAST puis DAST, et pentest ciblé sur les zones sensibles. Un pentest complet sur une app à 500 utilisateurs relève souvent du surdimensionnement.

Quelles sont les 4 phases principales d'un audit ?

Peu importe le type d'audit : la mécanique reste la même. Quatre phases, dans cet ordre. Sauter une étape se paie plus loin.

Phase 1 — Cadrage

On définit le périmètre, les objectifs, les accès, le calendrier. C'est la phase la plus souvent bâclée. Un cadrage réussi, c'est un audit qui ne déborde pas de trois semaines sur des questions hors périmètre.

Phase 2 — Collecte et analyse

Récupération du code, des binaires, du trafic réseau, des configurations back-end. On teste. On compare aux référentiels. On documente tout ce qui pose problème, avec la preuve à l'appui.

Phase 3 — Priorisation

Là où beaucoup d'audits échouent. On ne livre pas une liste alphabétique de 120 points. On livre une liste courte, triée par impact réel : ce qui expose des données utilisateur, ce qui permet une prise de contrôle, ce qui relève du confort.

Phase 4 — Restitution et correctifs

Une réunion, un document, puis un suivi. Un audit qui ne débouche pas sur une vague de correctifs et une re-vérification n'a servi à rien. Je demande toujours une session de correction post-audit dans le devis initial — sinon on me rappelle trois mois plus tard avec les mêmes failles.

Comment réaliser un audit de sécurité ?

La partie sécurité mérite d'être détaillée, parce que c'est souvent ce qui motive la démarche. Et parce que la liste des choses à vérifier tient en une page — pas en cinquante.

La checklist technique qui compte vraiment

Point de contrôle	Ce qu'on cherche	Fréquence du problème
Secrets dans le code	Clés API, tokens exposés dans le bundle ou le dépôt	Très fréquent
Stockage local	Données sensibles en clair (SharedPreferences, NSUserDefaults, fichiers)	Fréquent
Transit réseau	HTTP non chiffré, certificat non épinglé, validation désactivée	Fréquent
Authentification	Tokens à durée de vie infinie, absence de révocation, stockage des sessions	Fréquent
Journalisation	Données personnelles dans les logs de production	Très fréquent
Protection du binaire	Absence d'obfuscation, débogage activé en production	Occasionnel
Permissions	Permissions demandées sans justification fonctionnelle	Occasionnel

Cette grille, appliquée sérieusement, attrape la grande majorité des problèmes que je rencontre. Le reste relève de failles métier spécifiques à chaque application.

Le référentiel à garder sous la main

OWASP MASVS (Mobile Application Security Verification Standard) et MASTG (le guide de test associé) restent, à mon avis, la référence la plus solide pour structurer un audit mobile. Deux niveaux utiles : une vérification de base, et une vérification renforcée pour les applications qui manipulent des données financières ou de santé. Choisir le bon niveau fait varier le coût d'un facteur deux ou trois.

Le volet RGPD au moment de la mise en ligne

Un point qu'on oublie souvent : l'audit sécurité pré-publication croise les obligations de protection des données. Sur Google Play, la fiche « Data Safety » doit déclarer ce que l'application collecte et comment. Sur l'App Store, les étiquettes de confidentialité jouent le même rôle. Une faute de déclaration peut entraîner un retrait de l'application — même si le code est irréprochable. Vérifiez que ce qui est déclaré correspond à ce que le code fait réellement. J'ai vu une app déclarer « aucune collecte de localisation » alors que le SDK d'un partenaire publicitaire en captait.

Quand se passer d'un audit complet ?

Si votre application ne traite aucune donnée personnelle, ne fait aucun paiement, et ne s'authentifie pas, un audit complet est disproportionné. Une analyse statique et une revue de la configuration réseau suffisent. Inutile de mettre 15 000 € dans une prestation qui n'apportera rien de plus.

L'inverse est vrai : dès qu'il y a de l'authentification, des données utilisateur ou un flux de paiement, l'audit n'est pas optionnel. C'est là que les failles coûtent le plus cher.

Le livrable qui sert vraiment

Oubliez les rapports de 80 pages. Le document qui déclenche des corrections, c'est une liste de quinze lignes maximum, triée par criticité, avec pour chaque point : ce qui est exposé, comment le reproduire, ce qu'il faut corriger. Un tableau. Pas de narratif.

Et un détail que j'ai appris à la dure : la correction n'est pas la fin. Une re-vérification après correctifs est indispensable. Sur trois audits récents, deux équipes avaient « corrigé » sans que les correctifs fonctionnent réellement en production — l'un avait désactivé une vérification côté client uniquement, l'autre avait changé la clé API mais laissé l'ancienne active sur un ancien endpoint. Les deux auraient passé un audit de surface.

Ce que je retiens

Un audit sécurité avant publication ne vous dit pas si votre application est parfaite. Il vous dit ce qui va casser, et à quel point. La nuance est importante : aucune application n'est sûre à 100 %. Ce qu'on cherche, c'est le point où le risque devient inacceptable, et la façon de le ramener sous ce seuil.

La question n'est pas « faut-il auditer avant de publier ? ». C'est « que se passe-t-il si je publie sans ? ». Dans mon expérience, la réponse tient en deux mots : ça dépend. Ça dépend de ce que vous stockez, de qui vous authentifiez, et de ce que votre équipe considère comme acceptable. Le reste, c'est de la technique.