Guide : sécuriser une application de paiement mobile

Une application de paiement concentre tout ce qu'un attaquant recherche : de l'argent, des identifiants et des données personnelles. Elle vit sur des appareils que vous ne contrôlez pas, sur des réseaux que vous ne contrôlez pas non plus. La sécurité ne s'ajoute pas à la fin ; elle se conçoit avec le produit. Ce guide rassemble les contrôles que nous mettons en place sur les portefeuilles, les applications bancaires et les solutions de paiement marchand que nous construisons.

Le modèle de menace

Avant de choisir des contrôles, il faut nommer ce contre quoi on se protège :

• Le vol d'identifiants : hameçonnage, mots de passe réutilisés, codes à usage unique interceptés.
• L'appareil compromis : téléphone rooté ou jailbreaké, application modifiée, logiciel espion qui lit l'écran.
• L'interception réseau : point d'accès malveillant, certificat frauduleux, rejeu de requêtes.
• La fraude interne : accès trop larges au back-office, absence de journal, opérations manuelles non tracées.
• L'ingénierie sociale : la victime effectue elle-même l'opération sous pression ou par confiance.

Douze contrôles indispensables

1. Authentification forte, avec une biométrie liée à l'appareil pour les opérations courantes et un second facteur pour les opérations sensibles.
2. Enrôlement des appareils : chaque téléphone est enregistré ; un nouvel appareil déclenche une vérification supplémentaire et une notification.
3. Chiffrement en transit et au repos, avec des algorithmes actuels et des clés gérées hors du code.
4. Épinglage de certificats pour empêcher l'interception par un certificat frauduleux.
5. Stockage sécurisé : secrets et jetons dans le coffre du système (Keychain, Keystore), jamais dans un fichier en clair ni dans les journaux.
6. Intégrité de l'application et de l'appareil : signaux de root ou de jailbreak, attestation du système, refus ou dégradation des fonctions sensibles.
7. Limitation de débit et anti-automatisation sur l'authentification, les codes à usage unique et les transferts.
8. Tokenisation : le numéro de carte complet ne transite jamais par l'application ni par vos serveurs ; seuls des jetons circulent, conformément aux exigences de la norme PCI DSS.
9. Confirmation explicite des opérations sensibles : montant, bénéficiaire et frais affichés, confirmation séparée, délai de réflexion pour les nouveaux bénéficiaires.
10. Journalisation et supervision : chaque opération est tracée avec son contexte, et des règles d'anomalie déclenchent des alertes et des blocages temporaires.
11. Revue de code et tests d'intrusion réguliers, en s'appuyant sur le référentiel OWASP MASVS pour les applications mobiles.
12. Plan de réponse aux incidents : qui décide, comment on bloque, comment on informe les clients et les autorités, et comment on tire les leçons.

Ce que dit l'industrie

Les standards existent et évitent de réinventer : la norme PCI DSS encadre tout traitement de données de carte ; le référentiel OWASP MASVS décrit les exigences de sécurité d'une application mobile et les tests associés ; les protocoles d'authentification des paiements en ligne, comme 3-D Secure, ajoutent une vérification du porteur lors des achats à distance. Les réseaux de mobile money imposent leurs propres règles d'intégration. Les connaître tôt évite des surprises au moment de la certification ou du raccordement.

Organiser la sécurité dans l'équipe

• Un responsable identifié, qui tranche et rend compte.
• Des exigences écrites avant le développement, revues à chaque version.
• Des dépendances tenues à jour et surveillées pour les vulnérabilités connues.
• Des accès au back-office par rôle, avec revue trimestrielle et journal consulté.
• Des exercices : simulation d'incident, restauration de sauvegarde, rotation des clés.

Liste de contrôle avant lancement

• Le modèle de menace est écrit et partagé avec l'équipe.
• Les douze contrôles sont en place ou explicitement écartés avec une justification.
• Un test d'intrusion externe a été réalisé et ses constats corrigés.
• Les secrets ont été retirés du code et des dépôts, puis renouvelés.
• La supervision remonte les anomalies à une personne d'astreinte.
• Le plan d'incident a été répété au moins une fois.
• Les obligations réglementaires et contractuelles (régulateur, réseaux, partenaires) sont documentées.

Conclusion

La sécurité d'une application de paiement se joue sur la constance : des contrôles connus, appliqués partout, vérifiés régulièrement. C'est ce que nous faisons pour les produits que nous construisons pour la banque et la finance, et que nous appliquons à nos développements sur mesure. Pour un état des lieux de votre application, contactez-nous.