Application Android pour nos clients : comment s'assurer que les développeurs ont codé proprement côté sécurité ?

Posez-leur cette question toute simple : « Si un utilisateur ouvre l'appli sur un téléphone rooté ou intercepte le trafic réseau via un proxy, est-ce qu'il peut voir les tokens d'authentification des clients ? » S'ils bafouillent, c'est que la sécurité est légère. Vous pouvez aussi installer l'APK sur un appareil de test et le scanner vous-même avec des outils d'analyse de sécurité open source gratuits.

Le serveur backend (l'API) auquel l'application se connecte est hébergé où, et qui a audité sa sécurité ? Dans les applications mobiles les fuites de données viennent rarement du téléphone lui-même, mais des failles d'autorisation sur l'API qui sert les données. Est-ce que la sécurité de l'API a été auditée ?

Si vous conservez des données cliniques et des commandes commerciales en Allemagne, vous êtes légalement tenu de documenter le principe de « privacy by design » conformément au DSGVO. Demandez au développeur de remplir une checklist de conformité aux normes de sécurité mobile de l'OWASP (MASVS). Qu'ils indiquent en face de chaque point les mesures prises et qu'ils signent le document. Vous verrez immédiatement s'ils sont prêts à assumer une responsabilité officielle.

Que les développeurs disent « tout est sécurisé », ça ne veut absolument rien dire. La plupart des freelances se contentent de copier-coller des blocs de code trouvés sur internet et d'y intégrer les clés d'API en clair. Tant qu'un regard extérieur et indépendant ne s'est pas penché dessus, ne croyez jamais qu'une appli est sécurisée.

regardez d'abord les autorisations de l'appli dans les paramètres du tel. bon si une appli qui prend juste des commandes demande l'accès aux fichiers à la localisation ou aux contacts c'est que le dév a juste copié-collé un template tout fait. les autorisations inutiles c'est le pire risque.

Le Google Play Store ne fait pas déjà passer des contrôles de sécurité aux applications lors de leur publication ? Si la boutique a validé est-on quand même obligé de faire faire des tests de sécurité supplémentaires ?

On a réceptionné une appli B2B similaire l'année dernière. Les développeurs avaient l'air super sûrs d'eux, mais on a quand même payé 2.500 EUR pour faire un pentest mobile indépendant. Le rapport a révélé que les mots de passe du serveur backend avaient été laissés en clair dans l'APK et que les tokens de session n'expiraient jamais. Si on n'avait pas mis cet argent, on allait droit au scandale.

La solution qui semble bon marché finit souvent par coûter cher. Une sauvegarde non testée n'est pas une sauvegarde.

je pense différemment. si c'est une premièer commencez petit l'échelle viendra plus tard.

c'est confirmé par l'expérience.

Chez moi, c'est l'inverse qui s'est passé, c'est pourquoi j'écris. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

je me permets une petite mise en garde. bref ne comptez pas sur une sule mesure de sécurité ; allez par couches.

si vous écrivez le résultat ici cela aiddera aussi d'autres personnes.

Je suis d'accord.

vous avez raison, je suis aussi passé par là. n'hésitez pas à demander celui qui ne demande pas paie toujours plus cher.

Mes doutes sont levés, merci. Si la double authentification est activée, un mot de passe volé seul ne suffit pas.

Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Vous avez raison. Le temps que vous mettez à détecter un problème détermine directement son coût.

Il y a un point qui m'interpelle. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

Voilà, désolé si je me suis étendu.

Je ne savais pas ça. Si la double authentification est activée un mot de passe volé seul ne suffit pas.

Je vais résumer ce qui a été dit jusqu'ici. Si c'est une première, commencez petit, l'échelle viendra plus tard.

Bon courage.