أمان واختبار تطبيقات الموبايل: قائمة تدقيق قبل الإطلاق تحميك من الأعطال والاختراق

بقلم محمد صقر · 2 نوفمبر 2026 · تطبيقات الموبايل · قراءة نحو 6 دقيقة

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

هذا الدليل يعطيك إطارًا عمليًا للاختبار وقائمة أمان مرجعها OWASP Mobile Top 10 (أبرز مخاطر تطبيقات الموبايل).

الجزء الأول: الاختبار

خريطة أنواع الاختبار

1) اختبارات آلية للمنطق الحرج

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

// مثال: حساب إجمالي الطلب
test('الإجمالي = المجموع - الخصم + الشحن', () => {
  const total = calcTotal({ items: [{ price: 100, qty: 2 }], discount: 20, shipping: 15 });
  expect(total).toBe(195);
});

2) اختبار على أجهزة حقيقية متنوعة

• أندرويد: شركات متعددة (سامسونج وشاومي وأوبو...) وأحجام شاشات وإصدارات نظام، وجهاز قديم ضعيف وآخر حديث.
• iOS: آيفون بأحجام مختلفة وإصدارين على الأقل من النظام.
• أجهزة لوحية إن كان التطبيق يدعمها.
• لا تكتفِ بالمحاكي (Emulator)؛ الأجهزة الفعلية تكشف مشاكل الأداء واللمس والكاميرا والإشعارات. ويمكن استخدام خدمات سحابية لتشغيل التطبيق على أجهزة كثيرة.

3) ظروف الشبكة الواقعية

اختبر: شبكة ضعيفة، انقطاع في منتصف العملية، تبديل بين واي فاي وبيانات، وضع الطيران. وتأكد أن التطبيق يعرض رسالة مفهومة ويستأنف بلا فقد بيانات ولا تكرار طلبات (كطلب دفع مرتين).

4) حالات الحافة والمستخدم غير المثالي

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

5) الأداء

• زمن بدء التشغيل والانتقال بين الشاشات.
• سلاسة التمرير (إطارات في الثانية).
• استهلاك الذاكرة والبطارية والبيانات.
• حجم التطبيق.
• أدوات المنصات: Profiler في Android Studio وInstruments في Xcode.

6) اختبار تجريبي مع مستخدمين (Beta)

قبل الإطلاق العام وزّع نسخة تجريبية على مستخدمين حقيقيين: TestFlight لـiOS ومسارات الاختبار في Play Console لأندرويد. اجمع الأعطال والملاحظات، وراقب أين يتعثرون. وراجع النشر على App Store وGoogle Play لإعداد القنوات.

الجزء الثاني: الأمان

مبدأ أساسي: لا تثق بالعميل

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

1) تخزين البيانات على الجهاز

• لا تخزن كلمات المرور على الجهاز. خزّن رمز وصول بصلاحية قصيرة.
• استخدم التخزين الآمن للنظام: Keychain في iOS وKeystore مع EncryptedSharedPreferences في أندرويد. لا تضع الرموز في SharedPreferences أو UserDefaults العادية أو ملفات نصية.
• قلل ما تخزنه: لا تحفظ ما لا تحتاجه، وأزل البيانات عند تسجيل الخروج.
• امنع لقطات الشاشة للشاشات الحساسة إن لزم، وتأكد من عدم تسجيل بيانات حساسة في السجلات (Logs).
• تشفير قواعد البيانات المحلية إن كانت تحمل بيانات شخصية.

2) الاتصال الآمن بالخادم

• HTTPS فقط مع TLS حديث، وامنع الاتصال النصي (Cleartext). تحقق من صحة الشهادات ولا تعطّل التحقق أبدًا حتى «مؤقتًا للتجربة».
• تثبيت الشهادة (Certificate Pinning) للتطبيقات الحساسة (مالية وصحية) مع خطة لتدوير الشهادات حتى لا ينكسر التطبيق.
• أمان واجهات API: مصادقة وتفويض وتحقق من المدخلات وتحديد المعدل على الخادم (شرح REST API).

3) المصادقة والجلسات

• رموز وصول قصيرة العمر مع رموز تجديد (Refresh Tokens) وإمكان إبطالها.
• المصادقة الحيوية (بصمة/وجه) عبر واجهات النظام لا بحلول مخصصة.
• المصادقة الثنائية للعمليات الحساسة.
• حدّ محاولات الدخول وإشعار المستخدم بالدخول من جهاز جديد.
• تحقق من الصلاحيات في الخادم لكل طلب: لا تثق بأن الواجهة أخفت الزر.

4) حماية الكود والأسرار

• لا مفاتيح سرية داخل التطبيق: أي مفتاح يتضمنه الملف يمكن استخراجه. استخدم الخادم وسيطًا للمفاتيح الحساسة، وقيّد المفاتيح العامة (مثل مفاتيح الخرائط) بحزمة التطبيق.
• تشويش الكود (Obfuscation) مثل R8/ProGuard في أندرويد يصعّب الهندسة العكسية لكنه ليس حماية كاملة.
• اكتشاف أجهزة الروت/الجيلبريك والمحاكيات للتطبيقات شديدة الحساسية، مع تقدير أن ذلك يُتجاوز.
• التوقيع الآمن وحماية مفاتيح التوقيع وحسابات المتاجر بمصادقة ثنائية.

5) المكتبات والاعتماديات

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

6) الإذونات والخصوصية

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

7) المدفوعات

لا تعالج بيانات البطاقات بنفسك؛ استخدم بوابة دفع معتمدة أو واجهات الدفع الرسمية في المنصتين. وتحقق من نجاح الدفع من الخادم عبر إشعار البوابة، لا من رد التطبيق فقط.

قائمة OWASP Mobile: المخاطر الأشهر باختصار

القائمة (OWASP Mobile Top 10) تلخص أكثر المخاطر شيوعًا، وتشمل: الاستخدام الخاطئ لصلاحيات المنصة، وتخزين بيانات غير آمن، واتصال غير آمن، ومصادقة وتفويض ضعيفان، وتشفير غير كافٍ، وضعف جودة الكود، والعبث بالتطبيق، والهندسة العكسية، وميزات مخفية أو متروكة للتجربة. استخدمها قائمة تدقيق عند المراجعة.

الجزء الثالث: المراقبة بعد الإطلاق

الاختبار لا ينتهي بالنشر:

• تتبع الأعطال (Crashlytics وSentry وأمثالهما) لتعرف ما ينهار عند من وأين.
• مراقبة الأداء وأزمنة الاستجابة من التطبيق والخادم.
• التحليلات لسلوك المستخدمين وأين ينسحبون (GA4 أو Firebase).
• مراجعات المتجر كمصدر لأخطاء لم تكتشفها.
• إصدارات تدريجية (Staged Rollout): طرح الإصدار لنسبة من المستخدمين ثم زيادتها، لتوقف الانتشار إن ظهر عطل.
• خطة استجابة لحوادث الأمان: من يُبلغ؟ كيف تُصلح وتُحدّث وتُبلغ المستخدمين؟
• تحديثات دورية للتوافق مع أنظمة جديدة وإصلاح الثغرات. وتشبه فكرة الصيانة ما شرحناه للمواقع في صيانة المواقع.

قائمة تدقيق قبل الإطلاق

• اختبارات المنطق الحرج ناجحة آليًا.
• اختبار على 5 أجهزة حقيقية على الأقل بمستويات مختلفة.
• اختبار شبكة ضعيفة وانقطاع.
• لا مفاتيح سرية ولا بيانات حساسة في الكود أو السجلات.
• التخزين الآمن للرموز وHTTPS فقط.
• التحقق من الصلاحيات والمدخلات في الخادم.
• مكتبات محدثة وبلا ثغرات معروفة.
• بيانات الخصوصية وسياسة الخصوصية دقيقة.
• أداة تتبع أعطال وتحليلات مفعلة.
• نسخة تجريبية مع مستخدمين حقيقيين.
• خطة إصدار تدريجي وخطة رجوع.

وللتعامل الأمني مع الموقع المصاحب للتطبيق راجع قائمة أمان المواقع. وفي خدمة برمجة التطبيقات نضمّن الاختبار والمراجعة الأمنية ضمن التسليم.

أخطاء شائعة

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

أسئلة شائعة

أسئلة شائعة

اقرأ أيضاً

مصادر موثوقة للاستزادة

• OWASP Mobile Top 10
• OWASP Top 10
• Firebase
• Android Developers