أمن واجهات API في القطاع المالي السعودي: كيف يستغل المهاجمون البنوك المفتوحة قبل أن يكتشفها SOC لديك

في ظل تسارع تطبيق مبادرة البنوك المفتوحة التي تقودها هيئة المدفوعات السعودية بالتنسيق مع متطلبات SAMA، باتت واجهات برمجة التطبيقات (APIs) تُشكّل ما يزيد على 83% من حركة بيانات المؤسسات المالية السعودية — وفي الوقت ذاته، أصبحت المسار المفضّل للمهاجمين الذين وجدوا فيها بوابات مفتوحة يصعب على SIEM التقليدي رصدها أو إغلاقها.

لماذا تُستهدف API المصرفية بشكل متزايد؟

تختلف هجمات API جوهريًا عن الهجمات الشبكية التقليدية؛ فبدلًا من اختراق جدران الحماية، يستخدم المهاجمون بيانات اعتماد مسرّبة أو توكنات JWT منتهية الصلاحية أو يستغلون منطق الأعمال (Business Logic) نفسه للوصول إلى بيانات العملاء وتنفيذ معاملات غير مصرّح بها. بحسب تقرير Salt Security لعام 2025، شهدت هجمات API الموجهة للقطاع المالي ارتفاعًا بنسبة 137% مقارنةً بالعام السابق، مع تركّز 61% منها في ثغرات التفويض المعطوب (BOLA/IDOR) التي لا تُثير عادةً أي تنبيهات في بيئات SIEM القياسية. الأخطر من ذلك أن الهجوم الناجح على API لا يُخلّف أثرًا واضحًا في سجلات الشبكة، لأنه يُشبه من الخارج طلبًا مشروعًا تمامًا.

أبرز ثغرات OWASP API Security التي تواجهها المؤسسات المالية

تُصنّف OWASP في قائمتها المحدّثة التفويض المعطوب على مستوى الكائن (BOLA) بوصفه الخطر الأول على API المصرفية؛ إذ يسمح لمستخدم مصادق عليه بالوصول إلى بيانات حسابات مستخدمين آخرين بمجرد تعديل معرّف في طلب API. المشكلة أن هذا الطلب يبدو "شرعيًا" تمامًا لأنظمة الكشف التقليدية. يليه إساءة المصادقة (Broken Authentication) حيث تُستهدف نقاط نهاية إصدار التوكن وتجديده، وغالبًا ما يكون سببها توكنات JWT بصلاحيات مفرطة أو مفاتيح API ثابتة لم تُجدَّد منذ سنوات. كذلك تبرز مشكلة التعرّض المفرط للبيانات (Excessive Data Exposure): حين تُعيد بعض API المصرفية حقولًا أكثر مما يحتاجه التطبيق الأمامي، بما فيها أرصدة الحسابات وبيانات KYC، مما يُحوّل كل طلب ناجح إلى مخاطرة فعلية بتسريب البيانات، حتى دون وجود نية هجومية واضحة في البداية.

تأثير هجمات API على المؤسسات المالية الخاضعة لـ SAMA

لا يُعدّ اختراق API مجرد حادثة تقنية — بل يُشكّل انتهاكًا مباشرًا لعدة متطلبات في SAMA CSCC، لا سيما المحور 3.3 الخاص بحماية البيانات والمحور 4.2 المتعلق بإدارة الهوية والوصول. علاوةً على ذلك، يرتّب اختراق بيانات العملاء عبر API التزامات إخطار صارمة بموجب نظام حماية البيانات الشخصية (PDPL) تمتد إلى 72 ساعة، مع احتمال تغريم يصل إلى 5 ملايين ريال للمخالفة الأولى. الأخطر أن كثيرًا من المؤسسات لا تمتلك حتى الآن جردًا شاملًا بواجهات API النشطة، مما يعني أن جزءًا كبيرًا من سطح الهجوم غير مرئي لفريق الأمن من الأساس — وهو سيناريو غير مقبول في بيئة تنظيمية تشترط إدارة المخاطر الكاملة.

التوصيات والخطوات العملية

1. اكتشاف وجرد API بشكل مستمر: استخدم أدوات مثل Traceable AI أو Salt Security أو Noname Security لرسم خريطة كاملة لجميع واجهات API في بيئة الإنتاج، بما فيها API الظلّية (Shadow APIs) التي أُطلقت خلال مشاريع تقنية دون مراجعة أمنية مسبقة.
2. تطبيق RBAC دقيق وتحديد الصلاحيات بأقل امتياز: راجع جميع توكنات OAuth 2.0 وتأكد من تطبيق مبدأ أقل الصلاحيات (Least Privilege)؛ لا ينبغي لأي توكن مصرفي أن يحمل صلاحيات قراءة وكتابة على موارد متعددة دون قيود صريحة ومحددة بالوقت.
3. اختبار اختراق API تخصصي ربع سنوي: يختلف اختبار اختراق API عن اختبار تطبيق الويب التقليدي؛ تأكد من أن فريقك يُجري اختبارات BOLA وBFLA (التفويض المعطوب على مستوى الوظيفة) باستخدام أدوات مثل Postman، Burp Suite Enterprise API Scanner، وAupas.
4. بوابة API مع تحليل سلوكي واستخبارات تهديد: تجاوز WAF التقليدي إلى حلول WAAP (Web Application and API Protection) التي تُحلّل أنماط سلوك API وترصد الانحرافات عن خط الأساس السلوكي الطبيعي، وتربط الأنماط الشاذة بالسياق الكامل للجلسة.
5. دمج أمن API في دورة تطوير البرمجيات (SDLC): وثّق جميع API بمعايير OpenAPI (Swagger 3.0+) وأدرج متطلبات الأمان في مرحلة التصميم وليس بعد النشر — هذا ما يتطلبه إطار SAMA CSCC في المحور 3.5 الخاص بأمن التطوير، وهو أيضًا صلب نهج Security by Design الذي أصبحت هيئة الاتصالات والفضاء والتقنية (CITC) تُرسّخه.

الخلاصة

البنوك المفتوحة قادمة ولا رجعة فيها — وهذا خبر جيد للعملاء ومحفّز حقيقي للابتكار المالي في المملكة. لكنه في الوقت نفسه يُوسّع سطح الهجوم بشكل غير مسبوق. المؤسسات التي ستُحكم التوازن بين الانفتاح الرقمي والحماية المؤسسية هي من تستثمر اليوم في برنامج أمن API استراتيجي — لا رقعة دفاعية بعد الاختراق. الجرد الكامل، والتفويض الدقيق، والاختبار الدوري، وتحليل السلوك: هذه هي الأعمدة الأربعة لأمن API الناضج وفق SAMA CSCC.

هل مؤسستك مستعدة؟ تواصل مع فريق فنترالينك لتقييم مجاني لمدى النضج السيبراني وفق SAMA CSCC، بما يشمل مراجعة متخصصة لأمن واجهات API لديكم.