Un ingénieur sécurité applicative mobile doit d'abord connaître les deux plateformes au niveau des API. Le Keychain et le Secure Enclave d'un côté, l'Android Keystore et la Network Security Config de l'autre, avec leurs pièges propres. Le poste intervient en conception et en build : choix du stockage d'un jeton, plan de rotation du pinning, vérification des liens profonds, contrôles dans la CI, revue de chaque SDK que le marketing veut ajouter.
Deux profils se croisent. Le développeur iOS ou Android passé à la sécurité écrit du code juste mais pense parfois que l'obfuscation protège un secret. Le pentester mobile manie Frida et jadx mais a rarement porté une correction jusqu'en production ni négocié avec une équipe produit. Les meilleurs candidats savent dire ce qui ne peut pas être protégé côté téléphone et doit revenir au serveur.
Le référentiel commun est l'OWASP MASVS, en version 2.1 depuis janvier 2024, et son guide de tests, le MASTG. Le PDF associé contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Plateformes, référentiels et outils de la sécurité mobile
OWASP MASVS 2.1 et MASTG
Le standard de sécurité des applications mobiles et son guide de tests. La version 2.1 du MASVS, publiée en janvier 2024, compte huit groupes de contrôles, de MASVS-STORAGE à MASVS-PRIVACY. Le MASTG décrit comment vérifier chaque contrôle et a été publié en version 2.0 en juin 2026.
Keychain et Secure Enclave (iOS)
Le Keychain stocke les secrets de l'application avec des classes d'accessibilité qui décident quand ils sont lisibles et s'ils partent dans les sauvegardes. Le Secure Enclave garde des clés qui ne sortent jamais de la puce. La personne doit dire quelle classe elle choisit pour un jeton de session, et pourquoi.
Android Keystore et StrongBox
Le Keystore génère et utilise des clés non exportables, StrongBox les place dans une puce dédiée sur les appareils compatibles. Une clé peut exiger l'authentification de l'utilisateur, ce qui permet de lier la biométrie à une vraie opération cryptographique.
Network Security Config, App Transport Security et pinning
Les deux mécanismes de configuration réseau des plateformes. Ils interdisent le trafic en clair, fixent les autorités de confiance et portent le certificate pinning. Un pinning sans clé de secours peut couper tous les utilisateurs le jour d'un renouvellement de certificat.
Play Integrity API et App Attest
Les services d'attestation de Google et d'Apple. Ils permettent au serveur de vérifier qu'une requête vient d'une application authentique, sur un appareil sain. Play Integrity a remplacé l'attestation SafetyNet, arrêtée début 2025. Le verdict se vérifie côté serveur, jamais dans l'application.
Universal Links et Android App Links
Des liens profonds rattachés à un domaine vérifié, qu'une autre application ne peut pas revendiquer, à la différence des schémas personnalisés. Beaucoup de vols de jetons et d'actions déclenchées à distance passent par des liens profonds mal conçus.
Frida, Objection, jadx, MobSF
Les outils d'analyse : Frida et Objection pour instrumenter l'application en cours d'exécution, jadx pour décompiler un APK, MobSF pour l'analyse statique automatisée. L'ingénieur AppSec mobile s'en sert pour vérifier ses propres protections avant qu'un auditeur ne le fasse.
Obfuscation et protection à l'exécution
R8 réduit et renomme le code Android, des outils commerciaux ajoutent le chiffrement des chaînes et la détection de hook, de débogueur ou de modification. Ces protections ralentissent la rétro-ingénierie. Elles ne remplacent jamais un contrôle côté serveur.
Privacy manifests et Data safety
Les déclarations de confidentialité exigées par les magasins. Depuis le 1er mai 2024, Apple demande une raison approuvée pour certaines API et un manifeste signé pour une liste de SDK courants. Google Play impose sa section Data safety. Chaque SDK ajouté change ces déclarations.
Le poste existe surtout chez les éditeurs d'applications grand public et dans les équipes mobiles des grandes entreprises, souvent sous les titres d'ingénieur sécurité mobile, mobile security engineer ou expert AppSec mobile. Il se distingue du pentester mobile, qui audite une application terminée, et du développeur mobile, qui livre les fonctionnalités : l'ingénieur AppSec mobile écrit les exigences, revoit le code, outille la CI et suit les corrections. Selon la taille de l'équipe, il couvre aussi la sécurité des API appelées par l'application. Les certifications mobiles sont rares ; une expérience concrète sur Keychain, Keystore et une attestation côté serveur vaut davantage qu'un titre.
Les points techniques à vérifier chez un ingénieur sécurité mobile
- Stockage sécurisé sur iOS et Android
- Sécurité réseau et pinning
- Authentification mobile et sessions
- Liens profonds, WebView et composants
- Attestation et résistance à la modification
- Chaîne de build, SDK tiers et vie privée
Les questions sur une application iOS ou Android à sécuriser
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
La session de l'utilisateur doit rester ouverte trente jours. Où et comment stockez-vous le refresh token, sur iOS et sur Android ?
Une bonne réponseSur iOS, dans le Keychain, avec une classe d'accessibilité de type ThisDeviceOnly (kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly par exemple) pour que l'élément ne parte pas dans une sauvegarde restaurée sur un autre téléphone. Sur Android, chiffré par une clé non exportable de l'Android Keystore, dans StrongBox quand l'appareil en dispose, et rangé dans le stockage privé de l'application. Côté serveur, le jeton tourne à chaque usage, reste lié à l'appareil et se révoque.
Signal d'alerteUserDefaults ou SharedPreferences en clair, ou « le téléphone est chiffré, donc pas besoin ».
Question 2 · confirmé à senior
L'équipe veut ajouter du certificate pinning. Que pinnez-vous, et comment évitez-vous de bloquer tous les utilisateurs le jour où le certificat change ?
Une bonne réponseLa clé publique (empreinte SPKI) plutôt que le certificat final, avec au moins une empreinte de secours pour une clé de réserve, ou l'autorité intermédiaire selon le niveau de contrôle sur les certificats. Sur Android, un pin-set dans la Network Security Config avec une date d'expiration. Sur iOS, NSPinnedDomains dans l'Info.plist ou une vérification dans le délégué URLSession. Il prévoit la rotation : nouvelle version publiée avec la future empreinte bien avant le changement. Il rappelle que le pinning protège l'utilisateur d'une interception, pas le serveur d'un client modifié.
Signal d'alerteÉpingler le certificat feuille sans clé de secours ni plan de rotation.
Question 3 · confirmé
Pourquoi la connexion OAuth d'une application mobile doit-elle passer par le navigateur système plutôt que par une WebView intégrée ?
Une bonne réponseLa RFC 8252 sur OAuth pour les applications natives le recommande. Dans une WebView intégrée, l'application peut lire les identifiants saisis, l'utilisateur ne voit pas l'adresse et la session du navigateur n'est pas partagée. On utilise ASWebAuthenticationSession sur iOS et les Custom Tabs sur Android, avec PKCE parce que l'application est un client public sans secret, et une redirection par Universal Link ou App Link vérifié plutôt que par un schéma personnalisé qu'une autre application peut revendiquer.
Signal d'alerteUne WebView avec un client secret embarqué dans l'application.
Question 4 · confirmé à senior
Un lien du type monapp://profil/email?nouveau=… ouvre directement l'écran qui change l'adresse e-mail. Quels risques voyez-vous, et que changez-vous ?
Une bonne réponseN'importe quelle page web ou application peut déclencher un schéma personnalisé, et une autre application peut déclarer le même schéma pour intercepter les liens et les jetons qu'ils transportent. Il passe aux Universal Links et aux Android App Links vérifiés par les fichiers apple-app-site-association et assetlinks.json, traite chaque paramètre comme une entrée non fiable et exige confirmation et réauthentification avant toute action sensible.
Signal d'alerteFaire confiance aux paramètres du lien parce qu'il « vient de notre site ».
Question 5 · senior
Le métier demande une détection du root et du jailbreak. Que lui répondez-vous, et que mettez-vous en place ?
Une bonne réponseUne détection locale se contourne avec Frida, Magisk et ses modules de masquage : elle augmente le coût de l'attaque sans rien garantir. Il combine une attestation vérifiée côté serveur (Play Integrity API, App Attest d'Apple), une protection à l'exécution (détection de hook, de débogueur, d'émulateur, de signature modifiée) et une réponse graduée décidée par le serveur, qui limite les opérations sensibles plutôt que de fermer l'application. Il réserve ces protections aux applications dont le modèle de menace les justifie, comme le prévoit le groupe MASVS-RESILIENCE.
Signal d'alerte« On bloque l'application sur les téléphones rootés et c'est réglé », ou à l'inverse « ça ne sert à rien ».
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Sécurité applicative mobile : questions fréquentes
Faut-il un profil iOS ou un profil Android ?
L'idéal est un profil qui lit le code des deux plateformes, même s'il a développé sur une seule. Les mécanismes se répondent (Keychain et Keystore, ATS et Network Security Config, Universal Links et App Links) mais les pièges diffèrent. Si le parc penche nettement vers une plateforme, elle passe en premier, et l'entretien vérifie que la personne connaît au moins les équivalents de l'autre côté.
En quoi ce poste diffère-t-il de celui de pentester mobile ?
Le pentester mobile audite une application livrée, souvent pour plusieurs clients, et rend un rapport. L'ingénieur sécurité applicative mobile travaille dans l'équipe, avant et après l'audit : il choisit le stockage des secrets, écrit les exigences, configure les contrôles de la CI et fait corriger les constats. Un bon pentester peut faire ce métier s'il accepte de concevoir et de suivre des corrections dans la durée.
Quel test technique pour ce poste ?
Le support est un APK ou un projet de test préparé par l'équipe, avec une clé d'API en dur, un composant exporté sans protection, un lien profond qui déclenche une action et un jeton stocké en clair. La personne dispose d'une heure pour trouver les problèmes avec les outils de son choix, puis vingt minutes pour expliquer les corrections. La seconde partie compte autant que la première.
La détection du root et du jailbreak doit-elle faire partie des attentes ?
Elle fait partie du sujet, mais un bon candidat la remet à sa place. Une détection locale se contourne et ne vaut que combinée à une attestation vérifiée par le serveur et à des contrôles côté API. Un signal d'alerte : le profil qui présente le blocage des appareils rootés comme la protection principale d'une application, ou qui propose d'ajouter une protection commerciale sans parler du modèle de menace.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
