اختبار اختراق تطبيقات الجوال: ما يقيسه MASVS وما يتركه للخادم

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

المشتري في السوق العربية يواجه صعوبة إضافية: العروض المتاحة متشابهة في الشكل. كلها تَعِد بـ«اختبار اختراق شامل» وتُسلّم «تقريرًا بالثغرات»، والفرق الحقيقي بين عرض وآخر لا يظهر في العرض بل في ثلاثة أسئلة: ما النطاق المكتوب، وما الدليل الذي سيُنتج لكل بند، وهل يشمل السعر إعادة اختبار بعد الإصلاح. من لا يجيب عن هذه الثلاثة قبل التوقيع يشتري وثيقة، لا اختبارًا.

هذا الدليل مكتوب لصاحب القرار التقني لا للمختبِر: كيف تحوّل «اختبار تطبيق» إلى نطاق قابل للقياس، وما الذي يغطيه معيار MASVS وما يتركه خارج الباب، وأين تظهر الأخطاء فعليًا في أندرويد وiOS، وما الذي تفرضه متاجر التطبيقات والجهات التنظيمية الخليجية على النطاق نفسه. ونعمل في كل ما نصفه بتفويض كتابي من مالك التطبيق، على بيئات اختبار أو نسخ مخصصة، وبلا أي مساس ببيانات مستخدمين حقيقيين.

العميل بيد المهاجم: الفرق الذي يغيّر طريقة القياس

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

الفرق الأول أن أي قرار أمني يُتخذ داخل التطبيق قابل للتلاعب. «إخفاء زر» ليس صلاحية. «تعطيل النسخ» ليس منعًا. «التحقق من أن الجهاز غير معدَّل» ليس حاجزًا، بل عقبة تُكلّف المهاجم وقتًا. إذا كانت مصلحة المهاجم تستحق ساعة عمل، فسيتجاوزها. القاعدة العملية: كل ما لا يُقرَّر على الخادم يُعاد اعتباره اختياريًا في النموذج.

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

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

لذلك السؤال الأول في أي اختبار جوال ليس «هل التطبيق آمن؟» بل «أي طبقة نختبر الآن؟». الاختبار الذي لا يفصل بين التطبيق والخادم والحزمة سيخلط الثلاثة في تقرير واحد، وينتهي بك إلى إصلاحات في المكان الخطأ.

MASVS: عقد نطاق بدل قائمة ثغرات

معيار التحقق من أمن التطبيقات الجوّالة (OWASP MASVS) هو الوسيلة الأكثر شيوعًا لتحويل «اختبار» إلى نطاق. الإصدار الحالي هو 2.1.0 الصادر في يناير 2024، وقد أضاف فئة الخصوصية MASVS-PRIVACY إلى بنية الإصدار 2.0.0 التي أعادت تنظيم المعيار في ثماني مجموعات بدل القائمة المسطّحة القديمة. المعيار لا يصف كيف تُختبر الثغرة، بل يحدد ما يجب أن يكون صحيحًا؛ أما كيف تُختبر فتأتي من دليل الاختبار MASTG، الذي أُعيد بناؤه في الإصدار 2.0.0 الصادر في يونيو 2026 إلى مكوّنات مستقلة مرقّمة يمكن ربط كل بند فيها بضعف محدد MASWE وباختبار وبأداة.

هذا الفصل بين «ما» و«كيف» هو ما يجعله صالحًا للتعاقد. تكتب في العرض: تغطية كاملة لمجموعات MASVS الثماني عند مستوى L1 لمدة كذا، وتغطية L2 للمصادقة والشبكة والتخزين، ومجموعة المتانة R إن كان التطبيق ماليًا. فيصبح لديك عدد بنود معروف مسبقًا، وتقرير يُقاس عليه، لا وصف تسويقي.

لكل ضابط في قوائم التحقق أربعة أعمدة: L1 وL2 وR وP. المستوى L1 هو الحد الأدنى الذي يجب أن يتحقق في أي تطبيق يتعامل مع بيانات، وL2 يضيف ضوابط الدفاع في العمق للأصول الحساسة: تطبيقات مصرفية، محافظ، رعاية صحية، هوية. العمود R يخص المتانة ضد الهندسة العكسية والعبث، والعمود P يخص الخصوصية: ما تجمعه، ولماذا، وهل يخرج إلى طرف ثالث. الخلط الشائع أن يُقال «نحن متوافقون مع MASVS» بلا ذكر المستوى والأعمدة، وهذا يعني عمليًا لا شيء.

انظر إلى المجموعة الأخيرة تحديدًا. قبل الإصدار 2.1.0 كانت الخصوصية موزّعة ضمنا على بنود أخرى، واليوم صارت مجموعة مستقلة، وهذا يعكس تغيّرًا في السوق لا في المعيار فقط: متاجر التطبيقات بدأت تطلب إفصاحًا عن البيانات، والجهات التنظيمية بدأت تطلب أساسًا قانونيًا للجمع، وصار من الممكن أن يكون التطبيق «آمنًا» و«غير نظامي» في الوقت نفسه. اختبار لا يقرأ هذا العمود سيكتشف ثغرة واحدة ويترك تعرّضًا تنظيميًا كاملًا.

ما لا يغطيه MASVS: حدود تُكتب في العقد

أول حد هو الخادم. MASVS معيار للعميل، وواجهة برمجية بها خلل صلاحيات لا تظهر في أي بند من بنودها. أثقل ما نقيسه في معظم تقييمات الجوال لا يخص التطبيق: نقطة نهاية تقبل رقم مستخدم آخر، أو دالة إدارية بلا تحقق دور، أو مسار يُرجع ملفًا بمجرد تخمين معرّف. هذه تخص OWASP ASVS، وتغطيتها تحتاج نطاقًا منفصلًا صريحًا، وإلا حصلت على تقرير نظيف لتطبيق يمكن قراءة بيانات كل مستخدميه عبره.

الحد الثاني هو سلسلة التوريد. التطبيق الحديث ثلثاه مكتبات: SDK تحليلات، SDK إعلانات، SDK دفع، SDK دعم فني. جزء من هذه المكتبات يعمل خارج سيطرتك ويجمع بياناته بمعاييرها. MASVS-CODE وMASVS-PRIVACY يلمسان هذا الطرف، لكن الحكم الكامل يحتاج جردًا لمكوّنات الحزمة ومراجعة ما تفعله، وهو عمل يخرج عن جولة اختبار الاختراق المعيارية ويُكتب بندًا مستقلًا.

الحد الثالث هو البنية والتشغيل: تهيئة CDN، وسياسات الخادم، وإدارة الأسرار، وسجلات المراقبة، واستجابة الحادث. ولا يغطي المعيار أيضًا سياسة المتجر نفسها: ما تسمح به Play وتطلبه Apple ليس بند أمني في MASVS، لكنه قد يمنع إصدارك أو يكشف تعرّضًا لا علاقة له بالكود.

الحد الرابع هو الأجهزة المُدارة. إن كان التطبيق يعمل داخل مؤسسة، فإن MDM وسياسة الأجهزة وسياسة الاستخدام المقبول هي ما يحدّد قابلية الاستغلال الفعلية. تقرير يقول «الثغرة عالية الخطورة» دون أن يذكر أن الأجهزة مُدارة ومقيّدة سيضخّم الخطورة أو يقللها بلا سبب.

الخلاصة العملية: MASVS عقد ممتاز للطبقة التي يغطيها، وما يحتاجه المشتري هو سطران في العقد يقولان صراحة ما هو خارج النطاق. الاختبار الذي لا يعلن حدوده سيملأ الفراغ بثغرات منخفضة الخطورة ويترك الباب الذي يدخل منه المهاجم.

أندرويد: الحافة تُقرأ من ملف واحد قبل أي أداة

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

لاحظ أن ثلاثة من هذه البنود لا تظهر في أي فحص آلي تجاري بأنها «ثغرة»، لأنها إعدادات مشروعة. المشكلة أنها مشروعة في سياق ومكلفة في سياق آخر: تطبيق محفظة يترك allowBackup مفتوحًا يسلّم ملفاته كاملة إلى خدمة نسخ احتياطي خارجية، وتطبيق دردشة يترك pendingintent قابلًا للتعديل يفتح ثغرة تصعيد داخل التطبيق نفسه. الحكم هنا يحتاج سياق التطبيق لا مجرد وجود السطر.

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

iOS: أربعة أطراف لا تُرى من الواجهة

الطرف الأول هو نقل الشبكة. إعداد ATS الافتراضي يفرض TLS 1.2 على الأقل مع سرية تامة أمامية، وأي استثناء يُكتب صراحة في Info.plist. مفتاح NSAllowsArbitraryLoads يعطّل الحماية عالميًا، وتوابعه مثل السماح للمحتوى داخل WebView تُستخدم كثيرًا لتسهيل تكامل قديم وتُنسى. هذه الاستثناءات ليست ثغرة بذاتها، لكنها تُلغي الطبقة التي تعتمد عليها بقية الضوابط، ومراجع المتجر صارت تسأل عن مبررها.

الطرف الثاني هو الروابط. المخطط المخصص CFBundleURLTypes يمكن لأي تطبيق آخر تسجيله، فإذا كان المخطط يحمل رمز تحقق أو رمز استعادة كلمة مرور، فالتطبيق المزيف يستلمه. البديل الصحيح هو الروابط الشاملة Universal Links، لأن النظام يتحقق من ملكية النطاق عبر ملف يُستضاف على الخادم ويربطه بالتوقيع، ولا يستطيع تطبيق آخر ادّعاءه. الفرق بين الاثنين هو الفرق بين بوابة بهوية وبوابة باسم.

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

الطرف الرابع هو حماية الملفات والمصادقة الحيوية. كل ملف يكتبه تطبيقك له فئة حماية: NSFileProtectionComplete، أو CompleteUnlessOpen، أو CompleteUntilFirstUserAuthentication وهو الافتراضي، أو None. الفئة الافتراضية تعني أن الملف يُقرأ بعد أول فتح للجهاز ولو كان مقفلًا، وهي غير كافية لبيانات صحية أو مالية. وفي المصادقة، الفرق بين سياسة deviceOwnerAuthenticationWithBiometrics وسياسة deviceOwnerAuthentication هو الفرق بين «بصمة فقط» و«بصمة أو رمز»، وأي مسار بديل داخل التطبيق نفسه يجب أن يمر بالخادم لا بالمنطق المحلي.

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

التحليل الديناميكي: ما لا يظهر إلا تحت التشغيل

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

أهم ما ينتج عن هذه الجولة ثلاثة أنواع من النتائج. النوع الأول أسرار وحقول تظهر في السجلات أو في الملفات المؤقتة: رمز جلسة، بريد، رقم هوية، صورة بطاقة. النوع الثاني قرارات محلية تُتخذ في الجهاز ويمكن قلبها: «المستخدم مسؤول» في متغيّر محلي، أو «تم التحقق» في مخزن تفضيلات. النوع الثالث سلوك غير موثّق: طلب إلى نطاق لم يظهر في التحليل الثابت، أو إرسال بيانات إلى SDK ثالث عند أول تشغيل.

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

تثبيت الشهادة: ما يحمي وما يوهم

تثبيت الشهادة (Certificate Pinning) يمنع اعتراض الحركة بشهادة مزيفة، وهو مطلوب في تطبيقات مالية ومعرفية. لكنه في كل جولة اختبار هو أول ما يُتجاوَز: إما بأداة اعتراض داخل العملية، أو بإعادة تجميع الحزمة بعد تعطيل منطق التحقق، أو بحقن مكتبة تُرجع نجاحًا دائمًا. لذلك لا يجوز أن يُقدَّم للمشتري كحدّ أمني، بل كتكلفة إضافية على المهاجم.

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

ومن الأخطاء المتكررة أن يُثبَّت مفتاح واحد فقط بلا مسار احتياطي للتجديد، فتنتهي صلاحية الشهادة ويتعطّل التطبيق لكل المستخدمين في يوم واحد. الاختبار الجيد يفحص الحالتين: هل يمكن تجاوز التثبيت؟ وهل يوجد مسار تدوير آمن عند انتهاء الشهادة؟

المصادقة والجلسة: حيث تفقد التطبيقات حساباتها

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

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

البند الثالث هو التعداد: هل تختلف الاستجابة بين بريد مسجّل وبريد غير مسجّل، أو يختلف زمن الاستجابة بدرجة كافية للاستنتاج؟ وهل تسمح نقطة إعادة تعيين كلمة المرور بمعرفة الحسابات القائمة؟ هذه الفروق الصغيرة تُبنى عليها حملات تصيّد مقنعة، وهي من أكثر النتائج التي نجدها في تطبيقات المنطقة لأنها لا تظهر في أي فحص آلي.

الخادم: الطبقة التي تُدفع فيها الفاتورة

إذا كان عليك أن تختار طبقة واحدة تُختبر بعمق، فاختر الخادم. في كل تقييم جوال تقريبًا تكون أخطر نتيجة في واجهة برمجية لا في التطبيق: نقطة تقبل معرّف كائن يخص مستخدمًا آخر، أو وظيفة إدارية لا تتحقق من الدور، أو مسار يُرجع مستندًا لمن يعرف رابطه. هذه الأخطاء لا تحتاج جهازًا مُجذَّرًا ولا أدوات؛ تحتاج قراءة عقد الواجهة وتحويله إلى طلبات.

ما نطلبه في النطاق هنا صريح: جرد نقاط النهاية المستخدمة من التطبيق، واختبار الصلاحيات على مستوى الكائن والوظيفة، وحدود المعدل على نقاط المصادقة والدفع، ومنطق التحقق من الأسعار والمبالغ لأن كثيرًا من التطبيقات تثق بمبلغ يُرسله العميل. وإن كان التطبيق يتبادل رموزًا عبر روابط عميقة أو WebView، فهذا مسار ثالث يجب أن يُختبر بانفصال عن التطبيق نفسه.

الطبقة الأخيرة في هذا الباب هي المتانة. كشف الجذر والتصحيح، والتحقق من سلامة الحزمة، واستدعاء خدمة تحقق مثل Play Integrity أو App Attest، كلها إشارات لا حواجز. فائدتها أن تجعل إعادة التوزيع المعدَّل مكلفًا وأن تمنح خادمك سببًا لرفض طلب مشبوه. أما تقديمها على أنها «حماية من الهندسة العكسية» فهو وعد لا يتحقق، وسيخبرك بذلك أي مختبر يفتح الحزمة أمامك في دقائق.

الامتثال الخليجي: أين يتحول الاختبار إلى مطلب

في السعودية والإمارات لم يبقَ اختبار التطبيق ممارسة اختيارية. الضوابط السيبرانية الأساسية السعودية ECC-2:2024 خصّصت الضابط 2-6 لأمن الأجهزة المحمولة، والضابط 2-11 لاختبار الاختراق، وأفردت 2-15 لتأمين تطبيقات الويب — أي أن التطبيق الجوال والموقع ليسا بندًا واحدًا في الإطار التنظيمي، بل مساران. وتُضاف إليها ضوابط الأنظمة الحيوية التي ترفع وتيرة الاختبار، وضوابط السحابة التي تُلزم مزوّد الخدمة بتغطية إضافية في البندين نفسيهما.

في القطاع المالي، إطار الأمن السيبراني لمؤسسة النقد العربي السعودي (SAMA) يضع أمن التطبيقات في 3.3.6 ويشترط تنظيم استخدام تطبيقات الجوال المؤسسية أو المعتمدة للجمهور، ويخصّص 3.3.13 لخدمات الصرافة الإلكترونية بما يشمله من ضوابط العزل وعدم الاحتفاظ ببيانات حساسة في الجهاز وتقييد النشر في المتاجر الرسمية، مع اشتراط موافقة المؤسسة قبل إطلاق خدمة مصرفية إلكترونية جديدة. أي أن دورة الاختبار عندك صارت مرتبطة بتاريخ الإطلاق لا برغبة الفريق.

في الإمارات، لائحة ضمان المعلومات الصادرة عن هيئة تنظيم الاتصالات والحكومة الرقمية تخصّص البند T5.7 للتحكم في الوصول عبر الأجهزة المحمولة، وهي مُلزمة للجهات المصنَّفة ضمن البنية التحتية المعلوماتية الحيوية؛ أما الجهات الأخرى فتحكمها سياساتها القطاعية، ويبقى القانون الاتحادي 45 لسنة 2021 لحماية البيانات الشخصية هو الإطار العام للجمع والإفصاح.

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

حوكمة المتاجر: مطلب إصدار لا بند أمني

الطرف الذي يفرض تغييرات أسرع من أي جهة تنظيمية هو المتجر. منذ 31 أغسطس 2026 صارت التطبيقات الجديدة والتحديثات على Google Play مطالَبة باستهداف Android 16 (مستوى API 36)، وبقاء التطبيق القديم متاحًا لمستخدمين جدد عند مستوى 35 على الأقل، مع مهلة استثناء تنتهي في 1 نوفمبر 2026. ومنذ 1 نوفمبر 2025 صار دعم صفحات الذاكرة بحجم 16 كيلوبايت مطلوبًا للتطبيقات التي تستهدف Android 15 وما فوق ولديها كود أصلي، وهو بند يظهر أثره في المكتبات المترجمة لا في كودك.

على الجانب الآخر، تشترط آبل بيان الخصوصية PrivacyInfo.xcprivacy للتطبيقات والتحديثات التي تستخدم واجهات ذات سبب مطلوب، وتشترط توقيع المكتبات الشائعة، وتُلزم منذ 2022 بأن يتيح أي تطبيق يسمح بإنشاء حساب حذفه من داخل التطبيق. هذه البنود لا تُذكر في تقرير اختبار الاختراق عادةً، لكنها في الممارسة تُنتج تعرّضًا حقيقيًا: تطبيق يحتفظ ببيانات بعد طلب الحذف، أو يجمع معرّفًا لأغراض غير مصرَّح بها، أو يرسل إلى SDK ما لم يُفصح عنه.

لهذا نقترح دائمًا أن يكون في النطاق بند رابع اسمه «مطابقة الإفصاح بالسلوك». يقرأ فيه المختبر ما يقوله المتجر عن البيانات ويقارنه بما يرسله التطبيق فعلًا في التحليل الديناميكي. الفرق بينهما هو أكثر ما يورط الشركات في شكاوى الخصوصية، وهو رخيص القياس ولا يحتاج أدوات إضافية.

حساب الجهد: كم يومًا يستغرق الاختبار فعلًا

السؤال الذي يُطرح في كل اجتماع تسعير: لماذا لا يكون الاختبار يومًا واحدًا؟ الجواب في تفكيك النطاق. منصة واحدة على مستوى L1 كامل مع تغطية L2 لثلاث مجموعات حساسة تستهلك عادة من ستة إلى ثمانية أيام مهندس: يومان للتحليل الثابت وقراءة الحزمة والمكتبات، ويومان للتحليل الديناميكي على جهازين، ويوم للمصادقة والجلسة، ويوم للشبكة والتخزين، ويوم للتقرير وإعادة الإنتاج. المنصتان ترفعان الرقم إلى عشرة أو أربعة عشر يومًا لأن الشيفرة ومسارات الإدخال تختلف، وليس لأن الجهاز مختلف فقط.

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

هذه الأرقام ليست سعرًا، بل وحدة قياس للمفاوضة. عرض يقول «اختبار تطبيق كامل» بسعر يعادل ثلاثة أيام لا يمكن أن يغطي L1 كاملًا على منصتين، ومن يقبله سيحصل على فحص آلي وشاشتين. والأسلم أن تسأل عن عدد أيام المهندس المخصصة، وعن توزيعها على المجموعات، قبل أن تسأل عن السعر.

التقرير: ما يجب أن تراه قبل أن تدفع

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

احذر من مؤشرين في أي تقرير: عدد الثغرات بلا سياق، وقائمة مليئة بنتائج «معلوماتية» تُضخّم العدد. الأول يخفي أن أخطر نتيجة قد تكون واحدة، والثاني يجعل من الصعب معرفة ما يجب إصلاحه أولًا. اسأل بدلًا منهما: ما الثلاث نتائج التي لو أُصلحت لاختلف تقييمك للتطبيق؟ إن لم يكن للمختبر جواب واضح، فالتقرير لم يُكتب لك.

إعادة الاختبار: الفرق بين وثيقة وإصلاح

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

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

كيف تميّز مختبرًا من وسيط

ثمانية أسئلة تكفي في مكالمة واحدة. ما النسخة من MASVS التي تعملون عليها وأي أعمدة تغطون؟ هل الجهاز مُجذَّر أو مكسور الحماية أم محاكٍ؟ هل تختبرون المنصتين بكودين مختلفين أم تعيدون استخدام نفس المنهجية؟ هل الخادم داخل النطاق وما حدوده؟ كيف توثّقون النتيجة بخطوات إعادة إنتاج؟ هل التقرير يحتوي مصفوفة تغطية؟ هل إعادة الاختبار مشمولة وكم نتيجة؟ ومن يوقّع التقرير، وما خبرته العملية على المنصة المحددة؟

المختبر الحقيقي يجيب بسرعة وبأرقام. الوسيط يجيب بعبارات عامة، ويُخفي أن جزءًا من العمل يُنفَّذ آليًا، أو أن الخادم خارج النطاق لمجرد أن السعر لا يحتمله. والسؤال الذي يفضح الفرق أسرع من غيره: «أروني مقتطفًا من تقرير سابق بلا أسماء». من يملك منهجية سيعرض مقتطفًا منزوع الهوية في دقائق.

الحد القانوني: ما يجعل الاختبار مباحًا

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

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

قائمة القرار في عشرة بنود

• اكتب النطاق في سطرين: المنصات، والمستوى (L1/L2)، والأعمدة (R/P)، والنسخة المراد اختبارها.
• أعلن ما هو خارج النطاق صراحة: الخادم، وسلسلة التوريد، والبنية التحتية، وسياسة المتجر.
• اقرأ ملف البيان قبل التعاقد: المكوّنات المصدَّرة، والنسخ الاحتياطي، وقواعد الشبكة، ومهمة النافذة.
• اختبر المصادقة كأولوية أولى: عمر الرمز، وتدويره، وإبطاله، وحدود التحقق متعدد العوامل.
• اجعل الخادم داخل النطاق أو اعترف كتابيًا بأن التقييم جزئي.
• افحص ما يُكتب على الجهاز بعد كل شاشة، لا الملفات الموجودة فقط.
• اطلب مصفوفة تغطية MASVS مع التقرير بدل قائمة ثغرات مرقّمة.
• اشترط إعادة اختبار مكتوبة للنتائج الحرجة والعالية.
• راجع الإفصاح في المتجر مقابل السلوك الفعلي، وحدّث بيان الخصوصية قبل الإصدار.
• احفظ التفويض المكتوب مع التقرير؛ فهو ما يجعل العمل صالحًا أمام أي مراجعة.

الخلاصة التي نراها في كل تقييم تقريبًا: التطبيق ليس المكان الذي يُحسم فيه الأمان. المكان هو الخادم، والقرارات المتخذة في التصميم قبل كتابة أول سطر. اختبار الجوال الجيد لا يجعل التطبيق آمنًا، بل يجعل المخاطر معروفة ومرتّبة وقابلة للإصلاح، وهذا كل ما يمكن أن يشتريه أحد بمال. وإن كنت تقارن عروضًا الآن، فابدأ بالنطاق لا بالسعر؛ فالنطاق هو الشيء الوحيد الذي لا يمكن أن يكون مجانيًا. لمعرفة كيف يبدو هذا عمليًا في تقييم كامل، راجع خدمة اختبار الاختراق، وللجانب الأكثر خطورة في المعادلة راجع اختبار أمن واجهات البرمجة، وللإطار القانوني للبيانات المادة 32 وتدابير أمن المعالجة.