Mobile + API Combined Assessment

Comprehensive assessment covering both mobile app and backend API

حول هذه الخدمة

تقييمنا المجمَّع للجوّال والـ API يختبر تطبيق جوّال والواجهة الخلفية (API) التي يتحدّث إليها بوصفهما نظاماً واحداً، من طرف إلى طرف. يُختبر التطبيق بـ OWASP MASVS وMASTG؛ وتُختبر الواجهة الخلفية بـ OWASP API Security Top 10. ويقع معظم الضرر الفعلي عند الحدّ الفاصل بينهما — رمز (token) يثق به التطبيق أكثر من اللازم، أو معرّف كائن لا يتحقّق الخادم من ملكيته، أو وظيفة يخفيها التطبيق لكنّ الـ API ما زال يكشفها. نختبر كلّ جانب ثمّ التدفّقات التي تعبر الحدّ: كيف يُصادِق التطبيق، وما الذي يرسله، وما إذا كان الـ API يفرض القواعد نفسها التي يبدو أنّ التطبيق يفرضها. ويُتابَع كلّ نتيجة حتى إثبات عملي، وتُصنَّف وفق CVSS إلى جانب أثرها الفعلي، وتُوثَّق مع إصلاح ملموس.

ما الذي تتضمّنه الخدمة

اختبار تطبيق الجوّال وفق OWASP MASVS وMASTG: التخزين والتشفير والمنصّة والشبكة والصمود

اختبار الواجهة الخلفية (API) وفق OWASP API Security Top 10

تفويض معطوب على مستوى الكائن (BOLA): هل يستطيع مستخدم بلوغ كائنات مستخدم آخر بتغيير معرّف؟

مصادقة معطوبة ورموز (tokens) ضعيفة أو قابلة للتزوير

تفويض معطوب على مستوى الوظيفة وعلى مستوى خصائص الكائن — إجراءات أو حقول يخفيها التطبيق لكنّ الـ API ما زال يسمح بها

استهلاك غير مقيَّد للموارد وغياب تحديد المعدّل

تدفّق المصادقة والرموز (tokens) بين التطبيق والـ API، بما في ذلك التجديد وتسجيل الخروج

التحقّق من الشهادات وتثبيتها (pinning)، وحركة البيانات القابلة للاعتراض أو إعادة التشغيل

الأسرار ومفاتيح الـ API المضمَّنة في التطبيق

التهيئة الأمنية الخاطئة والجرد غير السليم لنقاط نهاية الـ API وإصداراته

كيف يعمل

1
تحديد النطاق والوصول
نرسم خريطة الجانبين — التطبيق ونقاط نهاية الـ API التي يستخدمها — ونحدّد العمق: الصندوق الأسود من الخارج، أو الصندوق الرمادي مع حسابات اختبار ووثائق الـ API، أو الصندوق الأبيض مع الوصول إلى الكود المصدري. نطلب بناءً، وحسابين على الأقلّ لكلّ دور كي نختبر مستخدماً في مواجهة آخر، وبيئة staging كي تبقى بيانات الإنتاج دون مساس.
2
اختبار تطبيق الجوّال
نختبر التطبيق بـ OWASP MASVS وMASTG: ما يخزّنه على الجهاز، وكيف يشفّر البيانات ويحتفظ بالمفاتيح، ومكوّناته المُصدَّرة واستخدامه للمنصّة، وكيف يتعامل مع الرموز (tokens). وهنا أيضاً نستخرج أيّ أسرار أو مفاتيح API مشحونة داخل التطبيق.
3
اختبار الواجهة الخلفية (API)
نختبر الـ API بـ OWASP API Security Top 10، مُشغّلين إيّاه مباشرةً لا عبر التطبيق وحده. وينصبّ التركيز على التفويض: الوصول على مستوى الكائن بحساب ثانٍ، والوصول على مستوى الوظيفة إلى إجراءات يخفيها التطبيق، والوصول على مستوى الخاصية إلى حقول لا يعرضها قطّ، إضافةً إلى المصادقة وتحديد المعدّل والتهيئة الخاطئة.
4
من طرف إلى طرف والتكامل
نختبر الحدّ الفاصل بين التطبيق والـ API: تدفّق المصادقة والرموز (tokens)، وما إذا كان الـ API يثق بقيم يرسلها العميل وكان ينبغي أن يتحقّق منها، وما إذا كان النقل محميّاً وصامداً أمام الاعتراض وإعادة التشغيل، وما إذا كانت قاعدة يفرضها التطبيق في واجهته مفروضةً فعلاً على الخادم.
5
التحقّق وإعداد التقرير وإعادة الاختبار
يُتحقّق من كلّ نتيجة بإثبات مفهوم قابل لإعادة الإنتاج، وتُوسَم بأنها على جانب التطبيق أو جانب الـ API أو التكامل، وتُصنَّف وفق CVSS والأثر الفعلي على العمل، وتُوثَّق مع إصلاح مرتّب بحسب الأولوية. وبعد معالجتكم، نعيد الاختبار للتأكّد من ثبات الإصلاحات.
المُخرجات
  • ملخّص تنفيذي مع نظرة عامة مجمَّعة على المخاطر لصنّاع القرار
  • تقرير فنّي مفصّل، كلّ نتيجة مع إثبات مفهوم قابل لإعادة الإنتاج
  • نتائج جانب التطبيق مربوطة بـ OWASP MASVS
  • نتائج جانب الـ API مربوطة بـ OWASP API Security Top 10
  • نتائج التكامل عند الحدّ الفاصل — تدفّق الرموز (tokens) والنقل والفرض على جانب الخادم
  • درجة خطورة CVSS والأثر على العمل لكلّ نتيجة
  • خارطة طريق للمعالجة مرتّبة بحسب الأولوية عبر التطبيق والـ API
  • إعادة اختبار بعد المعالجة

لماذا حافظ سيكيور

نظام واحد، لا اختباران منفصلان
اختبار التطبيق والـ API معاً يكشف مشكلات الحدّ الفاصل التي لا يكشفها أيٌّ من الاختبارين وحده — قاعدة يفرضها التطبيق ولا يفرضها الخادم، أو رمز (token) يثق به الـ API أكثر ممّا ينبغي.
تركيز على التفويض
التفويض المعطوب على مستوى الكائن وعلى مستوى الوظيفة من أبرز مخاطر الـ API. نختبرها مباشرةً بحسابات منفصلة، لأنّ واجهة التطبيق تخفيها لكنّ الـ API لا يفعل.
تغطية قائمة على المعايير
يتّبع التطبيق OWASP MASVS وMASTG ويتّبع الـ API معيار OWASP API Security Top 10، فتكون التغطية على الجانبين صريحة وقابلة للتحقّق بدلاً من أن تكون ارتجالية.
نتائج قابلة للتنفيذ ومرتّبة بحسب الأولوية
إرشادات واضحة مرتّبة بحسب الخطر، وكلّ نتيجة موسومة بأنها على جانب التطبيق أو جانب الـ API أو التكامل، مع إثبات مفهوم قابل لإعادة الإنتاج وإصلاح ملموس.

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

ما التقييم المجمَّع للجوّال والـ API؟

يختبر تطبيق جوّال وواجهته الخلفية (API) بوصفهما نظاماً واحداً. يُختبر التطبيق بـ OWASP MASVS وMASTG، والـ API بـ OWASP API Security Top 10، ثمّ التدفّقات التي تعبر الحدّ بينهما — المصادقة والرموز (tokens) والفرض على جانب الخادم — مع إثبات كلّ نتيجة وتصنيفها.

لماذا نختبر التطبيق والـ API معاً لا منفصلين؟

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

ما BOLA ولماذا يهمّ؟

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

ما الوصول الذي تحتاجونه، وهل تقدّمون اختبار الصندوق الأبيض؟

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

هل يجري الاختبار على بيئة الإنتاج أم على بيئة staging؟

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

هل تغطّون GraphQL أيضاً أم واجهات REST فقط؟

نختبر الـ API الذي يستخدمه التطبيق فعلاً، سواء أكان REST أم GraphQL أم أسلوباً آخر. ومخاطر التفويض والمصادقة في API Security Top 10 تنطبق على جميع الأساليب؛ أمّا طريقة اختبارنا لها فتتكيّف مع الواجهة.

كيف تُحدَّد درجة خطورة النتائج؟

تحصل كلّ نتيجة على درجة CVSS كأساس مشترك، تُعدَّل بحسب الأثر الفعلي في نظامكم — ما الذي يبلغه المهاجم، وبأيّ سهولة، وأيّ بيانات أو حسابات في خطر. ولهذا قد تُرتَّب مشكلتان لهما الدرجة نفسها على CVSS بأولويتين مختلفتين.

هل تُجرى إعادة الاختبار بعد المعالجة؟

نعم — بعد معالجتكم، نعيد اختبار النتائج المُبلَّغة على كلٍّ من التطبيق والـ API للتأكّد من ثبات كلّ إصلاح. وتعتمد المدّة على حجم التطبيق وعدد نقاط نهاية الـ API، ونقدّم تقديراً محدّداً بعد تحديد النطاق.

ماذا لو كان تطبيقي يتحدّث إلى عدّة خدمات خلفية؟

نحدّد نقاط النهاية والخدمات الداخلة في التقييم مسبقاً. واختبار خدمات أكثر يزيد الجهد، لذا نتّفق على الحدود قبل أن نبدأ ونعكسها في التقدير — ولا يُختبر شيء خارج النطاق المتَّفق عليه.

هل أنتم مستعدون للبدء؟
تواصلوا مع فريقنا لمناقشة احتياجات تقييم الأمان لديكم