أمن واجهات API في تطبيقات الموبايل والربط بين الأنظمة: قائمة OWASP عملياً

تطبيق الموبايل هو الجزء الظاهر فقط. خلف شاشة الطلبات وتتبع الشحنة وتطبيق المندوب توجد واجهة برمجية (API) تتصل بقاعدة البيانات ونظام ERP وبوابة الدفع وشركة الشحن. والمهاجم يعرف ذلك: يتجاهل التطبيق، ويراقب الطلبات التي يرسلها، ثم يتصل بالـ API مباشرة. لذلك فإن أمن API هو ما يحدد هل تبقى بيانات العملاء وأموالك في مكانها، سواء كنت متجراً إلكترونياً في القاهرة أو شركة توزيع لديها مناديب في الدلتا أو عيادة لها تطبيق حجز.

الإجابة المختصرة: أمن واجهات API يعني أن يتحقق السيرفر من هوية المتصل (المصادقة)، ومما يحق له الوصول إليه من سجلات ووظائف (الصلاحيات)، ومن الكمية المسموح بها (حدود الاستخدام)، ومن صحة ما يرسله (التحقق من المدخلات)، مع إبقاء مفاتيح الربط على السيرفر وتسجيل ما يحدث. والمرجع المعتمد هو قائمة OWASP API Security Top 10 إصدار 2023، وفي هذا الدليل نشرحها بأمثلة عملية وأسئلة توجهها للمبرمج.

الخلاصة السريعة

• الخطر الأول في قائمة OWASP لأمن API هو ضعف الصلاحيات على مستوى السجل (BOLA): تغيير رقم الطلب في الطلب البرمجي فيظهر طلب عميل آخر.
• كل طلب يصل إلى API يجب فحص صلاحيته على السيرفر للسجل المحدد والإجراء المحدد، لا الاكتفاء بسؤال "هل المستخدم مسجل دخوله؟".
• كل ما يوضع داخل تطبيق الموبايل يمكن استخراجه؛ مفاتيح الدفع والشحن والرسائل والفاتورة الإلكترونية مكانها السيرفر فقط.
• حدود الاستخدام وسقف الإنفاق تحميك من البوتات التي تستغل رسائل OTP والحجوزات والكوبونات والطلبات الوهمية.
• تحقق من كل مدخل وفق مخطط (Schema)، وتعامل مع بيانات واجهات الشركاء كبيانات غير موثوقة أيضاً.
• احتفظ بقائمة بكل إصدارات API ونقاطها، وسجّل من وصل إلى ماذا.

قائمة OWASP لأمن API (إصدار 2023) بلغة بسيطة

تنشر OWASP قائمة مستقلة لواجهات API لأن أخطاءها تختلف عن أخطاء صفحات الويب. وتضم قائمة OWASP API Security Top 10 لعام 2023 ما يلي:

ولقائمة تطبيقات الويب العامة راجع دليلنا شرح OWASP Top 10 إصدار 2025 لأصحاب الشركات.

ضعف الصلاحيات على مستوى السجل: مثال رقم الطلب

تخيل تطبيق متجر في القاهرة. عندما يفتح العميل "طلبي" يرسل التطبيق GET /api/orders/10452. يسجل المهاجم الدخول بحسابه العادي، ويلتقط الطلب بأداة مجانية، ويغيّره إلى /api/orders/10453. إذا كان السيرفر يتحقق فقط من أن رمز الدخول صالح، فسيرجع اسم عميل آخر وعنوانه وتليفونه ومحتوى سلته، ويستطيع سكربت بسيط أن يمر على كل أرقام الطلبات في دقائق.

هذا بالضبط ما تصفه صفحة OWASP للبند API1:2023: المهاجم يتلاعب بمعرّف السجل المرسل في الطلب. وتوصياتها للوقاية باختصار:

• آلية صلاحيات مبنية على سياسات المستخدمين وتسلسلهم.
• فحص الصلاحية في كل وظيفة تصل إلى سجل باستخدام معرّف يرسله العميل.
• تفضيل معرّفات عشوائية غير قابلة للتوقع (GUID) للسجلات.
• كتابة اختبارات للصلاحيات ومنع نشر أي تعديل يفشل فيها.

كيف يبدو الإصلاح؟

يجب أن يجلب السيرفر السجل مع شرط المالك داخل الاستعلام نفسه، مثل SELECT * FROM orders WHERE id = $1 AND customer_id = $2، بحيث يأتي رقم العميل من رمز الدخول الموثّق لا من جسم الطلب. المعرّفات العشوائية تصعّب التخمين لكنها ليست الحل، فقد يتسرب المعرّف في رابط أو لقطة شاشة. الحل الحقيقي هو فحص الملكية.

الفكرة نفسها للحقول والوظائف

• الحقول (API3): أرجع لكل دور الحقول التي يحتاجها فقط. واجهة المنتجات العامة لا يجب أن تتضمن سعر التكلفة أو رصيد كل مخزن. وعند التعديل اقبل قائمة محددة من الحقول حتى لا يرسل أحد "isAdmin": true أو يرفع حد الائتمان الخاص به.
• الوظائف (API5): افحص الدور في كل نقطة. تطبيق مندوب التوزيع يستدعي "إنشاء طلب" و"تسجيل تحصيل"، لا "اعتماد خصم" أو "تعديل رصيد عميل". وتجد تفاصيل تصميم الأدوار في دليل صلاحيات المستخدمين وسجل التدقيق في ERP وCRM.

المصادقة ورموز الدخول في تطبيقات الموبايل

تستخدم أغلب تطبيقات الأعمال رموز وصول قصيرة العمر مثل JWT مع رمز تجديد (Refresh Token) أطول عمراً. والممارسة الجيدة:

• اجعل رمز الوصول قصير العمر، وتحقق من توقيعه وانتهائه والجهة المقصودة به في كل طلب.
• دوّر رمز التجديد مع كل استخدام، واحفظه مجزّأً (Hashed) على السيرفر، وألغِه عند الخروج وتغيير كلمة المرور وخروج الموظف من الشركة.
• على الموبايل احفظ الرموز في التخزين الآمن للنظام (Android Keystore وiOS Keychain) لا في ملفات عادية.
• في نسخة الويب من النظام نفسه احفظ رموز الجلسة في كوكيز HttpOnly حتى لا تقرأها سكربتات الصفحة.
• احمِ نقاط الدخول وOTP واستعادة كلمة المرور بحدود للمحاولات، وفعّل التحقق بخطوتين لحسابات الموظفين والمديرين. راجع دليل التحقق بخطوتين وكلمات المرور ومفاتيح المرور.

إذا كان التطبيق يسجل الدخول عبر OAuth

إذا كان تطبيقك يسجل دخول المستخدمين عبر مزود OAuth أو سيرفر تفويض خاص بك، فاتبع المعيار RFC 8252 "OAuth 2.0 للتطبيقات الأصلية" (IETF، 2017). ينص المعيار على أن التطبيقات العامة يجب أن تطبق PKCE، وأنه لا يجوز استخدام متصفح مدمج داخل التطبيق لطلبات التفويض، وأن الأسرار المضمّنة في تطبيق يوزَّع على مستخدمين كثيرين لا تُعامل كأسرار سرية.

حدود الاستخدام واستغلال مسارات العمل

واجهة API بلا حدود دعوة مفتوحة للاستغلال. تعرض صفحة OWASP للبند API4:2023 سيناريو واضحاً: مهاجم استدعى مراراً نقطة استعادة كلمة المرور التي ترسل كوداً عبر SMS، فتسبب في آلاف الرسائل المدفوعة وكلّف الشركة آلاف الدولارات خلال دقائق. والشيء نفسه يحدث مع شاشات التسجيل بـ OTP في التطبيقات المصرية.

حدود يجب أن تكون في كل API

• تحديد معدل الطلبات لكل مستخدم ولكل IP ولكل نقطة، مع تشديده على الدخول وOTP واستعادة كلمة المرور والبحث.
• حد أقصى لعدد السجلات في الصفحة الواحدة (لا يسحب المندوب 50 ألف عميل في طلب واحد).
• حد أقصى لحجم الملفات المرفوعة وحجم الطلب.
• مهلة تنفيذ للتقارير والتصديرات الثقيلة.
• سقف إنفاق وتنبيهات فواتير لدى مزودي الرسائل وواتساب والبريد والذكاء الاصطناعي.

حماية مسارات العمل الحساسة (API6)

بعض الاستغلال يستخدم الـ API كما صُمم تماماً لكن بكميات ضخمة: حجز كل مواعيد عيادة في الإسكندرية، أو إنشاء مئات طلبات الدفع عند الاستلام بعناوين وهمية، أو الحصول على كوبون الطلب الأول من حسابات جديدة لا تنتهي. والدفاع يكون بحدود لكل رقم تليفون وجهاز، وتحقق قبل الإجراءات المكلفة، ومراجعة الأنماط المشبوهة، وقواعد عمل مثل كوبون واحد لكل رقم موثّق.

التحقق من المدخلات وسياسة CORS ومعالجة الأخطاء

• تحقق من كل طلب على السيرفر وفق مخطط، مثلاً باستخدام Zod: النوع والطول والصيغة والقيم المسموحة، مع رفض الحقول غير المعروفة.
• استخدم استعلامات بمعاملات (Parameterized) أو ORM موثوقاً حتى لا تُنفذ المدخلات كأوامر SQL.
• احسب المبالغ على السيرفر: الأسعار والخصومات والشحن والإجمالي لا تؤخذ من التطبيق أبداً.
• اضبط سياسة CORS صارمة لعملاء المتصفح. CORS تحدد أي المواقع يمكنها استدعاء الـ API من المتصفح، لكنها ليست مصادقة ولا تمنع السكربتات أو تطبيقات الموبايل.
• أرجع رسائل خطأ عامة للعميل، واحتفظ بالتفاصيل التقنية في سجلات السيرفر فقط.

الربط مع بوابات الدفع وشركات الشحن والفاتورة الإلكترونية

تتصل أنظمة الشركات في مصر بواجهات خارجية كثيرة: بوابات الدفع مثل Paymob وفوري، وشركات الشحن والتحصيل، ومزودي SMS وواتساب، ومنظومتي الفاتورة الإلكترونية والإيصال الإلكتروني لمصلحة الضرائب. والقاعدة بسيطة: التطبيق يتحدث مع الـ API الخاص بك فقط، والسيرفر هو الذي يتحدث مع الشركاء.

المفاتيح تبقى على السيرفر

• لا تضع أبداً المفتاح السري لبوابة الدفع أو مفتاح شركة الشحن أو بيانات مزود الرسائل أو بيانات ربط الفاتورة الإلكترونية داخل التطبيق أو كود الواجهة؛ فالتطبيق يمكن تفكيكه.
• احفظ الأسرار في متغيرات البيئة أو مدير أسرار، لا في مستودع الكود، وامنح كل مفتاح أقل صلاحيات يحتاجها.
• التوقيع الإلكتروني للفاتورة (التوكن USB أو HSM) وخدمة التوقيع مكانهما سيرفر مُحكم، لا لابتوبات الموظفين.

تحقق مما يعود إليك

• إشعارات الدفع (Callbacks): تحقق من توقيع البوابة قبل اعتبار الطلب مدفوعاً. فمثلاً توضح وثائق Paymob أن إشعاراتها تعتمد على مصادقة HMAC للتحقق من هوية المرسل وسلامة البيانات، وتُحسب بخوارزمية SHA512 مع سر HMAC الموجود في لوحة التحكم.
• المبلغ والحالة: قارن المبلغ المدفوع والعملة بالطلب المسجل لديك، واجعل التحديث آمناً عند التكرار حتى لا يُشحن الطلب مرتين إذا وصل الإشعار مرتين.
• ردود شركات الشحن والشركاء (API10): تحقق منها كما تتحقق من مدخلات المستخدم، واستخدم مهلة زمنية، واجعل النظام يفشل بأمان إذا توقف الشريك.

ولمخاطر الدفع الخاصة بالمتاجر راجع أمان المتجر الإلكتروني أبعد من HTTPS.

جرد الواجهات والإصدارات والسجلات

اعرف كل نقطة مكشوفة (API9)

تطبيقات الموبايل تخلق مشكلة خاصة: الإصدارات القديمة تبقى على موبايلات العملاء شهوراً، فتبقى إصدارات API القديمة تعمل أيضاً. احتفظ بقائمة مكتوبة بكل عنوان وإصدار ونقطة، ووثّق أي إصدارات التطبيق تستخدمها، وحدد موعداً لإيقافها، وطبّق الفحوصات الأمنية نفسها على القديم والجديد. وسيرفرات التجربة (Staging) لا يجب أن تكون متاحة على الإنترنت ومعها بيانات حقيقية.

سجلات للتحقيق لا للتسريب

• سجّل من استدعى أي نقطة، ولأي سجل، ومن أين، وما النتيجة، بصيغة منظمة مثل التي تنتجها Pino.
• لا تسجل كلمات المرور أو الرموز أو أرقام البطاقات الكاملة أو بيانات شخصية غير ضرورية.
• فعّل تنبيهات للارتفاعات المفاجئة: أخطاء 403 كثيرة من مستخدم واحد (علامة على تخمين المعرّفات)، أو دفعات من طلبات OTP، أو تصديرات غير معتادة.

السجلات تجيب عن سؤال "بيانات من تسربت؟" بعد أي حادث. ويشرح دليل تسريب البيانات والإخطار خلال 72 ساعة خطوات الاستجابة.

قائمة فحص أمن API: ماذا تسأل المبرمج؟

وقبل الإطلاق يستحق الأمر التفكير في اختبار مستقل يركز على الـ API للتطبيقات التي تتعامل مع مدفوعات أو بيانات شخصية؛ راجع اختبار الاختراق وتقييم الثغرات.

كيف تساعدك Nilex

تصمم Nilex واجهات REST API لتطبيقات الويب والموبايل وهذه الضوابط مبنية فيها: فحص الملكية لكل سجل، وفحص الدور لكل وظيفة، والتحقق من المدخلات بـ Zod، وتحديد معدل الطلبات، ورموز JWT قصيرة العمر مع تدوير رموز التجديد، وسياسة CORS صارمة، وربط بوابات الدفع وشركات الشحن من السيرفر بحيث لا تصل المفاتيح إلى التطبيق أبداً. ويمكننا أيضاً مراجعة API قائم وفق قائمة OWASP لأمن API وإصلاح ما نجده.

الأسئلة الشائعة

ما هو أمن API؟

هو مجموعة الضوابط التي تحمي الواجهات التي تستخدمها تطبيقاتك وشركاؤك لقراءة البيانات وتعديلها: المصادقة، والصلاحيات لكل سجل وإجراء، وحدود الاستخدام، والتحقق من المدخلات، وإدارة الأسرار، والسجلات. وأهميته أن المهاجم يستطيع استدعاء الـ API مباشرة دون المرور بتطبيقك.

ما أشهر ثغرة في واجهات API؟

ضعف الصلاحيات على مستوى السجل (BOLA) هو البند الأول في قائمة OWASP لأمن API لعام 2023. يحدث عندما يرجع السيرفر سجلاً أو يعدله بناءً على المعرّف المرسل فقط، دون التأكد أن السجل يخص صاحب الطلب.

هل وضع مفاتيح API داخل تطبيق الموبايل آمن؟

لا بالنسبة للمفاتيح السرية. كل ما يوضع في التطبيق يمكن استخراجه، والمعيار RFC 8252 ينص على أن الأسرار المضمّنة في تطبيق يوزَّع على مستخدمين كثيرين لا تُعامل كأسرار سرية. احفظ مفاتيح الدفع والشحن والرسائل على السيرفر، واجعل التطبيق يستدعي الـ API الخاص بك.

هل HTTPS يكفي لحماية الـ API؟

HTTPS يحمي البيانات أثناء انتقالها وهو ضروري، لكنه لا يتحقق من أن المستخدم المسجل يحق له رؤية طلب معين أو استدعاء وظيفة إدارية. وأخطر ثغرات API مشكلات صلاحيات ومنطق عمل لا يلمسها HTTPS.

كيف أمنع البوتات من استغلال رسائل OTP والتسجيل؟

ضع حداً للطلبات لكل رقم تليفون وجهاز وIP، وفترة انتظار بين رسائل OTP، وسقف إنفاق لدى مزود الرسائل، وتنبيهات للكميات غير المعتادة. وتصنف OWASP هذا تحت البند API4:2023 استهلاك الموارد بلا قيود.

تبني تطبيق موبايل أو تربط نظامك ببوابات الدفع وشركات الشحن والفاتورة الإلكترونية؟ اطلب مراجعة أمنية للـ API أو استشارة مجانية عبر صفحة التواصل.