Voici la prémisse inconfortable par laquelle toute décision de sécurité mobile devrait commencer : votre app tourne sur un appareil que vous ne contrôlez pas, entre les mains de quelqu'un qui est peut-être l'attaquant.
Les développeurs web ont le droit de supposer que le serveur leur appartient. Les développeurs mobile livrent le client à l'adversaire — avec un débogueur.
L'hypothèse qui cause la plupart des brèches
L'erreur la plus chère du développement mobile est de traiter l'app comme une partie de confiance de votre système.
Elle ne l'est pas. Un attaquant peut la décompiler, lire chaque chaîne, observer chaque appel réseau, modifier le binaire et l'exécuter sur un appareil rooté avec instrumentation. Rien de tout cela n'exige de sophistication — l'outillage est mûr, documenté et gratuit.
Ce qui signifie : tout contrôle de sécurité implémenté uniquement dans l'app est consultatif. La vérification premium qui débloque une fonction côté client est une vérification qu'un attaquant supprime. La validation qui empêche une quantité négative se contourne en éditant la requête. La limite de débit imposée dans votre code n'est pas une limite de débit.
Tout ce qui compte vraiment s'impose sur votre serveur. Les contrôles côté client existent pour guider les utilisateurs honnêtes et augmenter le coût pour les malhonnêtes. Ils n'imposent rien.
Ce que les attaquants visent réellement
Sautez les listes théoriques de vulnérabilités et regardez ce qui ressort des incidents réels.
Des secrets dans le binaire. Clés d'API, jetons et identifiants compilés dans l'app — parfois obscurcis, toujours extractibles. Des scanners automatiques ratissent les stores exactement pour cela, et les chercheurs trouvent constamment des clés de production valides. L'obfuscation retarde une personne déterminée de quelques minutes.
Un stockage local non sécurisé. Jetons de session dans les préférences partagées, données personnelles dans un fichier SQLite non chiffré, informations sensibles dans des journaux que toute app installée avec la bonne permission peut lire. Pratique en développement, permanent en production.
Une autorisation d'API faible. C'est le gros morceau — et ce n'est pas vraiment une vulnérabilité mobile : c'en est une de backend, que le mobile rend facile à trouver. Un endpoint qui retourne la fiche de n'importe quel utilisateur pour n'importe quel identifiant se découvre trivialement : observer son propre trafic, changer un chiffre. L'app ne vous a jamais montré ces données ; l'API les a livrées de bon cœur.
La confiance dans les valeurs du client. Prix, identifiants, rôles et quantités envoyés par l'app et utilisés sans vérification serveur. Si votre paiement accepte un prix venu du client, quelqu'un en enverra un meilleur.
Les SDK tiers. Analytics, publicité, rapport de crashs, attribution — chacun avec accès réseau et souvent des permissions larges, chacun une dépendance de chaîne d'approvisionnement que vous n'avez pas écrite et ne pouvez pas auditer. Plusieurs incidents mobiles notoires étaient un SDK faisant ce que son app hôte n'avait jamais voulu.
Fig. — Tout ce qui est à gauche de cette frontière est inspectable. Seul le serveur impose.
La checklist qui aide vraiment
Ne livrez aucun secret. Si l'app doit appeler une API tierce avec une clé, faites transiter l'appel par votre backend pour que la clé reste côté serveur. Là où une clé doit réellement partir avec l'app, traitez-la comme publique et restreignez-la par identifiant de bundle, référent et périmètre — pour que sa possession seule ne vaille rien.
Utilisez le keystore de la plateforme. Les deux plateformes offrent un stockage sécurisé adossé au matériel. Les jetons et identifiants vont là — pas dans les préférences, pas dans un fichier que vous avez chiffré vous-même avec une clé qui est aussi dans l'app.
Autorisez chaque requête côté serveur, sur l'identité de la session. Pas sur un paramètre fourni par le client. Ce seul contrôle élimine la plus grande catégorie d'expositions de données mobiles du monde réel.
Épinglez les certificats pour le trafic à forte valeur — prudemment. Le pinning défait l'interception occasionnelle. Il casse aussi votre app sur le terrain quand un certificat tourne à l'improviste : implémentez-le avec un pin de secours et un interrupteur distant — ou pas du tout.
Inventoriez vos SDK et justifiez chacun. Pour chaque tiers de votre build, sachez quelles données il reçoit et pourquoi il est là. Retirez ceux que personne ne sait expliquer — il y en a généralement deux ou trois.
Détectez la manipulation sans en dépendre. Détection de root et de jailbreak, contrôles d'intégrité, détection de débogueur : tout cela renchérit sensiblement le coût pour les attaquants opportunistes. Tout est contournable par un déterminé. Utilisez-les comme signaux vers votre backend, pas comme portes dans l'app.
Journalisez les événements de sécurité côté serveur. Autorisations échouées, séquences inhabituelles, requêtes impossibles. Les attaques contre les apps mobiles sont visibles dans le trafic d'API bien avant de l'être ailleurs — et la plupart des équipes ne regardent pas.
Où le modèle de menace diffère selon l'app
Les checklists génériques servent jusqu'à un point — puis il faut réfléchir à qui prendrait la peine de vous attaquer, vous, et pourquoi.
Si votre app manipule de l'argent, l'attaquant vise les transactions et son budget d'effort est élevé. Attendez-vous à des outils construits spécifiquement contre vous, et supposez que chaque contrôle côté client tombera. Ce qui compte : limites de transaction côté serveur, détection d'anomalies dans le backend, et authentification renforcée pour tout l'irréversible.
Si votre app détient des données personnelles mais pas d'argent, l'attaque la plus probable est l'extraction en masse via l'API plutôt que la compromission d'un compte. Cela change les priorités : limites de débit par identité, limites de pagination et alertes sur les volumes de lecture inhabituels comptent plus que le durcissement du binaire.
Si votre app est un produit payant ou contient des fonctions payantes, la menace est vos propres utilisateurs contournant le paiement. C'est le seul cas où le durcissement côté client paie vraiment — l'attaquant n'est pas sophistiqué, et le but est juste de rendre l'effort plus cher que l'abonnement. La protection parfaite est impossible, et d'ailleurs inutile.
Et si votre app est un outil d'entreprise distribué en interne, le risque intéressant est l'appareil perdu ou compromis plutôt que l'attaquant distant. Cela vous pousse vers des sessions courtes, l'effacement à distance — et vers ne pas mettre en cache localement de données sensibles du tout.
Déterminer lequel de ces cas est le vôtre prend une heure — et change ce à quoi vous devriez consacrer le prochain trimestre.
La couche réglementaire qui a changé
La sécurité était autonotée. De moins en moins.
Les deux stores exigent désormais des déclarations sur les données que vous collectez et partagez — et ces déclarations sont vérifiées contre le comportement réel. Un écart, c'est un rejet en revue, ou un retrait.
Le droit de la protection des données ajoute l'exigence la plus dure. Sous le RGPD et le DPDP Act indien, collecter des données dont vous n'avez pas besoin est en soi une violation, quelle que soit la qualité de leur protection — et une brèche entraîne des obligations de notification à délais serrés. Conséquence pratique : la minimisation des données est désormais un contrôle de sécurité. Le moyen le plus rapide de réduire l'exposition, c'est d'arrêter de collecter.
Et les paiements ont leur propre régime. Si votre app touche des données de carte sous quelque forme que ce soit, PCI DSS s'applique — et la bonne réponse est presque toujours de ne pas y toucher : utiliser un SDK de paiement qui tokenise avant que les données n'atteignent votre code.
La chaîne de build fait partie de la surface d'attaque
Une catégorie est totalement négligée parce qu'elle ne vit pas dans l'app : la façon dont l'app est construite et signée.
Les clés de signature sont les joyaux de la couronne. Qui les détient peut publier une mise à jour que vos utilisateurs installeront automatiquement, en confiance, parce qu'elle vient de vous. Ces clés appartiennent à un stockage matériel ou à un service de signature géré — pas à un laptop, et certainement pas au dépôt. Les deux plateformes offrent désormais la signature gérée, et l'utiliser supprime une classe entière de risques catastrophiques.
Les systèmes de build méritent le même examen que la production. Une chaîne CI aux identifiants larges, exécutant des scripts de dépendances téléchargés au moment du build, est une compromission de chaîne d'approvisionnement en attente — et c'est arrivé à des entreprises bien tenues. Épinglez vos versions de dépendances, relisez ce que vos scripts de build exécutent, et restreignez étroitement les identifiants de la CI.
Et sachez ce qui entre dans votre binaire. Un manifeste de dépendances que vous pouvez réellement produire sur demande est de plus en plus attendu des clients enterprise — et, dans certains secteurs, des régulateurs.
Par où commencer si vous avez hérité d'une app
Passez d'abord un scanner de sécurité mobile sur votre propre binaire. Ça prend un après-midi, c'est gratuit, et ça trouvera les secrets codés en dur et le stockage non chiffré. Corrigez-les avant tout le reste — car ce sont les trouvailles que les scanners feront à votre place sinon.
Passez ensuite une journée à intercepter votre propre trafic avec un proxy. Changez un identifiant dans une requête pour tenter de charger un autre compte. Envoyez un autre prix. Appelez un endpoint que l'app n'appelle jamais depuis un écran que vous n'avez pas déverrouillé. Les résultats sont généralement dégrisants — et toujours plus utiles qu'une checklist.
Le test d'intrusion annuel vaut la peine une fois ces bases tenues. Mais payer un expert pour trouver une clé d'API codée en dur est une façon coûteuse d'apprendre ce qu'un scanner gratuit vous aurait dit.
Les apps qui se font pirater sont rarement celles à la faille cryptographique subtile. Ce sont celles où personne n'a jamais changé l'identifiant utilisateur dans une requête pour voir ce qui revenait.
Construire cela proprement dans une app dès le départ, c'est le genre de travail que nous faisons chez CODT.
