معظم الاختراقات في تطبيقات الجوال لا تحدث في التطبيق نفسه بل في الـAPI خلفه. السبب بسيط: كثير من المطورين يعاملون التطبيق كخط دفاع، بينما التطبيق بيئة غير موثوقة بالكامل.
القاعدة الحاكمة: كل ما يصل من العميل غير موثوق — حتى لو أرسله تطبيقك أنت.
للمرجع المعياري في هذا المجال، راجع قائمة OWASP لأخطر عشر مخاطر في واجهات API — وهي المرجع الأوسع اعتماداً لدى فرق الأمن.
لماذا التطبيق ليس خط دفاع؟
أي شخص يستطيع فحص حركة تطبيقك ورؤية كل طلب يرسله وكل استجابة يتلقاها. الأدوات لذلك متاحة ومجانية.
ما يعنيه هذا:
- إخفاء زر في الواجهة ليس تفويضاً. المهاجم يستدعي الـAPI مباشرة.
- التحقق في التطبيق ليس تحققاً. كرّره في الخادم دائماً.
- أي مفتاح داخل التطبيق مكشوف. لا تضع أسراراً في كود العميل.
1. المصادقة والتفويض — الفرق الحاسم
خلط هذين المفهومين مصدر أخطر الثغرات.
المصادقة (Authentication): من أنت؟ التفويض (Authorization): هل يحق لك هذا تحديداً؟
الثغرة الأشيع في التطبيقات: التحقق من أن المستخدم مسجّل دخول، دون التحقق من أن هذا السجل يخصه.
GET /api/orders/12345
إن كان الخادم يتحقق فقط من صحة الرمز (token) ويعيد الطلب رقم 12345 لأي مستخدم مسجّل — فأي مستخدم يستطيع قراءة طلبات الجميع بتغيير الرقم.
القاعدة: تحقق دائماً أن المورد المطلوب يخص المستخدم صاحب الطلب — في كل نقطة نهاية بلا استثناء.
2. الرموز (Tokens) — إدارة صحيحة
لا تخزّن الرموز في تخزين عادي غير آمن. استخدم التخزين الآمن الذي يوفّره النظام (Keychain على iOS، Keystore على Android).
استخدم رمزين:
- رمز وصول قصير العمر — دقائق إلى ساعة.
- رمز تجديد أطول عمراً — يُستخدم لإصدار رمز وصول جديد.
لماذا؟ الرمز القصير يقلّل نافذة الضرر إن تسرّب.
وفّر آلية إبطال. إن سُرق جهاز أو اشتُبه في اختراق، يجب أن تستطيع إبطال جلسة محددة أو كل جلسات مستخدم.
3. الأخطاء الأشيع في تطبيقات الجوال
1. مفاتيح مدفونة في التطبيق. أي مفتاح داخل حزمة التطبيق قابل للاستخراج. المفاتيح الحساسة تبقى في الخادم، والتطبيق يستدعي خادمك لا الخدمة الخارجية مباشرة.
2. الاعتماد على التحقق في الواجهة. التحقق في العميل لتجربة المستخدم فقط؛ التحقق الحقيقي في الخادم دائماً.
3. إعادة بيانات أكثر من اللازم. نقطة نهاية تعيد كائن المستخدم كاملاً — بالبريد والهاتف والدور — لعرض الاسم فقط. أعد ما يُعرض.
4. رسائل خطأ كاشفة. «كلمة المرور خاطئة» تؤكد أن البريد مسجّل. استخدم «بيانات الدخول غير صحيحة» موحّدة.
5. غياب تحديد المعدل (Rate Limiting). بلا حد، نقطة تسجيل الدخول قابلة للتخمين الآلي، ونقطة إرسال الرمز قابلة للإساءة.
6. معرّفات متسلسلة قابلة للتخمين. /orders/1, /orders/2 تدعو للاستكشاف. استخدم معرّفات غير قابلة للتخمين للموارد الحساسة — مع بقاء فحص الملكية إلزامياً.
7. تسجيل بيانات حساسة. السجلات تحتوي أحياناً كلمات مرور أو رموزاً أو بيانات شخصية. راجع ما تسجّله — والسجلات تخضع لأنظمة حماية البيانات أيضاً. راجع دليل الامتثال لنظام حماية البيانات.
4. التحقق من المدخلات
تحقّق في الخادم من كل حقل — النوع، الطول، النطاق، الصيغة.
لا تثق بحقول مخفية. إن أرسل التطبيق price مع الطلب، فالمهاجم يرسل price: 0. احسب السعر في الخادم من معرّف المنتج.
استخدم استعلامات معاملية (Parameterized) لمنع الحقن — لا تبنِ استعلامات بدمج نصي أبداً.
افحص الملفات المرفوعة: النوع الفعلي لا الامتداد، والحجم الأقصى، ولا تنفّذها أبداً من مسار قابل للوصول العام.
5. النقل والتخزين
HTTPS إلزامي لكل اتصال بلا استثناء.
شفّر البيانات الحساسة في قاعدة البيانات — لا تعتمد على تشفير القرص وحده.
كلمات المرور تُخزَّن مُجزّأة بخوارزمية مصممة لذلك (مثل bcrypt أو Argon2) — لا مشفّرة ولا مُجزّأة بخوارزميات سريعة.
افصل بيئات الإنتاج والاختبار تماماً — ولا تستخدم بيانات إنتاج حقيقية في التطوير، فهذه مخالفة صريحة لنظام حماية البيانات.
6. تحديد المعدل والمراقبة
حدّد معدل الطلبات على نقاط النهاية الحساسة: تسجيل الدخول، إعادة تعيين كلمة المرور، إرسال الرموز، والبحث.
راقب ما يشير للإساءة:
- محاولات دخول فاشلة متكررة من مصدر واحد.
- طلبات لموارد لا تخص المستخدم (محاولات تخمين).
- ارتفاع مفاجئ في معدل الطلبات.
المراقبة ليست ترفاً — نظام حماية البيانات السعودي يشترط إشعار الخرق خلال 72 ساعة، ولا يمكنك الإشعار عن خرق لا تكتشفه.
قائمة تحقق قبل الإطلاق
- كل نقطة نهاية تتحقق من الملكية لا من تسجيل الدخول فقط.
- الرموز في التخزين الآمن للنظام.
- رمز وصول قصير + رمز تجديد، مع آلية إبطال.
- لا مفاتيح حساسة داخل حزمة التطبيق.
- تحقق كامل من المدخلات في الخادم.
- الأسعار والحسابات الحساسة تُحسب في الخادم لا تُستقبل من العميل.
- استعلامات معاملية في كل مكان.
- HTTPS إلزامي.
- كلمات المرور مُجزّأة بخوارزمية مناسبة.
- تحديد معدل على نقاط النهاية الحساسة.
- رسائل خطأ لا تكشف معلومات.
- الاستجابات لا تعيد حقولاً غير مستخدمة.
- السجلات خالية من بيانات حساسة.
- مراقبة تكشف الأنماط المشبوهة.
- بيئات التطوير لا تحوي بيانات إنتاج.
اقرأ أيضاً
- الامتثال لنظام حماية البيانات — الجانب النظامي لحماية البيانات.
- التقنية المالية وساما — متطلبات أمنية أشد في القطاع المالي.
- اختبار تطبيقات الجوال — اختبار الحالات الحدّية يكشف ثغرات.
الأسئلة الشائعة
ما أخطر ثغرة شائعة في APIs؟
غياب التحقق من الملكية: التحقق من أن المستخدم مسجّل دخول دون التحقق من أن المورد المطلوب يخصه. هذا يتيح لأي مستخدم قراءة بيانات غيره بتغيير معرّف في الرابط، وهو الأشيع والأسهل استغلالاً.
هل يكفي HTTPS لتأمين API؟
لا. HTTPS يحمي البيانات أثناء النقل فقط. لا يمنع مستخدماً مصادقاً من الوصول لبيانات غيره، ولا يحمي من مدخلات خبيثة، ولا يعوّض عن غياب التفويض. هو شرط ضروري غير كافٍ.
كيف أحمي مفاتيح الخدمات الخارجية؟
لا تضعها في التطبيق إطلاقاً. اجعل التطبيق يستدعي خادمك، والخادم يستدعي الخدمة الخارجية بمفتاحه. هذا يبقي المفتاح خارج متناول أي شخص يفحص التطبيق.
متى أستخدم تحديد المعدل؟
على كل نقطة نهاية عامة، وبصرامة أعلى على: تسجيل الدخول، إعادة تعيين كلمة المرور، إرسال رموز التحقق، والبحث. هذه أكثر ما يُساء استخدامه آلياً.
هل أحتاج تدقيقاً أمنياً؟
للمشاريع التي تعالج بيانات حساسة أو مدفوعات: نعم، والقطاعات المنظمة قد تشترطه. للمشاريع الأصغر، مراجعة أمنية داخلية بقائمة التحقق أعلاه تغطي معظم المخاطر الشائعة.
كيف أتعامل مع ثغرة اكتُشفت بعد الإطلاق؟
أصلحها فوراً وأصدر تحديثاً، وأبطل الجلسات المتأثرة إن لزم، وقيّم ما إذا كان هناك تسرّب فعلي للبيانات. إن كان هناك خرق يمس بيانات شخصية، فالتزامات الإشعار النظامية تنطبق — ومهلتها قصيرة.
الخلاصة
التطبيق بيئة غير موثوقة — كل تحقق حقيقي يحدث في الخادم.
تحقق من الملكية في كل نقطة نهاية — أخطر ثغرة وأسهلها استغلالاً.
لا تضع أسراراً في كود العميل — كل ما في الحزمة قابل للاستخراج.
واحسب ما يهم في الخادم — الأسعار والصلاحيات لا تُستقبل من العميل.
تريد مراجعة أمنية لواجهاتك؟ تواصل معنا — نراعي هذه المبادئ في البناء لا بعد الاختراق. اطّلع على خدماتنا.