تأمين الـ API: الثغرات اللي تسرّب بيانات تطبيقك بهدوء

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

الثغرة الأشهر: غيّر الرقم وشوف بيانات غيرك

المستخدم يفتح طلبه على رابط مثل /orders/1052. يغيّر الرقم إلى 1053، ويطلع له طلب عميل ثاني باسمه وعنوانه وجواله. هذي ثغرة التحكم في الوصول على مستوى الكائن، وهي من أكثر ما يتكرر في الأنظمة. السبب إن الـ API تأكد إن المستخدم مسجل دخول، لكنه ما تأكد إن هذا الطلب يخصه هو.

• كل طلب لبيانات يتحقق في السيرفر: هل هذا المستخدم يملك هذا السجل أو مسموح له به؟
• لا تعتمد على إخفاء الزر في التطبيق — الـ API لازم يرفض بنفسه.
• المعرّفات العشوائية الطويلة تصعّب التخمين، لكنها مو بديل عن التحقق.

لا ترجع أكثر مما تحتاج الشاشة

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

لا تقبل حقولاً ما طلبتها

العكس خطر أيضاً: طلب تعديل الملف الشخصي يستقبل الاسم، فيضيف المهاجم حقل «role: admin» أو «balance». لو الكود يحفظ كل ما يوصله، صار مديراً أو غيّر رصيده. حدد الحقول المسموح تعديلها صراحة، وتجاهل الباقي.

تحديد معدل الطلبات

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

التحقق من المدخلات في السيرفر

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

رسائل الخطأ والسجلات

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

أسئلة تسألها لمطوّرك

• لو غيّرت رقم الطلب في الرابط، وش يصير؟
• وين يُحسب السعر النهائي، في التطبيق أو السيرفر؟
• فيه حد لمحاولات إرسال رمز التحقق؟
• هل الـ API يرجع حقولاً ما تعرضها الشاشة؟

التوكنات والجلسات

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

وثّق الـ API واعرف ما هو مكشوف

مع الوقت تتراكم نقاط وصول قديمة: نسخة أولى من الـ API ما عاد يستخدمها التطبيق، أو نقطة اختبار نسيها المطوّر مفتوحة بدون تحقق. هذي الأبواب المنسية من أخطر ما يكون، لأن ما أحد يراقبها.

• قائمة محدثة بكل نقاط الوصول ومن يحق له استخدام كل واحدة.
• إيقاف النسخ القديمة بعد انتقال المستخدمين للتحديث الجديد.
• لا نقاط اختبار أو تصحيح مفتوحة في بيئة الإنتاج.
• إعدادات CORS تسمح فقط لنطاقاتك بدل السماح للجميع.

في منصة أزهل الرقمية نبني الـ API لتطبيقات Flutter وأنظمة SaaS على مبدأ إن السيرفر ما يثق بأي طلب. لو تبي مراجعة لـ API موجود أو بناء جديد، تواصل على واتساب.