Vol de données, malwares, API piratées… l’usage des applications mobiles explose, les attaques aussi. Vos applications mobiles sont-elles vraiment sécurisées ? Au-delà du simple chiffrement, comment garantir une vraie sécurité sans plomber l’UX ? Comment gérez-vous le stockage sécurisé ou le hardening client/serveur ? Et vos tests ? Sont-ils alignés sur les standards actuels ? Découvrez les pratiques et outils essentiels pour coder des apps sûres, performantes… et qui inspirent vraiment confiance.
D’abord, posons le décor avec quelques chiffres. En 2024, Akamai a recensé pas moins de 311 milliards d’attaques. Le plus frappant ? C’est que près de la moitié d’entre elles visent directement les API qui servent de portes dérobées. Premier gros défi pour les développeurs.
Mais ce ne sont pas les seules attaques contre les mobiles, loin de là ! En 2025, la pression s’intensifie. Les attaques contre les smartphones Android ont bondi de 29 % au premier semestre 2025 par rapport à l’année précédente, selon Kaspersky.
Les cybercriminels ne cherchent pas bien loin : ils ciblent ce qui rapporte immédiatement. Les OTP (mots de passe à usage unique) pour contourner l’authentification à deux facteurs, les wallets pour siphonner les avoirs numériques et, bien sûr, les données bancaires qui restent leur saint Graal.
Android est la cible privilégiée, mais iOS n’est plus ce sanctuaire inviolable qu’on imaginait il y a quelques années.
La sécurité des apps mobiles devient donc une priorité.
La menace en chiffres : l’explosion de la surface d’attaque
| Cible d’attaque | Statistiques (2025) | Impact pour le dev |
|---|---|---|
| Attaques applicatives | 83 % d’organisations attaquées en janvier 2025 (65 % en 2024) (Digital.ai) | Priorisez les tests continus, durcissement client |
| Attaques API | > 40 000 incidents au S1 2025 (Thales) | Contrôlez chaque endpoint + anti-abus (détection/blocage d’abus, bots, fraude) |
| Vulnérabilités IA/API | + 1025 % d’IA-CVE en 2024 dont 98,9 % liées aux API (Wallarm) | Testez les inputs/outputs et les contrôles AAA |
| Menaces Android |
+ 29 % d’attaques S1 2025 vs S1 2024 (Kaspersky) |
Imposez l’anti-tamper (empêcher les modifications de l’app) et la détection d’environnement |
| Coût moyen d’une violation | 4,88 M$ (IBM) | L’inertie coûte plus cher que l’outillage |
Votre feuille de route : 3 piliers pour une défense mobile
Face à cette déferlante, les checklists griffonnées au coin d’une table ne suffisent plus. Il vous faut une architecture de défense solide, reposant sur trois piliers complémentaires qui se renforcent mutuellement.
1er pilier : le cadre de référence qui structure votre démarche
Avant même d’écrire une ligne de code, vous avez besoin de points de repère. C’est exactement ce que vous propose l’OWASP Mobile Top 10 dans sa version 2024.
Ce référentiel identifie les dix risques majeurs qui guettent vos applications mobiles, du stockage non sécurisé à la cryptographie faible, en passant par les injections de code. Chaque risque est documenté, expliqué, contextualisé. Et l’OWASP Mobile Top 10 vous propose les remèdes à chaque problème.
De plus, ce référentiel sert de base de discussion avec n’importe quelle équipe de sécurité.
Mais un catalogue de dangers ne suffit pas. Il faut pouvoir traduire ces menaces abstraites en actions concrètes, et c’est là qu’intervient le MASVS v2 (Mobile Application Security Verification Standard).
Ce standard fait office de traducteur universel entre le monde des risques et celui des développeurs.
Prenons un exemple concret : le risque « stockage de données non sécurisé » devient dans le MASVS une exigence précise et vérifiable : « l’application ne doit stocker aucun secret en clair dans les préférences ». Exit le flou artistique, place aux critères clairement définis.
Suivez le guide MASTG
Pour valider que vous respectez bien ces exigences, vous pouvez ensuite vous appuyer sur le MASTG, le Mobile Application Security Testing Guide, qui vous fournit des scénarios de test pratiques et reproductibles.
Cette trilogie OWASP-MASVS-MASTG forme l’épine dorsale de votre garantie qualité sécurité.
Hélène, Engineering Manager dans une structure B2B, raconte comment son équipe a transformé le MASVS en backlog produit :
« Quand on a décidé de prendre le MASVS au sérieux, on a arrêté les grandes déclarations pour passer aux écarts concrets. On avait 17 points rouges sur la partie RESILIENCE : anti-debug, anti-hook, fuite de logs… On a monté un board unique partagé entre devs, QA et sécu, et planifié deux sprints dédiés. À chaque user story, une preuve de test MASTG était exigée. Résultat : en trois semaines, plus de bypass faciles, et une équipe alignée sur la même grille de lecture. Aujourd’hui, on ne discute plus : si c’est grave, on mesure. »
2ᵉ pilier : la défense active côté client
Votre application tourne sur un appareil que vous ne contrôlez pas. C’est un fait. L’utilisateur peut avoir rooté son Android, jailbreaké son iPhone, ou pire encore, installé des malwares qui écoutent tout ce qui transite. La question fondamentale devient alors : comment savoir si vous parlez vraiment à VOTRE application et que l’appareil est sain ?
La réponse passe par l’attestation matérielle, cette capacité à lier votre application au Hardware Security Module (HSM) de l’appareil.
Sur Android, cela signifie migrer sans délai vers Play Integrity (qui a remplacé SafetyNet). Play Integrity ne se contente pas de vérifier l’intégrité du binaire, il atteste de l’état réel de l’environnement : présence de root, détection de malware, signes de falsification. Votre code doit être impitoyable : bloquez toute exécution si le statut MEETS_BASIC_INTEGRITY échoue. Pas de demi-mesure, pas de mode dégradé qui laisserait passer un attaquant déterminé.
Sur iOS, le réflexe s’appelle App Attest. Ce service proposé par Apple lie cryptographiquement votre application à votre serveur. Concrètement, il fournit un jeton que votre back end doit valider à chaque appel sensible. La preuve est ainsi faite que c’est bien VOTRE application légitime qui envoie la requête, et non une version modifiée ou un clone malveillant.
Gardez les secrets en sécurité
Quant aux secrets de l’application, ils ne doivent jamais sortir de leur coffre-fort matériel, Android Keystore et iOS Keychain. Ils ne se contentent pas de chiffrer vos clés et tokens, ils les lient au matériel de l’appareil. Cette liaison rend l’extraction presque impossible sans une compromission physique avancée, ce qui change complètement l’équation pour l’attaquant. Ne stockez donc jamais, au grand jamais, un secret en clair dans votre binaire ou dans des préférences partagées.
Maëlys, lead Android dans une application retail, témoigne de l’impact immédiat de ces mesures :
« On suspectait des clones d’app qui appelaient nos endpoints sensibles. Le jour où on a déployé App Attest côté iOS et Play Integrity côté Android, on a changé la règle du jeu. Le back end refuse désormais tout appel critique sans attestation valide, point. En deux sprints, les tentatives de fraude visibles dans nos logs ont été divisées par trois. Côté utilisateur, rien n’a bougé : pas de frictions ajoutées, juste un silence radio des scripts qui “bruteforcaient” nos API.
3e pilier : l’API blindée
L’API, c’est l’endroit où la sécurité mobile se gagne ou se perd. Un token d’accès volé, c’est littéralement les clés du royaume, un accès total au compte de l’utilisateur et à toutes ses données.
Si vous utilisez encore le flux implicite OAuth 2.0, vous tendez une perche à l’attaquant. Le passage à OAuth 2.1 avec PKCE obligatoire n’est pas une simple mise à jour cosmétique, c’est la fermeture d’une faille béante. La spécification OAuth 2.1 restant un Internet-Draft, l’essentiel est d’appliquer ces mesures dès maintenant.
PKCE (Proof Key for Code Exchange) garantit que même si un attaquant intercepte le code d’autorisation pendant la redirection, il ne peut pas l’échanger contre un jeton d’accès.
C’est déjà un premier verrou solide, mais ça ne résout qu’une partie du problème.
Que se passe-t-il en effet si le token d’accès final est volé après coup ? Via un malware, une fuite dans les logs, un XSS ? C’est là que DPoP (Demonstration of Proof-of-Possession) entre en jeu. Ce mécanisme standardisé, plus léger à implémenter que mTLS sur mobile, change fondamentalement la donne.
Concrètement, avec DPoP :
- Le client mobile génère une paire de clés locale.
- Il signe chaque requête API avec sa clé privée (via un en-tête DPoP dédié).
- Le serveur valide la signature et vérifie que le token d’accès est bien lié à cette clé publique
Résultat : un token d’accès volé devient inutile. L’attaquant qui ne possède pas la clé privée de signature se retrouve avec une simple chaîne de caractères sans aucune valeur exploitable. C’est élégant, efficace, et ça ferme une porte que beaucoup d’applications laissent grande ouverte.
Enfin, ne négligez jamais la couche transport. Exigez TLS 1.2 minimum et préférez TLS 1.3, bannissez, bannissez les suites de chiffrement faibles (en suivant les recommandations de l’ANSSI ou de Mozilla). Utilisez HSTS (HTTP Strict Transport Security) pour vos front end web uniquement pour empêcher les attaques par repli vers des connexions non sécurisées. Pour les apps natives, privilégiez le certificate pinning (Android Network Security Config, iOS ATS) et une rotation planifiée des clés. Ces mesures sont complètement invisibles pour l’utilisateur final… et ça ferme des portes entières aux attaquants opportunistes.
Clara, SRE dans un SaaS RH, résume bien l’impact :
« On a normalisé TLS 1.3/HSTS sur tout le parc. Pour les clients, ça n’a rien changé. Pour nous, un paquet d’alertes bruit a disparu et les scans externes sont enfin propres. Franchement, c’est l’une des rares mesures à coût quasi nul et impact élevé qu’on peut déployer vite. »
Les deux angles morts qui peuvent tout faire basculer
Au-delà des trois piliers, deux zones d’ombre persistent souvent dans les stratégies de sécurité mobile. Ce sont des angles morts qui, négligés, peuvent réduire à néant tous vos efforts.
Le premier angle mort : votre supply chain, ce champ de mines invisibles
Parlons franchement : ce SDK d’analytics que vous avez intégré il y a deux ans, ce module de publicité qui vous semblait si pratique, peuvent se transformer en cheval de Troie du jour au lendemain. Une vulnérabilité découverte dans une dépendance tierce, un SDK racheté par une société moins regardante sur la sécurité, et c’est toute votre application qui devient poreuse.
La première étape consiste à savoir exactement ce que vous embarquez. Pour cela, générez systématiquement un SBOM, un Software Bill of Materials, au format CycloneDX à chaque build.
Cet inventaire complet liste toutes vos dépendances directes et transitives, créant une cartographie précise de votre surface d’attaque.
Mais un inventaire ne suffit pas, il faut l’analyser. C’est là qu’entrent en jeu les outils SCA, Software Composition Analysis, qui scannent votre SBOM pour détecter les vulnérabilités connues. Et surtout, questionnez chaque dépendance : ce SDK de pub a-t-il vraiment besoin d’accéder au réseau ET aux contacts de l’utilisateur ? Documentez ces choix et coupez impitoyablement les accès superflus.
Louis, responsable AppSec dans un média, a découvert un bénéfice inattendu de cette démarche :
« Quand on a sorti notre premier SBOM CycloneDX propre, on pensait être tranquilles. Le scan SCA a pourtant remonté un SDK pub avec des permissions délirantes et une CVE fraîche. On a retiré le SDK, mis un process d’approbation des dépendances, et ajouté une revue des scopes à chaque release. Bénéfice inattendu : la conso réseau a baissé, et le temps de démarrage aussi. Le gain perf+ sécu, on ne s’y attendait pas. »
Le deuxième angle mort : l’absence de DevSecOps, ou comment repousser les problèmes à demain
La sécurité testée à la fin du cycle, c’est la garantie de découvrir des problèmes critiques quand il est trop tard pour les corriger proprement. La sécurité doit donc devenir une condition de build
Pour cela, automatisez votre cycle de défense. Lancez l’analyse statique (SAST) et l’analyse de dépendances (SCA) à chaque commit. Intégrez des outils comme Semgrep ou SonarQube pour le code, Syft (génération SBOM) et Grype (scan de vulnérabilité). L’objectif ? Casser la build si un secret est hardcodé ou si une vulnérabilité critique est trouvée. Pas de tolérance, pas de « on verra plus tard ».
Passez ensuite au binaire lui-même. Intégrez MobSF, le Mobile Security Framework, dans votre pipeline CI pour auditer l’APK ou l’IPA généré. Si les configurations de base du MASVS ne sont pas respectées, la build échoue.
Ajoutez des tests d’API : vérifications DPoP (nonce/jti/iat/htu/htm), détection d’abus/bots, et rotation des refresh tokens avec détection de réutilisation.
Enfin, instrumentalisez vos tests de sécurité. Utilisez Frida ou Objection pour automatiser les vérifications d’anti-tampering. Si vos défenses contre le root/jailbreak ou le SSL pinning ne réagissent pas comme prévu, la build échoue. Cette rigueur peut sembler brutale au début, mais elle transforme radicalement la qualité de ce que vous livrez.
Romain, DevSecOps dans une EdTech, témoigne du changement culturel :
« La première fois qu’on a cassé la build pour une régression MobSF, c’était impopulaire. Deux jours plus tard, plus personne ne discutait : les quick wins sécu sortaient avant la prod, pas après. On a ajouté un rapport hebdo des contrôles, c’est devenu un critère d’acceptation produit. Bonus, le stress en MEP a fondu : on sait ce qu’on livre. »
Votre plan d’action : par où commencer ?
Face à cette liste de mesures, la paralysie guette. Par où commencer ? Comment prioriser ? Voici une trajectoire pragmatique, découpée en trois phases de deux semaines chacune.
Semaine 1-2 : cartographiez l’existant
- Passez votre app au crible du MASVS v2
- Identifiez vos 5 écarts critiques (ceux qui exposent le plus vos utilisateurs)
- Générez votre premier SBOM CycloneDX avec Syft et scannez-le avec Grype
Semaine 3-4 : implémentez les fondations
- Client : Play Integrity (Android) + App Attest (iOS)
- API : PKCE + DPoP sur vos endpoints sensibles (ceux qui manipulent des données critiques ou des transactions financières)
- Transport : TLS 1.2 minimum/1.3 préférée + certificate pinning (Android Network Security Config / iOS ATS) (HSTS réservé à vos front end web)
Semaine 5-6 : industrialisez dans la pipeline CI/CD
- Intégrez SAST/SCA avec la règle : toute vulnérabilité critique casse la build
- Ajoutez MobSF pour l’audit de vos binaires
- Automatisez un test Frida sur vos contre-mesures principales + tests d’API DPoP
L’open bar est fermé… définitivement !
L’ère du mobile considéré comme un « simple client » est révolue. C’est désormais un endpoint critique. Les chiffres de 2025 le prouvent sans ambiguïté : les attaquants s’y donnent à cœur joie.
L’attestation matérielle, l’authentification renforcée, et une CI impitoyable ne sont plus réservées aux applications bancaires.
La sécurité n’est plus une fonctionnalité qu’on ajoute si le budget le permet. C’est la base même de la confiance que vous établissez avec vos utilisateurs. N’attendez pas le rapport d’audit catastrophique ou la violation de données qui vous coûtera des millions. Votre nouveau mantra doit être : « Si ce n’est pas sécurisé, ça ne part pas en production. »
Votre job n’est plus seulement de livrer du code qui fonctionne. C’est de livrer de la confiance. Votre prochain commit sera votre première ligne de défense. Faites-en sorte qu’il compte.
