Les règles de la QCB pour l'application bancaire mobile de vos clients.
La Banque centrale du Qatar demande aux banques de tester les applications web et mobiles avant et après leur mise en production et après tout changement majeur, de réaliser des évaluations de vulnérabilité, des revues de code et des tests d'intrusion au moins deux fois par an, et de protéger l'authentification contre le rejeu et le détournement. Ostorlab vous aide à tester votre application et ses API à chaque version, entre les campagnes planifiées.
- Tests d'intrusion par agents IA derrière la connexion, avec un exploit à rejouer pour chaque résultat d'un agent IA
- Tests statiques et dynamiques de la version que vous livrez, sans besoin du code source
- Sessions, codes à usage unique et parcours d'authentification renforcée testés avec vos comptes de test
- Scan on-premises lorsque les données doivent rester sur une infrastructure que vous contrôlez
- Qui est concerné
- Les banques de l'État du Qatar
- Base juridique
- Règlement de la QCB sur les risques technologiques, janvier 2018, avec un rapport de conformité annuel à la QCB
- Fréquence
- Évaluations de vulnérabilité, revues de code et tests d'intrusion au moins deux fois par an
- Référence
- QCB Technology Risks regulation, Cloud Computing Regulation, Data Handling and Protection Regulation
Les règles de la QCB sur les risques technologiques, date par date
Les textes de la QCB cités sur cette page sont en vigueur aujourd'hui. Voici les dates et les fréquences au regard desquelles les tests de votre application sont évalués.
- 22 novembre 2012
Circulaire sur les risques de la banque électronique
La circulaire n° 105/2012 sur les risques des technologies modernes et des services de banque électronique, renforcée ensuite par le règlement de 2018.
- Janvier 2018
Règlement sur les risques technologiques
Les exigences de cybersécurité de la QCB pour les banques, notamment les tests des applications, les tests d'intrusion et la banque en ligne et mobile.
- 15 avril 2024
Règlement sur le cloud computing
Une approbation de la QCB avant tout recours au cloud, et des données personnelles (PII) et informations financières traitées exclusivement au Qatar.
- Deux fois par an
Évaluations et tests d'intrusion
Des évaluations de vulnérabilité, revues de code et tests d'intrusion au minimum deux fois par an, ou plus souvent si nécessaire.
- Tous les six mois
Revue des risques acceptés
L'acceptation des risques liés aux vulnérabilités existantes est revue chaque semestre.
- Chaque année
Rapport de conformité à la QCB
Une évaluation annuelle de la conformité, et un rapport à la QCB signé par le conseil d'administration ou un comité mandaté par celui-ci.
Les règles de la QCB sur les risques technologiques, appliquées à votre application mobile
Le règlement de la QCB sur les risques technologiques fixe les règles de test et de sécurité des banques, et ses règles sur le cloud et les données déterminent quels prestataires peuvent accéder à vos données. 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.
- QCB Technology Risks regulation, 9.4.2.2
Tester les applications web et mobiles sur tout leur cycle de vie
Ce que dit le texte
La banque doit réaliser des tests de sécurité des applications web et mobiles tout au long de leur cycle de vie : avant la mise en production, après la mise en production et après tout changement majeur. Les rapports sont partagés avec les parties prenantes et suivis jusqu'à leur clôture.
Ce que cela implique pour votre application mobile
Chaque version de l'application qui apporte un changement significatif nécessite un test de sécurité avant et après sa mise en production, et chaque résultat doit avoir un responsable et une date de clôture.
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. Les résultats sont classés critiques, élevés, moyens ou faibles, suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif livré.
Ce qui reste de votre ressort
La définition de ce qui constitue un changement majeur, et le partage des rapports avec les parties prenantes.
- QCB Technology Risks regulation, 9.4.2.3 et 9.4.3.3
Évaluations de vulnérabilité, revues de code et pentests deux fois par an
Ce que dit le texte
La banque doit réaliser des évaluations de vulnérabilité, des revues de code et des tests d'intrusion au minimum deux fois, ou plus souvent si nécessaire, sur une base annuelle pour l'ensemble de l'infrastructure applicative, et mener deux exercices de test d'intrusion par an, ou davantage si nécessaire.
Ce que cela implique pour votre application mobile
Votre application mobile et les API qui la sous-tendent nécessitent au moins deux campagnes d'évaluation et de pentest chaque année. Les versions publiées entre deux campagnes ne sont pas testées, sauf si vous en ajoutez.
Comment Ostorlab vous aide
Les scans rapides se terminent généralement en 1 à 5 minutes et les scans complets en 15 à 45 minutes : ils s'intègrent donc à chaque version. Un pentest par agents IA va plus loin, généralement en quelques heures, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, pour les changements critiques et vos tests approfondis périodiques.
Ce qui reste de votre ressort
La planification des deux exercices annuels, le choix des testeurs et les tests de l'infrastructure hors application.
- QCB Technology Risks regulation, 9.4.3.1 à 9.4.3.4
Combiner outils et travail manuel, et comparer avec la campagne précédente
Ce que dit le texte
Utiliser une combinaison d'outils automatisés et de techniques manuelles pour une évaluation de vulnérabilité complète, selon des pratiques comme OWASP, OSSTMM ou SANS. Comparer les résultats avec les scans précédents pour vérifier que les vulnérabilités ont été traitées, partager un plan d'action avec la direction et revoir les risques acceptés chaque semestre.
Ce que cela implique pour votre application mobile
Un résultat qui réapparaît lors de la campagne suivante est un correctif en échec. Il vous faut un historique des scans par application pour démontrer la différence.
Comment Ostorlab vous aide
Votre équipe sécurité ou de deuxième ligne exécute les tests et détient les résultats. Chaque résultat s'accompagne d'un niveau de risque, d'étapes de reproduction, des journaux de requêtes et de réponses et de captures d'écran, et le retest confirme si le problème sous-jacent est résolu.
Ce qui reste de votre ressort
Les tests manuels, le plan d'action pour la direction et les décisions d'acceptation des risques.
- QCB Technology Risks regulation, 9.4.2.4, 9.7.1.1, 9.7.1.4 et 9.7.2.1
Développement sécurisé et revue du code source
Ce que dit le texte
Formuler des lignes directrices de développement applicatif sécurisé conformes à OWASP, aux normes de codage sécurisé du CERT et à MITRE CWE. Réaliser une revue du code source pour trouver les vulnérabilités issues de problèmes de codage, de mauvaises pratiques ou de tentatives malveillantes, et examiner les applications pour déterminer si elles tentent d'établir des connexions externes.
Source :QCB Technology Risks regulation, 9.4.2.4, 9.7.1.1, 9.7.1.4 et 9.7.2.1
Ce que cela implique pour votre application mobile
La revue de code devrait couvrir ce qui est livré dans l'application, y compris les SDK tiers, et vous devriez savoir avec quels backends l'application et ses SDK communiquent.
Comment Ostorlab vous aide
Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans besoin du code source, y compris par analyse de propagation (taint) à travers les SDK intégrés. Ostorlab montre ce que l'application et ses SDK échangent avec les backends sur le réseau, et recense les SDK et bibliothèques natives de chaque version.
Ce qui reste de votre ressort
La rédaction des lignes directrices de développement, la revue du code source hors application et le séquestre du code source.
- QCB Technology Risks regulation, 8.10.2.9, 8.10.2.13 et 10.10.3
Protéger l'authentification contre le rejeu et le détournement
Ce que dit le texte
Les données d'authentification des systèmes en cours d'utilisation doivent être protégées et ne pas être vulnérables à des attaques comme le rejeu, l'homme du milieu et le détournement de session. L'accès doit être suspendu après au plus trois tentatives d'authentification échouées. Pour la banque en ligne, la banque doit mettre en œuvre une authentification à deux facteurs pour la signature des transactions.
Source :QCB Technology Risks regulation, 8.10.2.9, 8.10.2.13 et 10.10.3
Ce que cela implique pour votre application mobile
Les jetons, les codes à usage unique et la gestion des sessions dans l'application et ses API doivent résister au rejeu et au détournement, et la signature des transactions doit exiger un second facteur côté serveur.
Comment Ostorlab vous aide
Ostorlab se connecte avec vos comptes de test, saisit les codes à usage unique reçus par SMS, e-mail ou TOTP, et teste 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, y compris les parcours d'authentification renforcée.
Ce qui reste de votre ressort
Les politiques de mots de passe, les seuils de verrouillage et la gestion des accès du personnel.
- QCB Technology Risks regulation, 10.10.8
Tester la banque en ligne contre les attaques de l'homme du milieu
Ce que dit le texte
La banque doit réaliser une évaluation de vulnérabilité et un test d'intrusion de son système de banque en ligne afin de réduire au minimum son exposition aux cyberattaques comme les attaques de type man-in-the-middle, man-in-the-browser ou man-in-the-application.
Ce que cela implique pour votre application mobile
Pour une application mobile, man-in-the-application désigne le hooking et l'altération sur l'appareil, et man-in-the-middle l'interception du trafic. Les deux peuvent être testés.
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.
- QCB Technology Risks regulation, 10.11.1 à 10.11.3
Sécuriser les services en ligne mobiles et les paiements
Ce que dit le texte
La banque doit mettre en œuvre des mesures de sécurité pour les services en ligne mobiles et les paiements, réaliser une évaluation des risques pour identifier les scénarios de fraude possibles, et garantir une protection adéquate des informations sensibles ou confidentielles utilisées pour les services en ligne mobiles et les paiements.
Ce que cela implique pour votre application mobile
Les données que l'application stocke et transmet, et les API derrière les paiements, sont l'endroit où les scénarios de fraude se transforment en pertes.
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 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.
Ce qui reste de votre ressort
L'évaluation des risques de fraude, la surveillance de la fraude en temps réel et la sensibilisation des clients.
- QCB Technology Risks regulation, II et 7.1
Rendre compte de la conformité à la QCB chaque année
Ce que dit le texte
Les banques doivent se conformer à la circulaire, réaliser au minimum une évaluation annuelle de leur conformité et soumettre à la QCB, au minimum une fois par an, un rapport de conformité signé par le conseil d'administration ou un comité mandaté par celui-ci. Les écarts significatifs nécessitent des mesures correctives, et la QCB peut auditer la banque à tout moment.
Ce que cela implique pour votre application mobile
Votre rapport annuel doit s'appuyer sur des preuves que les tests de l'application et des API ont eu lieu comme exigé et que les résultats ont été corrigés.
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'évaluation de la conformité, le rapport, la validation par le conseil d'administration et le dialogue avec la QCB.
- Data Handling and Protection Regulation, 7.6, 7.7 et 15.1 ; Cloud Computing Regulation, 21.4
Conserver les données clients au Qatar, y compris chez les prestataires
Ce que dit le texte
L'environnement principal de stockage et de traitement des informations personnelles, personnelles sensibles et financières sensibles doit se trouver au Qatar, sauf approbation contraire de la QCB. Ces données ne doivent pas être stockées ni transférées à l'étranger sans l'approbation de la QCB, et selon le règlement sur le cloud computing, les données personnelles (PII) et les informations financières sont traitées exclusivement au Qatar.
Source :Data Handling and Protection Regulation, 7.6, 7.7 et 15.1 ; Cloud Computing Regulation, 21.4
Ce que cela implique pour votre application mobile
Un prestataire de tests qui reçoit les binaires de l'application, des comptes de test et des captures de trafic est un tiers auquel s'appliquent vos règles sur les données.
Comment Ostorlab vous aide
Avec l'offre Enterprise, vous pouvez lancer les scans on-premises, sur une infrastructure que vous contrôlez, ou choisir la résidence des données dans les pays du CCG. Ostorlab a fait l'objet d'un audit SOC 2 Type II.
Ce qui reste de votre ressort
La décision de transmettre ou non des données clients au prestataire, et les éventuelles approbations de la QCB.
Synthèse des textes de la QCB publiés sur le site de la QCB, vérifiés le 27 septembre 2026. Cette page ne constitue pas un avis juridique.
Les règles de la QCB, contrôle par contrôle
Les contrôles visés par le règlement de la QCB sur les risques technologiques, la manière dont Ostorlab les teste dans votre application et ses API, et les preuves que vous pouvez conserver.
| Contrôle | Comment Ostorlab vous aide | Preuves conservées |
|---|---|---|
| Tests de sécurité des applications avant et après la mise en productionTR 9.4.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 de scan pour chaque build |
| Tests d'intrusion au moins deux fois par anTR 9.4.2.3, 9.4.3.3 | 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 |
| Comparaison avec les scans précédents, et suivi jusqu'à la clôtureTR 9.4.2.2, 9.4.3.1 | Regroupe les résultats en tickets dans la plateforme ou dans Jira et ServiceNow, et reteste après correction. Détails | Historique des tickets et issue du retest pour chaque résultat |
| Revue du code livré dans l'applicationTR 9.7.1.4 | Analyse de propagation (taint) à travers les SDK intégrés, et analyse des dépendances de l'application compilée. Détails | Résultats attribués au SDK ou à la bibliothèque dont ils proviennent |
| Connexions externes établies par l'applicationTR 9.7.2.1 | 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 |
| Correction des vulnérabilités connues dans les composantsTR 8.3 | Identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, d'une version à l'autre. Détails | Vulnérabilités identifiées avec recommandations de mise à niveau ou de remplacement, et résolution suivie d'une version à l'autre |
| Rejeu, homme du milieu et détournement de sessionTR 8.10.2.9 | 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 |
| Signature des transactions à deux facteurs et verrouillageTR 8.10.2.13, 10.10.3 | 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 |
| Attaques man-in-the-applicationTR 10.10.8 | Injecte des débogueurs et des hooks et adapte sa tentative pour contourner les défenses anti-instrumentation. Détails | Preuves des protections qui ont tenu et de celles qui ont été contournées |
| Protection des données sensibles dans les services mobiles et les API de paiementTR 10.11.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 |
Ostorlab teste les contrôles dans l'application et ses API. La gouvernance, les ressources humaines, la continuité d'activité, les centres de données, la surveillance de la sécurité, la surveillance de la fraude, la sensibilisation des clients et le reporting à la QCB restent du ressort de vos équipes.
Les contrôles QCB à tester dans votre application cette année
Une liste pratique pour les équipes sécurité et conformité qui travaillent avec le règlement de la QCB sur les risques technologiques.
Deux campagnes de tests planifiées
Planifiez au moins deux campagnes d'évaluation de vulnérabilité et de test d'intrusion par an pour l'application et ses API, et des scans à chaque version dans l'intervalle.
Avant et après la mise en production
Testez chaque version majeure avant sa mise en œuvre puis à nouveau une fois en production, et suivez chaque résultat jusqu'à sa clôture.
Comparer avec la campagne précédente
Vérifiez que les résultats de la campagne précédente ont disparu, et revoyez les risques acceptés tous les six mois.
Ce qui est livré dans l'application
Recensez les SDK et bibliothèques de chaque version, ainsi que les backends auxquels l'application et ses SDK se connectent.
Sessions et codes à usage unique
Testez le rejeu des jetons et des codes, le détournement de session, le verrouillage après trois tentatives échouées et la signature des transactions à deux facteurs.
Hooking et interception
Exécutez l'application sur des appareils rootés et jailbreakés, avec des hooks et l'interception du trafic, et confirmez qu'elle réagit.
Données sur l'appareil et dans les API
Recherchez les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et testez les autorisations sur chaque API de paiement.
Preuves pour le rapport annuel
Conservez les résultats de scan, les tickets et les retests de chaque version, prêts pour le rapport de conformité à la QCB.
Une liste indicative, et non un modèle de la QCB. 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 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 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
- Tests authentifiésTestez la connexion, les codes à usage unique et les parcours d'authentification renforcée avec vos comptes de test.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
- 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
- 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
- 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
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.
- QCB Technology Risks regulation for banksBanque centrale du Qatar, janvier 2018. S'applique aux banques au Qatar et renforce la circulaire sur les risques des technologies modernes et des services de banque électronique. Couvre les tests de sécurité des applications, les tests d'intrusion, l'authentification, la banque en ligne et mobile et le reporting annuel de conformité
- QCB Instructions to Banks, Annex 192: Modern Technology and E-Banking Services RisksBanque centrale du Qatar, circulaire n° 105/2012 du 22 novembre 2012, dans les Instructions to Banks de septembre 2013. La circulaire antérieure sur les risques technologiques que le règlement de 2018 a renforcée
- QCB Cloud Computing RegulationBanque centrale du Qatar, en vigueur depuis le 15 avril 2024, pour toutes les entités régulées par la QCB qui utilisent le cloud computing. Approbation de la QCB avant tout recours au cloud, données personnelles (PII) et informations financières traitées exclusivement au Qatar
- QCB Data Handling and Protection RegulationBanque centrale du Qatar, pour toutes les institutions financières sous la supervision de la QCB. Environnement principal des données au Qatar, approbation de la QCB pour le stockage ou le transfert à l'étranger, accès des tiers. La date de publication n'est pas indiquée dans le document
- QCB Information and Cyber Security Regulation for Payment Service ProvidersBanque centrale du Qatar, 2022, pour les prestataires de services de paiement relevant du QCB Payment Services Regulation, pas les banques. Inclut des tests d'intrusion au moins deux fois par an
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 entre deux campagnes QCB
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer avec notre équipe des tests authentifiés et d'API.