Ce que cela signifie pour votre test
Un appel API authentifié peut néanmoins être non autorisé. Comparez les identités des clients, du personnel et des services à partir du même compte ou de la même instruction synthétique. Vérifiez séparément les opérations de lecture, de mise à jour et d’approbation, puis contrôlez l’état en aval au lieu de vous fier à un code de réponse.
La frontière à tester
La propriété du compte, les pouvoirs délégués et l’état des transactions créent un modèle d’autorisations plus riche que la seule connexion. Les mêmes règles métier doivent s’appliquer aux API alternatives, aux exports et aux fonctions de back-office.
Une application de support peut devenir un point d’entrée vers des identifiants CI et une identité de paiement excessivement privilégiée. Un service de signature distinct peut toutefois empêcher le déblocage. Une évaluation utile explique chaque transition au lieu de conclure, à partir d’un seul hôte vulnérable, que l’ensemble de la banque a été compromis.
Ce que le périmètre peut inclure
- Autorisation au niveau du compte et des objets client
- Cycle de vie de la session, récupération et transitions entre les rôles du personnel
- Brouillons de paiement, changements de bénéficiaire et limites d’approbation
- Exports, traitement des fichiers et opérations d’API en back-office
La proposition finale identifie les applications, les comptes, les environnements et les interfaces concernés. Elle précise également les prérequis que votre équipe ou un prestataire doit fournir.
Si l’évaluation doit également couvrir l’appareil ou le navigateur du client, incluez un test d’intrusion de l’application bancaire. En complément du périmètre de l’API de support, il couvre le client iOS, Android ou web convenu, le traitement local des données et les parcours d’inscription des appareils.
À quoi ressemble une preuve utile
Utilisez des clients synthétiques avec des relations contrôlées et une transaction préalimentée. Vérifiez les requêtes qui modifient l’état au moyen d’une relecture indépendante et des journaux d’audit, en identifiant également le principal responsable de l’opération.
Consignez l’heure UTC, l’identifiant de l’actif, le principal à l’origine de la requête, la décision attendue et la réponse observée. Les tests qui modifient l’état nécessitent une confirmation dans l’objet résultant ou dans un journal d’audit fiable. Les opérations refusées et les contrôles effectifs font également partie du résultat.
Mesures de sécurité et limites de l’évaluation
Par défaut, le test ne débloque pas de fonds réels. SWIFT, les réseaux de cartes, les services de compensation et les prestataires partagés doivent être explicitement inclus dans le périmètre et autorisés.
Utilisez des paiements préalimentés et des clients synthétiques avec le règlement désactivé. Convenez d’une autorité indépendante habilitée à arrêter les tests, du rapprochement des transactions, de responsables système nommément désignés et des autorisations pour les services tiers. Distinguez les modifications de brouillons démontrées des transferts de fonds non exécutés.
Bouclez la démarche
Reliez chaque faiblesse à un responsable nommé, à une mesure de protection immédiate et à une correction pérenne. Définissez des cas de retest positifs et négatifs afin que la modification rétablisse la limite prévue tout en préservant les usages légitimes. Les points en suspens conservent leurs dépendances et leurs échéances.
Consultez l’exemple de rapport sectoriel pour découvrir le format des éléments probants et du plan de traitement.
