تأمين واجهات برمجة التطبيقات (API): ما الذي يتغيّر عندما تتحول شركتك نحو الجوال أولًا

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

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

لماذا تختلف مخاطر الـAPI عن مخاطر المواقع

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

أهم النقاط التي يجب التحقق منها

• المصادقة على كل نقطة وصول، لا فقط تلك التي تتطلبها شاشات التطبيق ظاهريًا — مهاجم يستدعي الـAPI مباشرة لن يلتزم بتدفق التنقل في تطبيقك.
• تحديد معدّل الطلبات (Rate Limiting)، كي لا يتمكن سكربت من قصف نقطة تسجيل الدخول أو البحث آلاف المرات في الدقيقة.
• التحقق من الصلاحية على مستوى الكائن: تأكد أن المستخدم المسجّل يملك فعليًا السجل الذي يطلبه برقم معرّف، لا فقط أنه مسجّل دخول بشكل عام.
• لا تثق أبدًا بالتحقق من جانب العميل وحده — أي فحص يتم فقط داخل كود التطبيق دون الخادم يمكن تجاوزه بالكامل.

سؤال يستحق طرحه على فريق التطوير لديك

"إذا استخرج أحدهم طلبات الـAPI الخاصة بتطبيقنا وأعاد تشغيلها من سكربت، لا من التطبيق نفسه، ماذا سيستطيع الوصول إليه؟" الـAPI المؤمَّن جيدًا يجيب بـ"لا شيء لا ينبغي له الوصول إليه". معظم الفرق التي لم تطرح هذا السؤال تجد أن الإجابة الصادقة غير مريحة.

الخطأ الأكثر شيوعًا بين الشركات

تأمين واجهة التطبيق بعناية مع افتراض أن الـAPI "غير عام" لأنه غير مرتبط بأي رابط ظاهر. أي API يستدعيه تطبيق جوال عام هو، من الناحية العملية، API عام — يستطيع أي شخص استخراجه واستدعاءه مباشرة.