Banque centrale de Jordanie : testez l'application bancaire mobile qui donne accès aux comptes de vos clients.
Les Instructions sur la résilience aux cyberrisques (Instructions of Cyber Risks Resilience) de la Banque centrale de Jordanie exigent des tests d'intrusion des systèmes critiques au moins une fois par an, y compris au niveau applicatif. Son cadre de cybersécurité (Cybersecurity Framework) pour le secteur financier ajoute des règles concrètes pour les applications bancaires mobiles : TLS pinning, aucune installation sur des appareils rootés ou jailbreakés, expiration des sessions après cinq minutes et secrets à usage unique valables cinq minutes au maximum. Ostorlab vous aide à remplir vos obligations de test pour l'application et les API qui la sous-tendent, à chaque version.
- Tests de pénétration par agents IA derrière la connexion, codes à usage unique compris
- Vérifie la détection du root et du jailbreak et le TLS pinning, ainsi que la réaction de l'application lorsqu'ils se déclenchent
- Tests statiques et dynamiques de la version que vous livrez, sans besoin du code source
- Niveaux de risque, tickets et retests, pour que chaque correctif puisse être prouvé
- Qui est concerné
- Les banques agréées, les institutions financières, les bureaux de crédit et les sociétés de microfinance supervisés par la CBJ
- Base juridique
- Instructions sur la résilience aux cyberrisques, émises le 6 février 2018
- Objet
- La gestion des cyberrisques, les tests d'intrusion et la fourniture de services électroniques
- Référence
- Instructions sur la résilience aux cyberrisques, article 35 ; cadre de cybersécurité, sections G.2, G.9.5 et H.2
Les textes de la CBJ qui encadrent le canal mobile
Des instructions contraignantes, un cadre détaillé et des recommandations antifraude. Les dates ci-dessous concernent les textes cités sur cette page.
- 25 octobre 2016
Instructions sur la gouvernance des SI
Les Instructions n° (65/2016) sur la gouvernance et la gestion de l'information et des technologies associées, fondées sur COBIT 5, en vigueur dix-huit mois après leur émission.
- 6 février 2018
Instructions sur la résilience aux cyberrisques
Des règles sur la gouvernance de la cybersécurité, la protection, la détection, la réponse, les tests et l'externalisation, applicables douze mois après leur émission.
- Juillet 2021
Cadre de cybersécurité, version 1.0
Le cadre de la CBJ pour le secteur financier fixe des exigences de base en cybersécurité, y compris des contrôles pour la banque mobile et en ligne. Le FinCERT évalue sa mise en œuvre.
- Mai 2023
Recommandations sur la lutte contre la fraude financière
Des contrôles antifraude pour les sociétés agréées pour fournir des services de paiement électronique, y compris les banques : authentification forte du client et détection des appareils rootés.
- Chaque année
Tests d'intrusion et rapports d'audit informatique
Des tests d'intrusion des systèmes critiques au moins une fois par an, et des rapports d'audit informatique interne et externe annuels remis à la CBJ au cours du premier trimestre.
- Chaque mois
Scan de vulnérabilités des systèmes critiques
Le cadre recommande vivement un scan de vulnérabilités au moins une fois par mois pour les systèmes critiques et sensibles.
Les règles cyber de la CBJ, appliquées à votre application mobile
Les Instructions sur la résilience aux cyberrisques, le cadre de cybersécurité pour le secteur financier et les recommandations antifraude de la CBJ. Pour chaque règle : ce que dit le texte, ce que cela implique pour une application bancaire mobile, comment Ostorlab vous aide et ce qui reste du ressort de votre équipe.
- Instructions sur la résilience aux cyberrisques, article 35, a)
Soumettre les systèmes critiques à un test d'intrusion au moins une fois par an
Ce que dit le texte
Mettez en œuvre des tests d'intrusion des systèmes critiques au moins une fois par an ou après un changement radical du système, avec un périmètre fondé sur la sensibilité des systèmes et des systèmes qui les supportent. Les tests sont menés au niveau des applications ainsi que des réseaux internes et externes. Les tests peuvent être réalisés par un tiers, mais ne peuvent pas être confiés au même tiers plus de deux années consécutives.
Source :Instructions sur la résilience aux cyberrisques, article 35, a)
Ce que cela implique pour votre application mobile
Si votre application bancaire mobile supporte des systèmes critiques, elle et ses API entrent dans le test d'intrusion annuel, et dans un nouveau test après tout changement radical.
Comment Ostorlab vous aide
Le pentest par agents IA teste l'application et ses API derrière la connexion, sur la version que vous livrez, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA. Il peut s'exécuter à chaque version, entre vos tests annuels.
Ce qui reste de votre ressort
Le cadrage du test annuel, le choix et la rotation du prestataire de test, et la définition de ce qui constitue un changement radical.
- Instructions sur la résilience aux cyberrisques, article 35, b) et c) ; cadre de cybersécurité, G.9.5
Évaluer les vulnérabilités et surveiller l'apparition de nouvelles failles
Ce que dit le texte
Évaluez périodiquement les vulnérabilités et les failles de sécurité des systèmes critiques et des systèmes qui les supportent, traitez les failles identifiées, et surveillez les systèmes en continu pour en détecter de nouvelles. Le cadre recommande vivement un scan de vulnérabilités au moins une fois par mois pour les systèmes critiques et sensibles, réalisé à la fois en contournant les contrôles en place et à travers eux.
Ce que cela implique pour votre application mobile
Entre deux pentests annuels, l'application et ses API exigent des scans automatisés réguliers, avec des résultats corrigés et suivis.
Comment Ostorlab vous aide
Lancez des scans automatisés depuis votre pipeline CI/CD à chaque build et surveillez les versions publiées sur les stores sans déclenchement manuel. Des exécutions planifiées de votre pipeline maintiennent un rythme hebdomadaire entre les versions. Les résultats sont classés en critique, élevé, moyen ou faible, suivis sous forme de tickets et retestés une fois le correctif livré.
Ce qui reste de votre ressort
Le scan de l'infrastructure et du réseau, et la fréquence de scan de chaque système.
- Cadre de cybersécurité, G.2.2 et G.2.3
Tester la sécurité tout au long du développement
Ce que dit le texte
Définissez un cycle de développement sécurisé : analyse statique du code pendant le codage, et analyse dynamique du code par des scans de vulnérabilités et des tests d'intrusion pendant la phase de test, avec revue et correction des résultats. Le codage sécurisé doit couvrir au moins l'OWASP Top Ten et le CWE/SANS Top 25. La sécurisation des applications ne devrait pas reposer sur l'obscurcissement des fonctionnalités, du code source, des clés ou des chaînes, et les corrections doivent être testées de manière approfondie avant la mise en production.
Ce que cela implique pour votre application mobile
Chaque version de l'application devrait passer des tests statiques et dynamiques avant d'arriver sur le store, et des clés dissimulées dans l'application ne constituent pas un contrôle.
Comment Ostorlab vous aide
Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans besoin du code source, avec une analyse de propagation (taint) à travers les SDK intégrés. Mobile DAST exécute l'application et capture le trafic, les traces d'appels et les captures d'écran. Ostorlab détecte aussi les secrets codés en dur, comme les clés d'API et les jetons, avant leur mise en production.
Ce qui reste de votre ressort
La modélisation des menaces, les revues de code manuelles par une personne autre que le développeur, et la formation des développeurs.
- Cadre de cybersécurité, H.2.1(2)
Durcir l'application bancaire mobile
Ce que dit le texte
Pour la banque mobile et en ligne, l'application doit vérifier le numéro de mobile du client et l'IMEI ou l'ESN de l'appareil lors de la première utilisation, mettre fin aux sessions après cinq minutes d'inactivité au maximum, interdire les sessions simultanées tout en autorisant jusqu'à trois appareils validés, utiliser des techniques contre les attaques de l'homme du milieu comme le TLS pinning, éviter la mise en cache des données sensibles et chiffrer les données stockées sur l'appareil, et empêcher l'installation sur les appareils rootés ou jailbreakés.
Source :Cadre de cybersécurité, H.2.1(2)
Ce que cela implique pour votre application mobile
Chacun de ces points est une propriété vérifiable de l'application. Le pinning et la détection du root doivent aussi résister à un attaquant qui tente de les contourner.
Comment Ostorlab vous aide
Mobile Shielding Scan exécute l'application dans des environnements rootés et jailbreakés, tente de contourner la détection du root et du jailbreak, l'anti-altération, l'anti-instrumentation et le TLS pinning, et montre si l'application bloque le parcours, refuse de démarrer ou continue de fonctionner. Ostorlab recherche aussi les jetons et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran.
Ce qui reste de votre ressort
Le choix et la configuration de votre produit de blindage, et le processus d'enregistrement des appareils.
- Cadre de cybersécurité, H.2.1(1) et H.4(2)
Ajouter des facteurs d'autorisation pour les actions sensibles
Ce que dit le texte
Mettez en œuvre des facteurs d'autorisation supplémentaires pour l'activation du compte, la réinitialisation du mot de passe, les transactions financières et l'ajout ou la modification de bénéficiaires, au moyen de secrets à usage unique transmis hors bande, d'OTP basés sur le temps ou sur un hachage, ou d'authentificateurs cryptographiques. Les secrets à usage unique sont valables cinq minutes au maximum. La modification des coordonnées via un canal électronique exige une authentification multifacteur, avec des alertes et le second facteur envoyés à l'ancien numéro ou à l'ancienne adresse e-mail.
Ce que cela implique pour votre application mobile
Les vérifications d'authentification renforcée sur les bénéficiaires, les réinitialisations et les modifications de coordonnées sont les contrôles que les fraudeurs cherchent à contourner. Elles doivent tenir côté serveur, quoi que l'application envoie.
Comment Ostorlab vous aide
Ostorlab saisit les codes à usage unique reçus par SMS, e-mail ou TOTP avec vos comptes de test et teste l'application effective de la MFA et les parcours d'authentification renforcée, y compris les tentatives de manipulation par un attaquant, ainsi que les appels d'API derrière les modifications de compte.
Ce qui reste de votre ressort
Le choix des méthodes d'authentification et des canaux de transmission des secrets à usage unique.
- Cadre de cybersécurité, G.3 (7.4, 7.6, 8.3) et H.3(5)
Compter correctement les facteurs et verrouiller après trois échecs
Ce que dit le texte
Une authentification n'est multifacteur que si au moins deux authentificateurs relevant de facteurs différents sont utilisés. La vérification de l'appareil, l'authentification fondée sur la connaissance, la localisation et la biométrie comportementale ne sont pas des facteurs d'authentification. L'accès aux services de paiement électronique doit être bloqué après trois tentatives d'authentification ou d'autorisation échouées au maximum, et les mots de passe temporaires doivent expirer rapidement.
Source :Cadre de cybersécurité, G.3 (7.4, 7.6, 8.3) et H.3(5)
Ce que cela implique pour votre application mobile
Un appareil de confiance associé à un code SMS ne vaut pas deux facteurs si les deux peuvent être obtenus ensemble. Le verrouillage et l'expiration doivent être imposés par le backend.
Comment Ostorlab vous aide
Les tests authentifiés couvrent la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et l'application effective de la MFA, et l'analyse du trafic montre comment les identifiants transitent de l'application vers le backend.
Ce qui reste de votre ressort
La politique de mots de passe, les durées de verrouillage et la procédure de réactivation.
- Cadre de cybersécurité, I.3
Sécuriser les API que vous ouvrez aux tiers
Ce que dit le texte
Pour les prestataires d'accès à l'information et d'initiation de paiement, les tiers doivent être authentifiés avant de consommer toute API, le TLS mutuel étant vivement recommandé. Les utilisateurs sont authentifiés par au moins deux facteurs avant l'enregistrement de leur consentement, les clients sont authentifiés au niveau de l'API, OAuth 2.0 et OpenID Connect étant vivement recommandés, et les utilisateurs peuvent révoquer leur consentement à tout moment.
Source :Cadre de cybersécurité, I.3
Ce que cela implique pour votre application mobile
Les API derrière l'application et toute API ouverte exigent des autorisations qui tiennent pour chaque requête, quel que soit l'appelant.
Comment Ostorlab vous aide
Ostorlab intercepte le trafic de l'application, même avec TLS pinning, et teste les API à la recherche de contrôles d'autorisation défaillants (BOLA, BFLA, IDOR), d'usages abusifs des jetons et des sessions, et d'abus comme l'énumération, le rejeu et l'automatisation, avec les requêtes et réponses à l'appui de chaque résultat.
Ce qui reste de votre ressort
L'intégration des tiers, la connectivité VPN, la gestion du consentement et les catalogues de risques liés aux API.
- Recommandations de la CBJ sur la lutte contre la fraude financière dans le système national de paiement, procédures de contrôle interne, C, D et G
Intégrer les contrôles antifraude à l'application
Ce que dit le texte
Authentifiez les clients avec au moins deux facteurs et évitez de vous appuyer uniquement sur des OTP par SMS, y compris lors de l'accès aux applications mobiles, de la réalisation de transactions et de l'activation de l'application sur un nouvel appareil. Exigez un troisième facteur pour les sessions anormales ou les virements depuis un appareil non approuvé vers un nouveau bénéficiaire. Les applications mobiles devraient détecter le jailbreak ou le root et bloquer l'application ou restreindre les fonctionnalités sensibles, et limiter les connexions simultanées ou le nombre d'appareils.
Ce que cela implique pour votre application mobile
Les contrôles antifraude se trouvent dans l'application et dans les API de paiement. La détection des appareils rootés, l'association à l'appareil et les règles d'authentification renforcée font partie de votre défense antifraude.
Comment Ostorlab vous aide
Ostorlab teste les contrôles antifraude présents dans l'application et ses API : authentification, vérifications d'authentification renforcée, gestion des sessions, protections de l'appareil et logique métier des paiements.
Ce qui reste de votre ressort
La surveillance des transactions, la cellule antifraude, les listes noires et la sensibilisation des clients.
- Instructions n° (65/2016), article 9 et annexe 5
Fournir aux auditeurs des preuves de vos tests
Ce que dit le texte
Le comité d'audit et l'auditeur externe transmettent à la CBJ un rapport annuel d'audit informatique interne et un rapport annuel d'audit informatique externe au cours du premier trimestre de chaque année. Le programme d'audit couvre, entre autres, l'efficacité et la suffisance de l'évaluation des vulnérabilités et des tests d'intrusion, ainsi que les contrôles opérationnels des canaux électroniques et des systèmes de paiement électronique.
Ce que cela implique pour votre application mobile
Les auditeurs vous demanderont comment l'application a été testée, ce qui a été trouvé et si cela a été corrigé.
Comment Ostorlab vous aide
Les résultats de scan, les vulnérabilités détectées avec leurs étapes de reproduction et les résultats de retest vous donnent une trace datée de la manière dont les contrôles de l'application ont été testés et corrigés, version après version.
Ce qui reste de votre ressort
L'audit lui-même, le cadre de gouvernance des SI et le reporting à la CBJ.
Synthèse des versions anglaises des textes publics de la CBJ, vérifiés le 27 septembre 2026. Certains textes s'appliquent à des types de licences spécifiques, comme indiqué. Cette page ne constitue pas un avis juridique.
Les règles de la CBJ, contrôle par contrôle
Les contrôles mobiles et API des textes de la CBJ, la manière dont Ostorlab les teste dans votre application et ses API, et les preuves que vous conservez.
| Contrôle | Comment Ostorlab vous aide | Preuves conservées |
|---|---|---|
| Tests d'intrusion au niveau applicatifRésilience aux cyberrisques, art. 35, a) | Pentest par agents IA de l'application et de ses API, derrière la connexion, sur la version que vous livrez. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
| Scans de vulnérabilités réguliersRésilience aux cyberrisques, art. 35, b) ; CSF G.9.5 | Scans automatisés depuis votre pipeline CI/CD à chaque build, y compris par exécutions planifiées, et surveillance des versions publiées sur les stores. Détails | Résultats de scan par build et par version publiée sur les stores |
| Analyse statique et dynamique avant la mise en productionCSF G.2.2 | Mobile SAST sur le binaire et Mobile DAST sur l'application en cours d'exécution, avant la mise en production. Détails | Résultats avec contexte du code décompilé, trafic, traces d'appels et captures d'écran |
| Aucune clé ni aucun secret dissimulé dans l'applicationCSF G.2.3 | Détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels. Détails | Secrets validés, avec les permissions et les services qu'ils exposent |
| Aucune installation sur les appareils rootés ou jailbreakésCSF H.2.1 ; recommandations antifraude, G | Exécute l'application dans des environnements rootés et jailbreakés et tente de contourner la détection du root et du jailbreak. Détails | Score de durcissement, et preuves de contournement pour chaque protection qui a échoué |
| TLS pinning contre les attaques de l'homme du milieuCSF H.2.1 | Tente de contourner le TLS pinning à l'exécution et intercepte le trafic de l'application lorsque c'est possible. Détails | Preuves des protections qui ont tenu et de celles qui ont été contournées |
| Données sensibles mises en cache ou stockées sur l'appareilCSF H.2.1 | Recherche les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifie la protection du transport. Détails | Preuves sur le système de fichiers montrant ce qui a été écrit, où et quand |
| Facteurs d'autorisation, sessions de cinq minutes et secrets à usage uniqueCSF H.2.1, H.4, H.3 | Se connecte avec des codes à usage unique et teste l'application effective de la MFA, les parcours d'authentification renforcée, les délais d'expiration et l'invalidation des sessions. Détails | Résultats sur les parcours de connexion, de session et d'authentification renforcée, avec étapes de reproduction |
| Authentification et autorisation des APICSF I.3 | Intercepte le trafic même avec TLS pinning et teste les autorisations, les usages abusifs des jetons et les abus comme l'énumération et le rejeu. Détails | Requêtes et réponses à l'appui de chaque résultat d'API |
| Corrections suivies et retestéesRésilience aux cyberrisques, art. 35, b) ; ITG 65/2016, annexe 5 | Regroupe les résultats en tickets dans la plateforme ou dans Jira et ServiceNow, et reteste après correction. | Historique des tickets et issue du retest pour chaque résultat |
Ostorlab teste les contrôles de l'application et de ses API. La gouvernance de la cybersécurité, la gouvernance des SI selon COBIT, les tests du réseau et de l'infrastructure, la surveillance par le SOC, la réponse aux incidents, la continuité d'activité, la supervision de l'externalisation et du cloud, les opérations antifraude et le reporting à la CBJ restent du ressort de vos équipes.
Les contrôles mobiles de la CBJ à tester dans votre application
Une liste pratique pour les équipes sécurité, antifraude et audit en Jordanie.
Test d'intrusion annuel
Incluez l'application mobile et ses API dans le périmètre du test d'intrusion annuel des systèmes critiques, et retestez après tout changement radical.
Scans entre les tests
Scannez chaque build et chaque version publiée sur les stores, et visez au moins un scan mensuel des systèmes critiques, comme le recommande le cadre.
Appareils rootés et jailbreakés
Exécutez l'application sur des appareils rootés et jailbreakés et vérifiez qu'elle refuse de s'installer ou de s'exécuter, ou qu'elle restreint les fonctionnalités sensibles.
TLS pinning
Essayez d'intercepter le trafic de l'application et vérifiez que le pinning résiste aux tentatives de contournement.
Sessions et secrets à usage unique
Vérifiez l'expiration après cinq minutes d'inactivité, l'interdiction des sessions simultanées, l'expiration des secrets à usage unique et le verrouillage après trois tentatives.
Authentification renforcée pour les actions sensibles
Vérifiez que l'activation, la réinitialisation du mot de passe, les virements, l'ajout de bénéficiaires et la modification des coordonnées exigent un facteur supplémentaire, imposé par le serveur.
Données et secrets dans l'application
Recherchez les données sensibles mises en cache, le stockage non chiffré et les clés ou jetons codés en dur dans le package de l'application.
Preuves pour les auditeurs
Conservez les résultats, les tickets et les retests de chaque version, prêts pour les rapports annuels d'audit informatique interne et externe.
Une liste indicative, et non un modèle de la CBJ. Ceci ne constitue pas un avis juridique.
Les capacités associées à cette page
Chacune a sa propre page détaillée.
- Mobile Agentic Deep ScanDes agents IA pentestent la version publiée à chaque release, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.En savoir plus
- Mobile Shielding ScanTestez à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et voyez quelles protections ont tenu et lesquelles ont été contournées.En savoir plus
- Mobile SASTAnalyse statique des binaires APK, AAB et IPA, avec analyse de propagation (taint) sur l'application et ses SDK intégrés.En savoir plus
- Tests authentifiésTestez la connexion, les codes à usage unique et les parcours d'authentification renforcée avec vos comptes de test.En savoir plus
- Tests des API et du backendInterceptez le trafic de l'application même avec TLS pinning, puis testez les API et backends derrière les comptes et les paiements.En savoir plus
- SCA et SBOMDétectez les dépendances vulnérables, y compris les bibliothèques natives compilées statiquement, et suivez leur résolution version après version.En savoir plus
- Votre propre clé IALancez les scans par agents IA avec la clé de votre fournisseur d'IA et un plafond de dépense par scan, pour respecter vos politiques internes.En savoir plus
- Scan on-premisesScannez les applications de préproduction, API et dépôts derrière votre pare-feu ou VPN, sur une infrastructure que vous contrôlez.En savoir plus
Des banques et fintechs nous font confiance, dont
Sources
Les textes officiels sur lesquels s'appuie cette page, vérifiés le 27 septembre 2026.
- Instructions of Cyber Risks ResilienceBanque centrale de Jordanie, n° 26/1/1/1984, 6 février 2018, applicables douze mois après leur émission. S'appliquent aux banques agréées, aux institutions financières, aux bureaux de crédit et aux sociétés de microfinance ; l'article 35 porte sur les tests d'intrusion et les évaluations de vulnérabilité
- Cybersecurity Framework for Jordan Financial Sector, Version 1.0Banque centrale de Jordanie et FinCERT, juillet 2021. Exigences de base pour les entités réglementées par la CBJ, notamment le développement sécurisé, le scan de vulnérabilités et les tests d'intrusion, la banque mobile et en ligne, et les API ouvertes
- Governance and Management of Information and Related Technology Instructions No. (65/2016)Banque centrale de Jordanie, 25 octobre 2016, fondées sur COBIT 5, en vigueur dix-huit mois après leur émission. Portent sur la gouvernance des SI et les rapports annuels d'audit informatique remis à la CBJ
- Guidance on Combating Financial Fraud in the National Payment SystemBanque centrale de Jordanie, département de la surveillance et de la supervision du système national de paiement, mai 2023. Pour les sociétés agréées pour fournir des services de paiement électronique, y compris les banques
Questions fréquentes
Des réponses claires sur la couverture, la mise en place et la façon dont les résultats parviennent à vos équipes.
Vous ne trouvez pas votre réponse ? Réservez une démo ou contactez-nous.
Testez votre application bancaire mobile au regard des règles de la CBJ
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests de blindage et des tests authentifiés avec notre équipe.