Test de pénétration d'appli mobile avant de payer — est-ce qu'on a une checklist sécu qu'on peut appliquer nous-mêmes ?

Faites faire ces trois contrôles à votre équipe dès demain : 1) Désactivez les logs de l'appli, jamais d'infos client ou de token dans les sorties console. 2) Assurez l'effacement automatique des données sensibles copiées dans le presse-papiers de l'appareil. 3) Testez comment l'appli se comporte sur des appareils avec accès root.

Vous pouvez intégrer des outils d'analyse statique open source dans votre process de build. Y'a des outils gratuits qui scannent votre code automatiquement et listent en quelques minutes les clés cachées et les fonctions de stockage non sécurisées. Ne payez pas un test externe sans les avoir lancés, je vous le dis.

On a fait la même erreur l'an dernier. On a payé 4 200 livres pour le test, sur les 12 findings du rapport, 9 étaient des clés de test oubliées dans le code et des fichiers de cache local non chiffrés. Si on avait regardé avant, les auditeurs auraient pu se concentrer sur le flux de paiement qu'ils devaient vraiment creuser.

Votre checklist à vous c'est une très bonne idée mais voyez-la jamais comme un substitut au test de pénétration officiel. Quand on cherche les failles de son propre code la cécité d'équipe est inévitable. Ces contrôles doivent servir non pas à annuler le test mais à en avoir pour son argent.

nous on utilise une infra hybride, donc l'appli tourne en fait dans une webview. ces contrôles de stockage local et de certificat dont vous parlez s'appliquent aussi pareil aux applis hybrides ?

faites très gaffe au truc des clés api secrètes oubliées dans le repo de code. notre équipe avait push en prod une clé temporaire écrite pour l'env de test, on l'a remarqué au dernier moment. ça se chope même avec une simple recherche dans le repo.

Y'a deux ans, sur la première version de notre appli de livraison, un client avait réussi à intercepter avec un simple outil proxy et à mettre le montant de sa propre commande à 0 livre. Parce qu'on calculait le prix dans l'appli mobile et qu'on l'envoyait comme ça au serveur. Depuis ce jour, on fait zéro confiance au client mobile.

Vous êtes sur une très bonne voie. Les boîtes de sécu proposent des recommandations de correction standard pour chaque finding mais corriger votre code vous revient quand même. Si vous épuisez votre checklist et arrivez chez la boîte avec une base propre, le temps de test passe beaucoup plus efficacement et le rapport que vous recevez devient un gage de prestige dans vos ventes B2B.

je ne saavais pas ça.

Chez nous, ça s'est passé comme ça. N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher.

Je trouve difficile d'être aussi catégorique côté checklist sécurité application mobile. Le temps que vous mettez à détecter un problème détermine directement son coût.

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

Il y a un piège ici je ne pouvais pas ne pas le mentionner. Les décisions hâtives finissent par être corrigées six mois plus tard.

Quand on essaie de tout changer en même temps, rien ne prend.

Merci de partager le résultat.

Merci pour votre retour.

Le point le plus souvent négligé concernant checklist sécurité application mobile est : Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

Je suis aussi curieux de savoir si d'autres font autrement.

Séparons les concepts, ils sont souvent confondus. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

Je suis aussi curieux de savoir si d'autres font autrement.

Sujet très actuel. Ne comptez pas sur une seule mesure de sécurité ; allez par couches.

Vous avez raison.