Sécurité : Applications mobiles - conception et développement

Les applications mobiles sont l’un des principaux moyens d’accès à des contenus et des services numériques et impliquent pour la plupart le traitement de données personnelles. Il est nécessaire pour les éditeurs de sécuriser ces traitements et d’offrir la meilleure transparence possible aux utilisateurs.

Les précautions élémentaires

Minimiser les traitements de données personnelles mis en œuvre en s’assurant que chaque type de données collectées est bien nécessaire au fonctionnement de l’application.

Choisir, lors de leur sélection, les permissions pertinentes au fonctionnement de l’application et impliquant le minimum de collecte supplémentaire, voire proposer des alternatives à l’utilisateur ne reposant pas sur des permissions (ex. : la géolocalisation permet de simplifier une recherche géographique, mais peut être remplacée par la saisie manuelle de l’adresse).

Sécuriser les communications, au moins avec les serveurs, en les encapsulant dans un canal TLS, en respectant le guide TLS de l’ANSSI.

Stocker les secrets cryptographiques par empaquetage au moyen d’API permettant l’utilisation des suites cryptographiques incluses dans le téléphone, en privilégiant les protections matérielles telles que le « Hardware Keystore » d’Android ou la « Secure Enclave » d’Apple.

Prendre en compte la possibilité que le système d’exploitation effectue des sauvegardes automatiques des données personnelles, quelles qu’elles soient. Désactiver les sauvegardes non souhaitées ou procéder à un chiffrement des données sans inclure la clé de chiffrement dans les sauvegardes.

Recourir à un moyen d’authentification correspondant au niveau de sécurité recherché lorsqu’une authentification est nécessaire (ex. : si une personne doit être authentifiée avec certitude, ne pas recourir à un moyen d’authentification biométrique si le dispositif utilisé permet l’enregistrement de gabarits biométriques de plusieurs personnes).

Ce qu'il ne faut pas faire

Contractualiser avec un développeur pour la réalisation d’une application sans formaliser avec lui les objectifs et les mesures techniques attendus en termes de sécurité des données et sans préciser que ces exigences sont applicables aux sous-traitants ultérieurs (voir la fiche n°14 - Gérer la soustraitance).

Intégrer ou laisser à son sous-traitant la latitude d’intégrer dans son application des éléments de code extérieurs (ou SDK), y compris ceux proposés par les éditeurs des systèmes d’exploitation mobiles, sans s’assurer qu’ils respectent eux-mêmes les précautions de sécurité à l’état de l’art.

Pour aller plus loin

• De manière générale, respecter les niveaux L1 et L2 des recommandations produites par l’OWASP.
   
• Le modèle de sécurité des applications mobiles ne devrait pas se reposer sur l’intégrité du terminal (via une attestation mise à disposition par le système d’exploitation), sauf dans certains cas justifiés. Le service devrait être conçu de manière à maintenir le niveau de sécurité même avec des terminaux considérés corrompus. Les bonnes pratiques en termes d’API (voir la fiche n°25 - API : Interfaces de programmation applicative) devraient être appliquées pour sécuriser les serveurs utilisés par l’application et les protéger contre des éventuelles tentatives d’abus.
   
• Privilégier le traitement et le stockage des données de l’utilisateur directement sur son terminal.
   
• Il est souhaitable que l’éditeur d’une application mette en place un processus de validation de toutes les modifications apportées au traitement mis en œuvre, notamment en termes de sécurité, afin d’éviter que des évolutions (ex. : opérations de maintenance, modification de composants externes) ne viennent impacter la sécurité globale du traitement.
   
• Il est important de mettre en œuvre des processus qui assurent le maintien de la sécurité de l’application au cours du temps, notamment :
  • en adoptant une méthodologie d’intégration et de déploiement continus (CI/CD en anglais) pour permettre des mises à jour fréquentes des applications, notamment en cas de mise à jour de sécurité ;
  • en informant les utilisateurs de la disponibilité de mises à jour critiques (ex. : un bandeau d’information), voire en bloquant certaines fonctionnalités au niveau du serveur pour les versions non sécurisées de l’application ;
  • en maintenant la vigilance relative aux éléments externes intégrés dans les applications, notamment face au risque d’évolution malveillante dans les SDKs ou les bibliothèques utilisés, via des pratiques de sécurisation de la chaîne d’approvisionnement (ou « supplychain security ») tel que décrit dans les analyses de l’ANSSI ;
  • en s’assurant que le niveau de sécurité attendu puisse rester le même, le plus longtemps possible, indépendamment de la version de l’OS utilisée. De sorte qu’un utilisateur qui ne souhaiterait ou ne pourrait pas accéder à un appareil récent puisse bénéficier d’un niveau de sécurité suffisant.