CORF de la Banque centrale du Koweït : testez l'application bancaire mobile qu'utilisent vos clients.
La Banque centrale du Koweït a publié son Cyber and Operational Resilience Framework (CORF) le 3 décembre 2025, dans le prolongement du Cybersecurity Framework de 2020. Ses exigences de base en matière de sécurité des paiements fixent des règles concrètes pour les applications bancaires mobiles : bloquer les appareils rootés et jailbreakés, faire expirer les sessions après cinq minutes, limiter la validité des mots de passe à usage unique à deux minutes au maximum, et tester les applications et les API par des évaluations de vulnérabilité et des tests d'intrusion. Ostorlab vous aide à remplir vos obligations de test pour l'application et les API qui la sous-tendent, à chaque version.
- Vérifie si la détection du root et du jailbreak tient, et ce que fait l'application lorsqu'elle se déclenche
- Teste la connexion, les codes à usage unique, les vérifications d'authentification renforcée et l'expiration des sessions avec vos comptes de test
- Suit l'application jusque dans ses API, même avec TLS pinning, pour tester les autorisations et les abus
- Suit les résultats jusqu'à leur résolution et reteste chaque correctif, avec des preuves que vous conservez
- Qui est concerné
- Toutes les entités réglementées placées sous la supervision de la Banque centrale du Koweït
- Publication
- CORF version 1.0, 3 décembre 2025
- Objet
- La cyberrésilience et la résilience opérationnelle, y compris la sécurité de la banque en ligne et mobile
- Référence
- CORF, chapitre 4, Cyber Resilience Baselines, domaines 5 et 8
Les textes de la CBK qui encadrent le canal mobile
Le CORF est la dernière étape d'une série de textes de la CBK sur la cybersécurité et les paiements électroniques. Les dates ci-dessous concernent les textes cités sur cette page.
- 23 décembre 2018
Instructions sur les paiements électroniques
La circulaire n° (2/BS, BS, IBS/415/2018) émet les Instructions for Regulation of the Electronic Payment of Funds à l'intention des banques locales et des autres institutions.
- Janvier 2020
Cybersecurity Framework
La version 1.0 du Cybersecurity Framework du secteur bancaire koweïtien fixe le premier socle de cybersécurité commun à l'ensemble du secteur.
- 18 septembre 2023
Mesures contre la fraude électronique
La circulaire n° (2/BS, IBS/534/2023) fixe des règles pour l'ajout de bénéficiaires, les nouveaux appareils et les applications de prise de contrôle à distance dans la banque en ligne et mobile.
- 3 décembre 2025
CORF version 1.0
Publication du Cyber and Operational Resilience Framework, qui fait passer du cadre de 2020 à un modèle axé d'abord sur la résilience et orienté vers la maturité.
- Chaque année
Profil de risque, autoévaluation et revue de la CBK
Les entités mettent à jour leur profil de risque inhérent et soumettent une autoévaluation chaque année. La CBK évalue les entités de niveau 1 chaque année, celles de niveau 2 tous les dix-huit mois et celles de niveau 3 tous les deux ans.
- Chaque trimestre
Reporting des vulnérabilités au conseil d'administration
La fonction sécurité de l'information informe le conseil d'administration et la direction générale de l'efficacité de la gestion des vulnérabilités, chaque trimestre ou plus souvent.
Les exigences de base du CORF, appliquées à votre application mobile
Les exigences de base du CORF en matière de sécurité des technologies et des paiements, ainsi que la circulaire de la CBK sur la fraude électronique. 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.
- CBK CORF, chapitre 4, 5.8.2.2 et 8.3.1.14
Tester vos applications par des évaluations de vulnérabilité et des tests d'intrusion
Ce que dit le texte
Toutes les applications, quel que soit leur type, doivent faire l'objet d'évaluations de sécurité complètes, y compris des évaluations de vulnérabilité et des tests d'intrusion, de manière périodique. Les entités doivent également mener des évaluations de sécurité périodiques pour identifier et corriger les vulnérabilités de leurs plateformes de banque en ligne et de leurs applications bancaires mobiles.
Ce que cela implique pour votre application mobile
L'application bancaire mobile est explicitement citée. Elle doit faire l'objet d'évaluations de vulnérabilité et de tests d'intrusion réguliers, et les failles qu'ils révèlent doivent être corrigées.
Comment Ostorlab vous aide
Mobile SAST analyse le binaire, y compris les SDK intégrés, et Mobile DAST teste l'application en cours d'exécution ; les deux s'exécutent dans la CI/CD. Le pentest par agents IA va plus loin derrière la connexion, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.
Ce qui reste de votre ressort
La fixation de la fréquence des tests, le cadrage des tests manuels et la validation des corrections.
- CBK CORF, chapitre 4, 8.3.1.7, 8.1.3.3 et 8.3.3.3
Bloquer les appareils rootés et jailbreakés
Ce que dit le texte
Les entités doivent mettre en œuvre des contrôles pour empêcher l'installation et bloquer l'utilisation des applications bancaires mobiles sur les appareils jailbreakés ou rootés. Les appareils utilisés pour la banque numérique doivent être vérifiés en continu au regard des politiques de sécurité, notamment la version du système d'exploitation, le niveau de correctifs et l'intégrité de l'appareil, et l'accès des appareils non conformes doit être restreint ou révoqué. Les portefeuilles numériques doivent également bloquer leur utilisation sur les appareils jailbreakés ou rootés.
Ce que cela implique pour votre application mobile
La détection du root et du jailbreak est une exigence, pas une option. Elle doit se déclencher et l'application doit réagir, même lorsqu'un attaquant tente de masquer l'état de l'appareil.
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. Vous obtenez un score de durcissement et des preuves de contournement.
Ce qui reste de votre ressort
Le choix et la configuration de votre produit de blindage ou de protection à l'exécution, ainsi que la politique de conformité des appareils.
- CBK CORF, chapitre 4, 8.3.1.3 et 8.1.3.5
Utiliser une MFA forte pour les actions critiques
Ce que dit le texte
Les entités doivent mettre en œuvre une authentification multifacteur forte et une vérification hors bande pour autoriser les actions critiques telles que l'activation d'un compte, les virements, le paiement de factures et l'ajout de bénéficiaires, au moyen d'OTP issus d'applications d'authentification tierces, de notifications push dans l'application avec approbation biométrique ou par code PIN, ou d'une autorisation liée à l'appareil telle que FIDO2. La modification d'informations sensibles du client, comme le numéro de mobile et l'adresse e-mail, exige la MFA.
Ce que cela implique pour votre application mobile
Chaque action critique dans l'application exige sa propre vérification forte, et cette vérification doit 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 le recueil du consentement du client sur le mode de transmission des OTP.
- CBK CORF, chapitre 4, 8.3.1.1, 8.3.1.2 et 8.1.3.1
Limiter les sessions, les mots de passe à usage unique et les échecs de connexion
Ce que dit le texte
Les sessions de banque mobile doivent prendre fin automatiquement après cinq minutes d'inactivité au maximum, et les sessions simultanées sont interdites. Les mots de passe à usage unique sont valables deux minutes au maximum, et les sessions doivent être revalidées à intervalles définis ou lorsque le contexte de la session change. L'accès doit être bloqué après trois tentatives de connexion ou d'authentification échouées au maximum.
Ce que cela implique pour votre application mobile
Ce sont des paramètres concrets et vérifiables : le délai d'inactivité, l'interdiction des sessions parallèles, la durée de vie des OTP et le seuil de verrouillage.
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 procédure de réactivation des utilisateurs bloqués et les déclencheurs de revalidation que vous choisissez.
- CBK CORF, chapitre 4, 8.3.1.8 à 8.3.1.10
Chiffrer les données locales et lier l'application aux appareils
Ce que dit le texte
L'application bancaire mobile doit chiffrer toutes les données qu'elle stocke localement sur l'appareil du client. Elle doit vérifier le numéro de mobile du client et recourir à l'authentification de l'appareil, par exemple par empreinte de l'appareil ou par authentification à base de certificat, lors de la première utilisation. Les clients peuvent utiliser l'application depuis trois appareils validés au maximum, ou six au maximum avec des contrôles forts d'atténuation des risques.
Ce que cela implique pour votre application mobile
Ce que l'application écrit sur l'appareil, et la manière dont elle reconnaît un nouvel appareil, entrent tous deux dans le périmètre.
Comment Ostorlab vous aide
Ostorlab recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, et détecte les erreurs de configuration qui affaiblissent la protection du transport et des sessions. Les tests authentifiés couvrent les parcours de connexion et d'appareil derrière vos comptes de test.
Ce qui reste de votre ressort
Les limites d'enregistrement des appareils, la revalidation des appareils enregistrés et les notifications aux clients.
- CBK CORF, chapitre 4, 5.8.3.1 à 5.8.3.8 et 8.3.2.7
Sécuriser vos API et les évaluer après chaque changement majeur
Ce que dit le texte
Les API doivent suivre des pratiques de codage sécurisé comme l'OWASP API Security Top 10, imposer une authentification forte et un contrôle d'accès fondé sur les rôles, valider toutes les entrées, appliquer une limitation de débit (rate limiting et throttling) et chiffrer le trafic. Les API doivent faire l'objet d'évaluations de sécurité de manière périodique et après chaque changement majeur, telles que des tests d'intrusion, du fuzzing, du DAST/SAST, des tests à l'exécution et des tests d'erreurs de configuration. Les API d'open banking doivent être évaluées périodiquement par des tests d'intrusion et des évaluations de vulnérabilité.
Ce que cela implique pour votre application mobile
Les API derrière l'application exigent le même examen que l'application, à un rythme régulier et à nouveau après chaque changement majeur.
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
Les passerelles d'API, l'inventaire des API, la journalisation et la surveillance, et la gestion du cycle de vie des API.
- CBK CORF, chapitre 4, 5.8.1.3, 5.8.1.6, 5.8.1.7 et 5.9.1.6
Intégrer la sécurité au développement et aux mises en production
Ce que dit le texte
Les entités doivent suivre une approche DevSecOps, adopter des pratiques de codage sécurisé comme celles de l'OWASP pour traiter les faiblesses courantes telles que le CWE Top 25, et tenir à jour un Software Bill of Materials pour tous les logiciels, y compris ceux des fournisseurs tiers. Les tests menés avant qu'un changement n'atteigne la production doivent couvrir les tests de sécurité, les revues de code source le cas échéant, les tests d'intrusion et l'évaluation de vulnérabilité.
Source :CBK CORF, chapitre 4, 5.8.1.3, 5.8.1.6, 5.8.1.7 et 5.9.1.6
Ce que cela implique pour votre application mobile
Chaque version de l'application devrait passer des tests de sécurité avant d'arriver sur le store, et vous devriez savoir quels composants tiers elle embarque.
Comment Ostorlab vous aide
Les scans automatisés s'exécutent depuis votre pipeline CI/CD à chaque build. SCA recense les SDK et bibliothèques natives de chaque version avec leurs versions, les associe aux vulnérabilités connues et suit leur résolution d'une version à l'autre.
Ce qui reste de votre ressort
Les revues de conception sécurisée, les revues de code manuelles, la séparation des tâches et l'approbation des changements, y compris l'approbation de la CBK pour les changements majeurs.
- CBK CORF, chapitre 4, 5.13.1.2, 5.13.1.5 à 5.13.1.7
Suivre les vulnérabilités jusqu'à leur résolution et valider le correctif
Ce que dit le texte
Les évaluations de vulnérabilité des réseaux, systèmes et applications doivent être menées périodiquement ou à chaque changement significatif. Les résultats doivent être documentés et suivis jusqu'à leur résolution, et les entités doivent valider la correction pour confirmer que les failles sont traitées. Les entités doivent recourir à la gestion de la surface d'attaque externe pour leurs actifs exposés au public.
Ce que cela implique pour votre application mobile
Trouver les problèmes ne suffit pas. Il vous faut une trace montrant que chacun a été corrigé et retesté, et une vue des applications que vous exposez.
Comment Ostorlab vous aide
Les résultats sont classés en critique, élevé, moyen ou faible, suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif livré. La découverte de la surface d'attaque vous aide à identifier les applications et actifs que vous exposez.
Ce qui reste de votre ressort
Les délais de correction, la gestion des correctifs et le rapport trimestriel au conseil d'administration.
- Circulaire de la CBK n° (2/BS, IBS/534/2023)
Protéger les clients contre la fraude électronique
Ce que dit le texte
Lorsqu'un client ajoute un nouveau bénéficiaire via la banque en ligne ou mobile, un OTP doit être envoyé par SMS, le client doit être notifié, et le bénéficiaire ne doit pas être activé avant au moins 12 heures, sauf confirmation du client. Les appareils non reconnus doivent être vérifiés par téléphone avant toute transaction. Les banques doivent empêcher l'utilisation de l'application lorsque des applications de prise de contrôle à distance comme AnyDesk sont installées, et générer des codes de sécurité afin que les transactions ne puissent pas être effectuées depuis un autre appareil.
Ce que cela implique pour votre application mobile
Le délai d'activation des bénéficiaires, les vérifications des nouveaux appareils et les codes de sécurité liés à l'appareil relèvent de la logique métier. Ils doivent tenir côté serveur, pas seulement dans les écrans de l'application.
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 détection des applications de prise de contrôle à distance, la vérification par téléphone, la surveillance des transactions et la sensibilisation des clients.
Synthèse des textes publics de la CBK, vérifiés le 27 septembre 2026. Les circulaires sur les paiements électroniques sont des traductions anglaises publiées par la CBK à titre d'information ; le texte arabe fait foi. Cette page ne constitue pas un avis juridique.
Le CORF de la CBK, contrôle par contrôle
Les contrôles mobiles et API du CORF, 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 |
|---|---|---|
| Évaluations de vulnérabilité et tests d'intrusion de l'application mobileCORF 5.8.2.2, 8.3.1.14 | 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 |
| Blocage des appareils rootés et jailbreakésCORF 8.3.1.7, 8.1.3.3 | 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é |
| MFA pour les actions critiques et la modification des coordonnéesCORF 8.3.1.3, 8.1.3.5 | Se connecte avec des codes à usage unique et teste l'application effective de la MFA, les parcours d'authentification renforcée et les appels d'API qui les sous-tendent. Détails | Résultats sur les parcours de connexion et d'authentification renforcée, avec étapes de reproduction |
| Expiration des sessions après cinq minutes, OTP de deux minutes, trois tentatives échouéesCORF 8.3.1.1, 8.3.1.2, 8.1.3.1 | Teste la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration et l'invalidation des sessions. Détails | Résultats sur les sessions et les jetons, avec journaux des requêtes et réponses |
| Chiffrement des données stockées sur l'appareilCORF 8.3.1.8 | 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 |
| Authentification, contrôle d'accès, limitation de débit et tests des APICORF 5.8.3.1 à 5.8.3.8, 8.3.2.7 | 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 |
| Tests de sécurité avant la mise en productionCORF 5.8.1.6, 5.9.1.6 | 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 |
| Software Bill of Materials pour chaque versionCORF 5.8.1.3 | Recense les SDK et bibliothèques natives de chaque version avec leurs versions, et montre avec quels backends l'application et ses SDK communiquent. Détails | Identité, version et emplacement de chaque composant dans le bundle de l'application, par version |
| Suivi des résultats jusqu'à leur résolution et validation des correctionsCORF 5.13.1.5, 5.13.1.7 | 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 |
| Identifiants codés en dur dans l'applicationCORF 8.1.3.2 | 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 |
Ostorlab teste les contrôles de l'application et de ses API. La gouvernance, les profils de risque et les autoévaluations, la surveillance par le SOC, les opérations antifraude, la continuité d'activité, la gestion des risques liés aux tiers et au cloud, et le reporting à la CBK restent du ressort de vos équipes.
Les contrôles mobiles du CORF à tester dans votre application
Une liste pratique pour les équipes sécurité et conformité qui préparent une évaluation au titre du CORF.
Appareils rootés et jailbreakés
Exécutez l'application sur des appareils rootés et jailbreakés, essayez de masquer l'état de l'appareil, et vérifiez que l'application bloque l'installation ou l'utilisation.
Paramètres des sessions et des OTP
Vérifiez l'expiration après cinq minutes d'inactivité, l'interdiction des sessions simultanées, la durée de vie de deux minutes des OTP et le verrouillage après trois tentatives.
MFA sur les actions critiques
Vérifiez que l'activation du compte, les virements, le paiement de factures, l'ajout de bénéficiaires et la modification des coordonnées exigent tous une MFA forte, imposée par le serveur.
Nouveaux bénéficiaires et nouveaux appareils
Vérifiez que le délai de 12 heures pour les bénéficiaires et les vérifications des nouveaux appareils prévus par la circulaire 534/2023 ne peuvent pas être contournés via l'API.
API derrière l'application
Testez les autorisations, la validation des entrées et la limitation de débit sur chaque API de compte et de paiement, et à nouveau après chaque changement majeur.
Données laissées sur l'appareil
Recherchez les jetons et les données personnelles non chiffrés dans le stockage, les caches, les journaux et les captures d'écran, ainsi que les identifiants codés en dur dans l'application.
SBOM pour chaque version
Tenez à jour la liste des SDK et bibliothèques natives embarqués dans chaque version, avec leurs vulnérabilités connues et leur résolution.
Preuves pour l'évaluation
Conservez les résultats, les tickets et les retests de chaque version, pour montrer que les vulnérabilités ont été suivies jusqu'à leur résolution et que les corrections ont été validées.
Une liste indicative, et non un modèle de la CBK. 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
- 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
- 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
- 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.
- Cyber and Operational Resilience Framework for All Local Banks and Financial Institutions (CORF)Banque centrale du Koweït, version 1.0, première publication le 3 décembre 2025. S'applique à toutes les entités réglementées par la CBK ; le chapitre 4 regroupe les exigences de base de cyberrésilience sur les applications, les API, la gestion des vulnérabilités et la sécurité des paiements
- CBK Launches the Cyber & Operational Resilience Framework for Local Banks and Financial InstitutionsCommuniqué de presse de la Banque centrale du Koweït, 3 décembre 2025
- Cybersecurity Framework for Kuwaiti Banking SectorBanque centrale du Koweït, version 1.0, janvier 2020. Le cadre antérieur sur lequel s'appuie le CORF
- Circular No. (2/BS, BS, IBS/415/2018): Instructions for Regulation of the Electronic Payment of FundsBanque centrale du Koweït, 23 décembre 2018, émise en application de la résolution n° 44/430 de 2018. Traduction anglaise à titre d'information ; le texte arabe fait foi
- Circulars for Regulating the Electronic Payment of Funds, including Circular No. (2/BS, IBS/534/2023) on Measures for Protection of Customers from Electronic FraudBanque centrale du Koweït, chapitre deux des instructions sur les paiements électroniques. La circulaire 534/2023 est datée du 18 septembre 2023 et porte sur les bénéficiaires, les nouveaux appareils et les applications de prise de contrôle à distance. Traduction anglaise à titre d'information
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 exigences de base du CORF
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.