Applications mobiles
Pentest mobile
Votre application mobile s’exécute sur un appareil que vous ne maîtrisez pas. L’attaquant dispose donc du binaire, du stockage local et de la totalité du trafic. Nous testons ces trois couches, ainsi que les API qui alimentent l’application, sur iOS comme sur Android.
Le test d’intrusion (pentest) suit le standard de vérification OWASP MASVS et le guide de test MASTG : la couverture est mesurable et ne dépend pas de la personne qui a réalisé la mission. Chaque vulnérabilité est exploitée, documentée, puis revérifiée lors du contre-audit, inclus sans surcoût.
Ils nous font confiance
Objectifs
Objectifs d’un pentest mobile
Un test d’intrusion mobile répond à une question simple : que récupère réellement un attaquant à partir d’un téléphone volé, d’un appareil rooté ou d’un simple proxy posé sur un réseau Wi-Fi public ? Nous partons d’une build réelle et d’un appareil réel, jamais d’un environnement de démonstration.
Le rapport ne contient pas une sortie d’outil. Ce que nous trouvons, nous l’exploitons, afin que vous mesuriez l’impact concret — accès au compte d’un autre client, lecture de données bancaires, contournement d’un paiement, récupération d’une clé d’API valable en production — plutôt qu’une liste de signalements théoriques que vos développeurs devront trier eux-mêmes.
Mesurer l’exposition de l’appareil
Secrets embarqués dans le binaire, jetons de session conservés en clair, données personnelles qui survivent à une sauvegarde : nous établissons ce qu’un attaquant obtient sans jamais toucher à vos serveurs.
Vérifier ce que l’API autorise vraiment
Une application mobile n’est souvent qu’une façade posée sur une API. Nous testons l’autorisation côté serveur avec la même rigueur qu’un pentest web, parce que c’est là que se trouvent les failles les plus graves.
Prioriser la remédiation
Chaque vulnérabilité est notée (CVSS), rattachée à une catégorie MASVS et accompagnée des étapes de reproduction. Vos développeurs savent quoi corriger en premier et pourquoi.
Périmètre
Ce que nous testons sur iOS et Android
Une mission mobile couvre bien plus que les écrans visibles par l’utilisateur. Nous travaillons sur un appareil réel, avec la build que vous publiez sur l’App Store et Google Play : nous décompilons l’application, instrumentons le processus en cours d’exécution et suivons chaque chemin ouvert à un attaquant disposant d’un téléphone volé, d’un appareil rooté ou jailbreaké, ou simplement d’un émulateur.
Six familles de faiblesses reviennent dans la quasi-totalité des missions : le stockage local (bases non chiffrées, préférences partagées, sauvegardes), l’épinglage de certificat (certificate pinning) contournable à l’exécution, le contournement de la détection de root et de jailbreak, la communication avec les API, les secrets embarqués dans le binaire et la rétro-ingénierie de la logique métier.
Lorsque l’application n’est qu’un client léger, le risque réel se situe derrière l’API : le jeton de session est bien stocké sur l’appareil, mais personne ne contrôle l’autorisation côté serveur. C’est pourquoi nous intégrons le backend au périmètre chaque fois que c’est possible, et pourquoi nous le disons explicitement dans la note de cadrage lorsque ce n’est pas le cas.
Couverture par catégorie OWASP MASVS
| Domaine | Ce que nous recherchons |
|---|---|
| Stockage local | Clés et jetons écrits dans les préférences partagées ou les UserDefaults, bases de données non chiffrées sur l’appareil, données personnelles déposées sur le stockage externe et données qui survivent dans les sauvegardes. |
| Communications | Trafic en clair, absence de validation du certificat serveur et épinglage de certificat (certificate pinning) contournable à l’exécution sur un appareil rooté. |
| Identifiants et sessions | Clés d’API en dur dans le code, jetons écrits dans les journaux, jetons de session rejouables après déconnexion et validation biométrique qui ne protège aucune opération sensible. |
| Protections du binaire | Build de production restée débogable, absence de détection du root et du jailbreak, faible résistance au repackaging, à la modification du binaire et à la rétro-ingénierie. |
| Interfaces de la plateforme | Composants exportés, abus de liens profonds (deeplinks), ponts JavaScript dans les WebView et traversée de répertoires via les content providers. |
| Chaîne d’approvisionnement | SDK tiers compromis, dependency confusion et chargement de code dynamique non signé au démarrage de l’application. |
Chaque ligne renvoie au chapitre correspondant du Haxoris Wiki (rédigé en anglais) : nous y documentons la faiblesse, la manière dont elle est exploitée et la façon de la corriger.
Approches
Approches : boîte noire, boîte grise, boîte blanche
Trois approches existent et elles ne répondent pas à la même question. Sur une application mobile, la différence tient surtout à ce que vous nous remettez au départ : une simple build publiée, des comptes de test pour chaque rôle, ou le code source et la configuration du backend.
Dans la grande majorité des missions, nous recommandons la boîte grise. À nombre de jours-homme égal, elle couvre davantage de fonctionnalités, parce que nous ne consacrons pas la moitié du budget à créer des comptes et à cartographier des parcours au lieu de chercher des vulnérabilités.
Boîte noire (black box)
Nous partons de la build publiée, sans compte ni documentation, comme l’attaquant opportuniste qui télécharge votre application sur un store. Utile pour mesurer l’exposition publique ; insuffisant pour couvrir les fonctionnalités réservées aux utilisateurs authentifiés.
Boîte grise (grey box)
Nous disposons de comptes de test pour chaque rôle et d’une description fonctionnelle. C’est l’approche retenue dans la plupart des missions mobiles : elle permet de tester l’autorisation entre utilisateurs, les parcours de paiement et l’API dans le même budget.
Boîte blanche (white box)
Nous ajoutons le code source, une build de débogage et, si nécessaire, la configuration du backend. L’analyse statique gagne en profondeur : secrets de build, logique métier sensible, chiffrement mal implémenté. À privilégier avant une mise en production sensible ou pour une application de paiement.
Méthodologie
Notre méthodologie et le déroulement de la mission
Nous appliquons le standard OWASP MASVS pour fixer le niveau de vérification attendu et le guide MASTG pour les tests eux-mêmes. L’API qui alimente l’application est testée selon le guide OWASP WSTG, et la conduite générale de la mission suit le cadre PTES. Ces référentiels sont publics : vous pouvez vérifier, point par point, ce qui a été couvert. Nos méthodologies de test sont détaillées sur le site.
Comptez deux à quatre semaines de bout en bout pour une application courante, contre-audit compris. L’outillage sert à la collecte ; l’exploitation et la validation restent manuelles, ce qui explique qu’une mission représente le plus souvent 8 à 15 jours-homme et non un scan de deux heures.
Cadrage
Nous fixons les plateformes, la build testée, les comptes et les rôles, ainsi que l’inclusion ou non du backend. Le périmètre et l’autorisation sont formalisés par écrit avant toute action : tous nos tests d’intrusion sont réalisés sur mandat écrit, dans un périmètre défini contractuellement (articles 323-1 et suivants du code pénal). Vous recevez un prix ferme avant le démarrage.
Analyse statique
Nous décompilons la build, lisons le manifeste Android et les entitlements iOS, inventorions les bibliothèques tierces et recherchons les secrets embarqués, la cryptographie faible et les artefacts de débogage laissés dans la version de production.
Analyse dynamique
Sur un appareil réel : instrumentation à l’exécution, interception du trafic, contournement de l’épinglage de certificat, contournement de la détection de root et de jailbreak, inspection du stockage local et abus des interfaces exportées.
Tests de l’API et du backend
Les API dont dépend l’application sont testées comme une application web : autorisation, IDOR, limitation de débit, gestion des sessions et logique métier. C’est la partie qui produit le plus souvent les constats critiques.
Rédaction et restitution
Chaque constat est documenté avec une preuve d’exploitation, une notation CVSS, la catégorie MASVS concernée et les étapes de reproduction. La restitution se déroule en visioconférence avec l’équipe technique, puis, si vous le souhaitez, en une session courte pour la direction.
Contre-audit
Une fois vos correctifs déployés, nous rejouons les scénarios concernés et publions une version actualisée du rapport. Le contre-audit est inclus dans le prix, sous 90 jours après la remise du rapport initial.
Livrables : rapport, restitution et contre-audit
Vous n’achetez pas un fichier PDF, vous achetez de quoi décider et de quoi corriger. Un exemple de rapport anonymisé est disponible avant signature, afin que vous sachiez exactement ce que vous recevrez.
Rapport technique en français
Chaque vulnérabilité avec sa preuve d’exploitation, sa notation CVSS, la catégorie MASVS concernée et les étapes de reproduction, captures et requêtes comprises.
Synthèse managériale
Deux à trois pages lisibles par un comité de direction : niveau de risque global, trois priorités, effort de remédiation estimé et évolution depuis la mission précédente.
Restitution en visioconférence
Une séance de restitution animée par les pentesteurs qui ont réalisé les tests, avec vos développeurs. Vous parlez aux personnes qui ont trouvé les failles, pas à un commercial.
Contre-audit inclus, sans surcoût
Nous revérifions vos correctifs et publions un rapport actualisé, opposable à un client ou à un auditeur. Inclus dans le prix, sous 90 jours après la remise du rapport.
Ce que comprend chaque pentest mobile
Quel que soit le périmètre retenu, chaque mission mobile inclut :
Pourquoi Haxoris
Haxoris est un prestataire européen, établi dans l’Union européenne : vos build, vos rapports et les preuves d’exploitation restent dans l’UE et le RGPD s’applique directement à ce traitement. Nous ne détenons aucune qualification délivrée par une autorité publique française et nous ne le prétendons pas. Ce que nous mettons à la place tient en trois points, tous vérifiables avant signature.
Contre-audit inclus, sans surcoût
La revérification de vos correctifs fait partie du prix, sous 90 jours après la remise du rapport. Ce n’est ni une journée facturée en supplément, ni une option de la proposition.
Nos tarifs sont publics
Une application sur une seule plateforme démarre à 2 000 € HT. Les fourchettes et le tarif en jours-homme sont publiés dans notre article sur le prix d’un test d’intrusion, avant même le premier échange.
Vous savez qui teste
Vous connaissez le nom, le parcours et les certifications des pentesteurs affectés à votre mission (OSCP, eMAPT), et vous échangez directement avec eux. Voir la page à propos et nos témoignages clients.
Témoignages clients
Ce que nos clients disent de nous
Pentest mobile : foire aux questions
01 Combien coûte un pentest mobile ?
Le prix suit le périmètre : nombre de plateformes, taille et complexité de l’application, présence de paiements ou de données de santé, inclusion ou non du backend. Une application sur une seule plateforme démarre autour de 2 000 € HT. Les deux plateformes testées avec l’API associée représentent le plus souvent 8 à 15 jours-homme.
Après un échange de cadrage d’une trentaine de minutes, vous recevez un prix ferme pour l’ensemble de la mission, contre-audit compris. Le détail de notre grille figure dans l’article consacré au prix d’un test d’intrusion (pentest).
02 Combien de jours-homme faut-il prévoir ?
Une application simple, sur une seule plateforme et sans paiement, se teste en 4 à 6 jours-homme. Une application avec authentification, plusieurs rôles et parcours de paiement, testée sur iOS et Android avec son API, demande 8 à 15 jours-homme. Une application très volumineuse, ou soumise à des exigences sectorielles fortes, peut dépasser 20 jours-homme.
Nous préférons annoncer une charge réaliste plutôt qu’un forfait court qui obligerait à interrompre les tests à mi-parcours : un périmètre sous-évalué produit un rapport rassurant et faux.
03 Boîte noire ou boîte grise : que choisir ?
La boîte grise, dans la quasi-totalité des cas. En boîte noire, une part du budget est consommée à créer des comptes, cartographier les parcours et deviner les rôles : autant de jours qui ne servent pas à chercher des vulnérabilités. Avec des comptes de test pour chaque rôle, la même charge couvre nettement plus de fonctionnalités.
La boîte noire conserve son intérêt lorsque la question posée est précisément : « que peut faire un attaquant qui ne dispose que de l’application publiée sur le store ? » La boîte blanche, avec le code source, s’impose avant une mise en production sensible ou pour une application de paiement.
04 Avez-vous besoin du code source ?
Non. Par défaut, nous travaillons en boîte noire à partir de la build de production, comme un attaquant. Si vous pouvez partager le code source ou une build de débogage, nous les utilisons : à nombre de jours égal, la boîte grise et la boîte blanche remontent davantage de constats. Ce n’est pas une condition.
Si l’application a été développée par un prestataire externe et que vous n’avez pas accès au code, cela ne change rien à notre approche ni au périmètre annoncé.
05 Testez-vous à la fois iOS et Android ?
Oui, et la plupart de nos clients font tester les deux, car les deux plateformes échouent différemment. Android laisse plus souvent fuir des données par les composants exportés, les liens profonds et le stockage local ; iOS par un mauvais usage du Keychain et par une détection de jailbreak contournable.
Les deux build sont testées séparément et documentées séparément : un correctif appliqué côté Android ne vaut pas preuve côté iOS.
06 L’API qui alimente l’application est-elle incluse ?
Elle peut l’être, et elle devrait presque toujours l’être. Une application mobile est souvent une façade posée sur une API où réside la véritable logique d’autorisation : un attaquant qui a extrait un jeton de l’appareil s’attaque ensuite à l’API, pas à l’écran. Nous inscrivons explicitement le backend dans le périmètre pour qu’aucune ambiguïté ne subsiste sur ce qui a été couvert.
Voir également notre page pentest web et API, ainsi que l’audit de vulnérabilités si votre besoin porte d’abord sur un inventaire large.
07 Le contre-audit est-il inclus ?
Oui, et sans surcoût. Une fois vos correctifs déployés, nous rejouons les scénarios concernés et publions une version actualisée du rapport indiquant ce qui est corrigé et ce qui ne l’est pas. Le contre-audit est compris dans le prix, sous 90 jours après la remise du rapport initial.
C’est un point sur lequel nous nous écartons de la pratique courante : le contre-audit est le plus souvent facturé comme une journée supplémentaire, ou évoqué sans engagement dans la proposition.
08 Faut-il un prestataire qualifié pour faire tester une application mobile ?
Pour une application commandée par une entreprise privée, aucun texte n’impose de recourir à un prestataire titulaire d’une qualification délivrée par une autorité publique. Ces qualifications relèvent d’une démarche volontaire et concernent principalement la commande publique et les contrôles réservés à certains opérateurs, sur lesquels nous ne soumissionnons pas.
Nous ne détenons aucune qualification de ce type et nous ne le prétendons pas. Ce que vous pouvez vérifier : les certifications individuelles des pentesteurs affectés à votre mission, un exemple de rapport anonymisé remis avant signature, nos références et notre couverture d’assurance. Les questions à poser à un prestataire sont détaillées dans l’article comment choisir un prestataire de test d’intrusion.
09 À quelle fréquence faut-il refaire un pentest mobile ?
Deux éléments fixent le rythme. Si l’application traite des données personnelles, l’article 32.1.d du RGPD prévoit, le cas échéant, « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement ». C’est la base européenne la plus claire d’un test périodique. Ensuite compte votre rythme de publication : si vous livrez une version par mois, rattachez le test aux évolutions fonctionnelles majeures plutôt qu’au seul calendrier.
En pratique, la plupart de nos clients font réaliser un pentest une fois par an, avec un test ciblé à chaque refonte d’un parcours sensible. Un test d’intrusion est un constat technique, pas un avis juridique sur les obligations applicables à votre organisation.
Dernière vérification : 11 septembre 2026.
10 Pouvez-vous tester une application qui n’est pas encore publiée ?
Oui, et c’est le meilleur moment. Envoyez-nous une build signée — TestFlight, un APK ou un accès à un canal de distribution interne — et nous testons l’application avant qu’elle n’atteigne vos utilisateurs. Corriger avant la mise en ligne évite une mise à jour d’urgence et un nouveau passage en revue sur les stores.
Des exemples de missions conduites dans ces conditions figurent dans nos cas clients.
