Sécurité d'une application mobile : l'OWASP MASVS appliqué

La sécurité d'une application mobile part d'un constat : l'application tourne sur un appareil que son éditeur ne contrôle pas, qui peut être perdu, prêté ou modifié, et son code peut être lu. L'OWASP MASVS (Mobile Application Security Verification Standard) liste les exigences de sécurité d'une application mobile en huit catégories, et le MASTG (Mobile Application Security Testing Guide) explique comment les vérifier. Ce chapitre applique le MASVS à AppliFrais Mobile, catégorie par catégorie, avec ce que le code des chapitres précédents fait déjà et ce qu'il reste à faire. Les risques des API et le cadre général de la sécurité applicative sont dans le cours Sécurité des applications.

Une application mobile est un client non fiable

Tout ce qui est dans l'application est entre les mains de l'utilisateur, et d'un éventuel attaquant :

• le code se lit : un APK ou une IPA se décompresse et se décompile avec des outils gratuits ; le bundle JavaScript, même compilé en bytecode Hermes, garde ses chaînes de caractères lisibles. L'adresse de l'API d'AppliFrais, injectée par EXPO_PUBLIC_API_URL, se retrouve en clair dans le fichier compilé ;
• le code se modifie : sur un téléphone rooté (Android) ou jailbreaké (iOS), des outils d'instrumentation changent le comportement de l'application pendant son exécution, par exemple pour forcer un test à « vrai » ;
• l'appareil se perd : un téléphone volé, ou prêté à un collègue, donne accès à ce qui est stocké et affiché ;
• les communications passent par des réseaux inconnus : le Wi-Fi d'un hôtel, d'une gare, d'un hôpital.

D'où les deux règles qui résument la sécurité d'un client mobile : aucun secret dans l'application, et tout contrôle de sécurité refait par le serveur. Ces deux règles viennent du cours sécurité ; le MASVS les décline en exigences vérifiables.

OWASP MASVS, MASTG et Mobile Top 10

Le MASVS est l'équivalent mobile de l'ASVS du Web. Tous les contrôles ne s'appliquent pas à toutes les applications : le projet OWASP MAS définit des profils, du niveau de base, qui convient à toute application, aux exigences renforcées d'une application qui manipule des données sensibles (santé, banque), et à la résilience contre la rétro-ingénierie, réservée aux applications qui protègent un modèle économique ou un secret industriel.

Les huit catégories appliquées à AppliFrais

Les sections qui suivent détaillent chaque catégorie.

Stockage : ce qui reste sur le téléphone

MASVS-STORAGE-1 demande de ranger les données sensibles dans le stockage prévu par la plateforme. Dans AppliFrais, le seul secret durable, le jeton de rafraîchissement, est dans SecureStore ; le jeton d'accès ne quitte pas la mémoire (chapitre 7).

MASVS-STORAGE-2 demande d'empêcher les fuites, qui passent souvent par des chemins inattendus :

Pour un écran qui affiche des données sensibles, le module expo-screen-capture bloque les captures d'écran et masque l'aperçu dans le sélecteur d'applications sur Android :

import { usePreventScreenCapture } from 'expo-screen-capture';

export function EcranSensible() {
  usePreventScreenCapture(); // actif tant que l'écran est affiché
  // …
}

Sur iOS, la fonction enableAppSwitcherProtectionAsync du même module floute l'aperçu de l'application dans le sélecteur. Ces protections gênent aussi l'utilisateur légitime (impossible de faire une capture pour le support) : réserve-les aux écrans qui le méritent.

Cryptographie : ne rien inventer

MASVS-CRYPTO demande des algorithmes actuels et une bonne gestion des clés. Pour une application de gestion, la règle tient en une phrase : ne chiffre rien toi-même. Le transport est chiffré par HTTPS (TLS), le stockage des secrets par SecureStore, qui s'appuie sur des clés matérielles du Keystore et du trousseau. Les erreurs classiques à repérer dans un code (et dans un sujet d'E7) : une clé de chiffrement écrite en dur dans le code, un algorithme dépassé (MD5, SHA-1, DES, AES en mode ECB), un « chiffrement » qui n'est qu'un encodage Base64. Les principes sont dans le cours Cryptographie.

Authentification : le serveur reste le juge

MASVS-AUTH-1 porte sur le protocole : AppliFrais utilise un jeton d'accès de 15 minutes et un jeton de rafraîchissement révocable, avec rotation, et la déconnexion révoque le jeton côté serveur (chapitre 6). Surtout, chaque contrôle d'accès est refait par l'API : la garde d'Expo Router cache des écrans, elle ne protège aucune donnée. Une faille BOLA dans l'API (lire la fiche d'un autre visiteur en changeant l'identifiant) se corrige sur le serveur, jamais dans l'application.

MASVS-AUTH-2 porte sur l'authentification locale : la biométrie doit passer par les mécanismes du système (BiometricPrompt sur Android, LocalAuthentication sur iOS, que expo-local-authentication utilise), et idéalement débloquer une clé plutôt que renvoyer un simple booléen (chapitre 9).

MASVS-AUTH-3 demande une authentification renforcée pour les opérations sensibles. Dans AppliFrais, la clôture d'une fiche, qui la rend définitive, pourrait redemander l'empreinte ; dans une application bancaire, un virement redemande toujours une confirmation.

Réseau : HTTPS partout

MASVS-NETWORK-1 exige que tout le trafic soit chiffré et que les certificats soient vérifiés. Android (depuis la version 9 pour les applications récentes) et iOS (App Transport Security) refusent par défaut le HTTP en clair dans une application publiée. Les erreurs à ne jamais commettre :

• réautoriser le HTTP en clair « pour que ça marche » (option usesCleartextTraffic sur Android, exceptions ATS sur iOS) ;
• désactiver la vérification des certificats pendant les tests : ce code finit en production ;
• envoyer un jeton dans l'adresse (?token=…), qui finit dans les journaux des serveurs et des proxys.

MASVS-NETWORK-2 concerne l'épinglage de certificat (certificate pinning) : l'application n'accepte que le certificat, ou la clé publique, attendu pour le serveur de l'éditeur, même si une autorité de certification compromise en délivrait un autre. Il protège mieux, mais complique le renouvellement des certificats : un épinglage mal géré rend l'application inutilisable le jour où le certificat change. Pour AppliFrais, il n'est pas retenu ; c'est un choix à justifier dans la documentation, pas un oubli. Une application de santé ou de paiement l'adopterait, avec une clé de secours.

Plateforme : liens profonds, WebView et écran

MASVS-PLATFORM-1 concerne les échanges avec les autres applications, et d'abord les liens profonds (chapitre 4). N'importe quelle application ou page web peut ouvrir applifrais://fiche/12 ; le lien est donc une entrée non fiable :

• valider chaque paramètre (Number.isInteger(Number(id))) avant de l'utiliser ;
• ne jamais déclencher une action (supprimer, clôturer, valider) depuis un lien sans que l'utilisateur la confirme dans l'application ;
• ne jamais mettre de jeton ni de donnée sensible dans un lien.

Un autre risque touche les schémas personnalisés : rien n'empêche une autre application de déclarer le même schéma applifrais:// et d'intercepter les liens. Pour un lien qui transporte quelque chose d'important (un retour d'authentification OAuth, par exemple), on utilise les App Links et Universal Links, liés à un domaine vérifié.

MASVS-PLATFORM-2 concerne les WebView. AppliFrais n'en a pas. Une application qui en affiche une ne doit y charger que ses propres pages, en HTTPS, sans exposer de fonctions natives au JavaScript de la page ; une WebView qui ouvre n'importe quelle adresse reçue devient une porte d'entrée.

MASVS-PLATFORM-3 concerne l'interface : masquer les champs sensibles, protéger les écrans sensibles des captures (vu plus haut), ne pas afficher plus de données que nécessaire.

Code : versions, dépendances et entrées

MASVS-CODE-1 demande une version de système récente : le SDK 58 fixe le minimum à Android 7 et iOS 16.4, et tenir le SDK à jour fait suivre ces minimums.

MASVS-CODE-2 demande un mécanisme pour imposer une mise à jour. Au démarrage, l'application demande à l'API la version minimale acceptée et la compare à la sienne (Constants.expoConfig?.version, de expo-constants) ; si elle est trop ancienne, elle affiche un écran qui renvoie vers le magasin. Sans ce mécanisme, une version vulnérable reste en circulation indéfiniment.

MASVS-CODE-3 interdit les composants vulnérables connus. Une application Expo embarque des centaines de dépendances npm :

npm audit                # vulnérabilités connues des dépendances
npx expo install --check # versions incompatibles avec le SDK
npx expo-doctor          # problèmes de configuration

La gestion des dépendances, les SBOM et l'automatisation dans la chaîne d'intégration sont dans le cours Sécurité des applications.

MASVS-CODE-4 demande de valider toutes les entrées : la saisie (validation dans l'application et dans l'API), les réponses de l'API, les liens profonds, les QR codes, les notifications. Et les requêtes SQLite locales sont préparées, comme sur un serveur (chapitre 7).

Résilience : freiner la rétro-ingénierie

MASVS-RESILIENCE regroupe les mesures qui ralentissent un attaquant qui analyse ou modifie l'application : détection d'un téléphone rooté ou jailbreaké, vérification de l'intégrité de l'application, offuscation du code, détection d'un débogueur. Elles ne remplacent jamais les autres contrôles : un attaquant motivé les contourne. Elles se justifient pour une application qui protège un modèle économique (un jeu, un service payant), des données très sensibles, ou contre la fraude. Pour AppliFrais, dont la sécurité repose sur l'API, elles ne sont pas exigées : la compilation de publication Android raccourcit déjà les noms du code Java et Kotlin (R8), et le bytecode Hermes rend la lecture du JavaScript moins immédiate, sans plus.

Vie privée : collecter le minimum

MASVS-PRIVACY, ajoutée dans la version 2 du MASVS, rejoint le RGPD :

• minimiser (PRIVACY-1) : demander la caméra mais ni la photothèque ni le micro (chapitre 8), la position au premier plan et approximative, réduite à une commune ;
• ne pas permettre l'identification au-delà du nécessaire (PRIVACY-2) : pas d'identifiant publicitaire, pas de bibliothèque de mesure d'audience qui envoie l'identifiant de l'appareil à un tiers ;
• être transparent (PRIVACY-3) : la politique de confidentialité, le formulaire Sécurité des données de Google Play, les étiquettes App Privacy d'Apple, qui doivent décrire exactement ce que fait l'application ;
• laisser l'utilisateur maître (PRIVACY-4) : désactiver le rappel, refuser la position, se déconnecter en effaçant les données locales, demander la suppression de son compte.

Ces obligations découlent du RGPD : finalité, minimisation, information, droits des personnes (le RGPD au BTS SIO).

Vérifier : le MASTG et la revue de code

Le MASTG décrit, pour chaque contrôle, comment le tester : par une revue du code source, par l'analyse du fichier compilé (analyse statique), et par l'observation de l'application en fonctionnement (analyse dynamique). Pour un projet de BTS, la vérification réaliste combine :

• une revue de code avec une liste de contrôle tirée du tableau des huit catégories ;
• npm audit et npx expo-doctor dans la chaîne d'intégration continue ;
• des tests de refus dans la recette : jeton expiré, fiche d'un autre visiteur, lien profond avec un identifiant invalide, permission refusée ;
• une analyse de l'APK par un outil d'analyse statique open source comme MobSF (Mobile Security Framework), qui signale les permissions, les configurations dangereuses et les secrets visibles dans le fichier.

const CLE_API_CARTO = 'sk_live_8f2b…';

export async function connexion(login: string, motDePasse: string) {
  const reponse = await fetch(`http://api.gsb.example/v1/auth/connexion?login=${login}&mdp=${motDePasse}`);
  const corps = await reponse.json();
  await Storage.setItem('motDePasse', motDePasse);
  if (corps.role === 'comptable') router.replace('/validation');
}