Tests d'intrusion · API
API
Pentest API selon l'OWASP API Security Top 10 2023 : autorisation au niveau des objets, OAuth 2.0, JWT, GraphQL et webhooks. Rapport avec preuves et retest.
Tests d'intrusion · Applications mobiles
Pentest mobile : test d'intrusion d'applications iOS et Android
Un pentest mobile vérifie si les données de vos clients sont en sécurité sur le téléphone, pendant leur transmission vers le serveur et dans le backend lui-même. Nous testons les applications iOS et Android selon l'OWASP MASVS et le MASTG - analyse statique et dynamique, pour chaque plateforme séparément, avec l'API à laquelle l'application se connecte.
01Pourquoi
Ce qui peut mal tourner dans une application mobile
Une application mobile s'exécute sur un appareil que vous ne contrôlez pas. L'utilisateur - ou l'attaquant - peut la décompresser, observer son trafic réseau, modifier son comportement et envoyer au serveur n'importe quelle requête. Les problèmes que nous rencontrons le plus souvent :
- données sensibles stockées sur le téléphone sans chiffrement - jetons, données personnelles, fichiers en cache,
- clés et adresses codées en dur dans l'application, qui donnent accès au backend ou à des services tiers,
- vérification TLS insuffisante, qui permet d'intercepter et de modifier les communications,
- sécurité assurée par l'application et non par le serveur - par exemple des fonctions premium masquées ou des limites vérifiées uniquement sur le téléphone,
- failles d'autorisation dans l'API utilisée par l'application.
02Périmètre
Périmètre : pentest mobile selon l'OWASP MASVS
Le MASVS 2.1 répartit les exigences en huit groupes. Nous réalisons les tests selon les procédures de l'OWASP MASTG.
| Groupe MASVS | Ce que nous vérifions |
|---|---|
| MASVS-STORAGE | Données sensibles sur l'appareil : fichiers, bases de données, préférences, cache, journaux, sauvegardes, presse-papiers. |
| MASVS-CRYPTO | Algorithmes et modes de chiffrement, génération et stockage des clés, utilisation du magasin de clés du système. |
| MASVS-AUTH | Connexion, session et jetons, biométrie, authentification locale et son lien avec le serveur. |
| MASVS-NETWORK | Configuration TLS, validation des certificats, certificate pinning lorsqu'il se justifie. |
| MASVS-PLATFORM | Autorisations, communication entre applications, liens profonds, WebView, captures d'écran et notifications. |
| MASVS-CODE | Dépendances présentant des vulnérabilités connues, validation des entrées, mise à jour forcée. |
| MASVS-RESILIENCE | Protection contre la rétro-ingénierie, la modification et l'exécution sur un appareil rooté ou jailbreaké - lorsqu'elle est requise. |
| MASVS-PRIVACY | Minimisation des données collectées, identifiants de l'appareil, transmission de données à des bibliothèques et services tiers. |
03Méthodes
Analyse statique et dynamique
Analyse statique
Nous décompressons l'application et analysons son code et ses ressources sans l'exécuter : nous recherchons les clés et adresses codées en dur, et vérifions la configuration (manifeste, autorisations, paramètres de sécurité réseau), les bibliothèques tierces et leurs versions, ainsi que l'usage qui est fait de la cryptographie.
Analyse dynamique
Nous exécutons l'application sur des appareils de test et observons son fonctionnement : trafic réseau, écritures sur l'appareil, comportement en cas d'interruption de session ou de modification des données dans les requêtes. Nous vérifions aussi ce qu'il est possible d'obtenir en modifiant l'application - car un attaquant fera exactement la même chose sur son propre téléphone.
04Plateformes
iOS et Android : ce qui change dans le test
| Domaine | iOS | Android |
|---|---|---|
| Stockage des secrets | Keychain et classes de protection des données | Android Keystore, EncryptedSharedPreferences |
| Communication entre applications | Schémas d'URL, Universal Links, extensions | Intents, composants exportés, App Links |
| Configuration réseau | App Transport Security | Network Security Configuration |
| Distribution de test | TestFlight ou fichier IPA | Fichier APK ou AAB, tests fermés sur Google Play |
| Erreurs typiques | Données dans des fichiers sans classe de protection, schémas d'URL trop larges | Activités exportées, données en stockage externe, journaux |
Nous testons les applications multiplateformes (Flutter, React Native et similaires) sur les deux systèmes : un code partagé ne signifie pas des failles partagées, car chaque plateforme stocke les données et gère les autorisations à sa manière.
05Déroulement
Comment se déroule le test d'une application mobile
Les étapes du test - de la version de test de l'application jusqu'au retest (contre-test) après la publication de la version corrigée.
-
Version de test et comptes
Fichier de l'application ou accès via TestFlight ou les tests fermés de Google Play, comptes pour chaque rôle, informations sur le backend.
-
Analyse statique
Code et ressources de l'application sans exécution : configuration, autorisations, clés, bibliothèques, cryptographie.
-
Analyse dynamique
L'application sur des appareils de test : données écrites sur le téléphone, trafic réseau, comportement après modification.
-
Test de l'API
Requêtes de l'application vers le serveur : authentification, jetons, accès aux données d'autres utilisateurs, validation côté serveur.
-
Rapport
Vulnérabilités réparties entre iOS, Android et backend - avec preuves, score CVSS et recommandations pour chaque équipe.
-
Retest
Vérification des correctifs dans la nouvelle version de l'application et du backend, mise à jour du rapport.
Nous rédigeons le rapport de sorte que chaque équipe sache immédiatement ce qui la concerne : des constats distincts pour l'application iOS, l'application Android et le backend, chacun rattaché à l'exigence MASVS concernée. Il est ainsi facile de planifier les corrections dans la prochaine version et de les vérifier lors du retest, avant que la nouvelle version n'arrive sur les stores.
06Backend
Une application, c'est aussi une API
La plupart des données d'une application mobile résident sur le serveur. Même l'application la mieux protégée ne sert à rien si l'API permet de récupérer les données d'un autre utilisateur en modifiant un identifiant, ou si elle accepte sans vérification un prix ou des droits transmis par l'application. C'est pourquoi notre test d'application mobile couvre toujours l'API dans la mesure où l'application l'utilise : authentification, jetons, autorisation au niveau des objets et données envoyées au serveur. Nous vérifions également si le serveur est capable d'imposer une mise à jour et de rejeter les anciennes versions de l'application présentant des vulnérabilités connues, lorsque votre politique de sécurité l'exige.
Si l'API ne sert pas uniquement cette application, son périmètre complet est décrit sur notre page pentest API. Vous trouverez une présentation des approches et des offres sur la page test d'intrusion, et les facteurs de prix sur notre page tarifs des tests d'intrusion.
Questions fréquentes
Testez-vous les deux plateformes, iOS et Android ?
Oui. Nous testons chaque plateforme séparément, car elles diffèrent par leur manière de stocker les données, par leur gestion des autorisations et par les mécanismes de sécurité du système. L'API backend utilisée par les deux versions n'a besoin d'être testée qu'une fois - c'est pourquoi tester les deux plateformes ne coûte pas deux fois plus cher qu'en tester une seule.
De quoi avez-vous besoin pour tester une application mobile ?
Du fichier de l'application (IPA pour iOS, APK ou AAB pour Android) en version de test, ou d'un accès via TestFlight ou une piste de test fermée sur Google Play, de comptes de test pour chaque rôle et d'informations sur l'environnement backend. Le code source n'est pas obligatoire, mais il accélère l'analyse et permet d'aller plus loin - nous combinons alors le test avec un audit de code source.
Une application multiplateforme (Flutter, React Native) nécessite-t-elle un autre test ?
Le périmètre est le même : les exigences du MASVS portent sur le comportement de l'application, pas sur la technologie. C'est l'outillage d'analyse statique qui change, car la logique n'est pas empaquetée de la même façon que dans une application native. Nous vérifions les plateformes et leurs mécanismes de sécurité exactement comme pour les applications natives.
Les protections contre la modification de l'application sont-elles indispensables ?
Pas toujours. La protection contre la rétro-ingénierie et la modification (groupe MASVS-RESILIENCE) se justifie dans les applications bancaires, de paiement ou à contenu payant. Dans les autres applications, l'essentiel est que la sécurité ne dépende pas de ce qui se passe sur le téléphone - car un attaquant peut toujours contrôler son propre appareil.
Le test couvre-t-il le backend auquel l'application se connecte ?
Oui, dans la mesure où l'application l'utilise : authentification, autorisation et données envoyées au serveur. Si la même API sert aussi des partenaires ou une application web, envisagez un pentest API complet.
Sources
Services associés
Logiciel sur mesure · Applications mobiles
Applications mobiles
Développement d'applications mobiles iOS et Android pour les entreprises : natives ou multiplateformes, backend sécurisé, stores et OWASP MASVS.
Tests d'intrusion · Tarifs
Tarifs
Quel est le prix d'un pentest ? Ce qui détermine le coût d'un test d'intrusion, nos offres, la checklist de demande et les pièges de l'offre la moins chère.