كيف تصلح الـ 7 أخطاء الكارثية في أمن واجهات API خطوة بخطوة دليل عملي للمطورين
كيف تصلح الـ 7 أخطاء الكارثية في أمن واجهات API خطوة بخطوة (دليل عملي للمطورين)
يا جماعة، في المقال السابق تكلمنا بصراحة عن 7 أخطاء كارثية في أمن الـ API اللي كثير من المطورين يقعون فيها يوميًا. قلنا إن إخفاء الزر ما يحمي شيء، وإن الـ Token الموجود ما يعني إن كل شيء آمن، وإن تغيير الـ ID ممكن يفتح باب كارثة، وإن المصادقة ما تغني عن الصلاحيات، وإن الاعتماد على الـ Frontend وحده كارثة، وإن نسيان الـ HTTP Methods خطير، وإن غياب الـ Rate Limiting يخلي الـ API مفتوح للتجربة بلا حدود.
اليوم مو بس بنعيد الأخطاء. اليوم بنصلحها. خطوة بخطوة. بشكل عملي يقدر أي مطور يطبقه سواء كان يبني API جديد أو يراجع API موجود.
الهدف إنك تطلع من المقال وعندك صورة واضحة: وش تسوي بالضبط عشان تمنع هالأخطاء من الأساس.
1. إصلاح خطأ «أنا أخفيت الزر، خلاص محمي»
المشكلة: الأمان على الواجهة فقط.
الحل خطوة بخطوة:
كل Endpoint حساس (حذف، تعديل، عرض بيانات خاصة) لازم يمر بفحص صلاحيات على السيرفر قبل أي تنفيذ.
استخدم Middleware أو Guard يفحص: هل المستخدم مسجل دخول؟ وهل عنده الصلاحية المطلوبة على هذا المورد بالذات؟
لا تعتمد أبدًا على أن الواجهة ما تظهر الزر. افترض دائمًا أن أحدًا يرسل الطلب مباشرة (من Postman أو curl أو أي أداة).
في الكود: قبل ما تنفذ عملية الحذف أو التعديل، تحقق من ملكية المورد أو صلاحية الدور. لو فشل التحقق → رجّع 403 Forbidden فورًا.
القاعدة الذهبية: أي شيء يمر على السيرفر لازم يتحقق منه السيرفر.
2. إصلاح خطأ «الـ Token موجود، خلاص آمن»
المشكلة: قبول أي Token بدون فحوصات كافية، أو وضع أسرار في الواجهة.
الحل خطوة بخطوة:
تحقق دائمًا من: صحة التوقيع، انتهاء الصلاحية (exp)، والـ issuer والـ audience إن وُجدت.
طبق آلية إبطال (Revocation): لما يسجل المستخدم خروج، أضف الـ Token إلى قائمة سوداء أو استخدم Refresh Tokens قصيرة العمر مع إمكانية الإبطال.
لا تضع أبدًا API Keys أو Secrets داخل ملفات JavaScript أو أي كود يصل للمتصفح. استخدم متغيرات بيئة على السيرفر فقط.
أعطِ كل Token أقل صلاحيات ممكنة (Principle of Least Privilege). لا تعطِ Token عادي صلاحيات الأدمن.
استخدم HTTPS فقط، ويفضل HttpOnly + Secure للكوكيز إن كنت تستخدمها.
3. إصلاح خطأ تغيير الـ ID (BOLA / IDOR)
المشكلة: السيرفر ما يتحقق إن الـ ID يخص المستخدم الحالي.
الحل خطوة بخطوة:
لا تثق أبدًا في الـ ID اللي يجي من العميل. استخدم دائمًا هوية المستخدم من الـ Token أو الجلسة.
عند جلب أو تعديل مورد: تحقق أن resource.owner_id === current_user.id أو أن المستخدم يملك صلاحية صريحة على هذا المورد.
في الاستعلامات: أضف شرط المالك دائمًا (مثلاً: WHERE id = ? AND user_id = ?).
اختبر بنفسك: سجل دخول بحساب، غيّر الـ ID في الطلب، وتأكد أن السيرفر يرفض الطلب بحساب آخر.
استخدم UUIDs بدل الأرقام التسلسلية إن أمكن (يقلل التخمين)، لكن لا تعتمد عليها وحدها كحماية.
4. إصلاح خطأ «المصادقة موجودة = الصلاحيات موجودة»
المشكلة: الخلط بين Authentication و Authorization.
الحل خطوة بخطوة:
افصل الطبقتين بوضوح:
Authentication: من أنت؟ (هل الـ Token صحيح؟)
Authorization: وش يحق لك تسوي؟ (هل تقدر تشوف/تعدّل/تحذف هذا الشيء؟)
بعد نجاح المصادقة، مرّر الطلب إلى طبقة الصلاحيات.
استخدم أدوار (Roles) وصلاحيات دقيقة (Permissions)، وتحقق منها على مستوى كل عملية.
لا تعتمد على أن المستخدم «مسجل دخول» فقط. تحقق دائمًا من الصلاحية المحددة.
5. إصلاح الاعتماد على الـ Frontend بالكامل
المشكلة: كل التحقق في الواجهة.
الحل خطوة بخطوة:
انقل كل منطق التحقق إلى السيرفر: نوع الملف، الحجم، الصلاحيات، القيم المسموحة، إلخ.
الواجهة تكون للتجربة الجيدة فقط (منع إرسال طلبات غير صالحة لتوفير الطلبات)، أما الأمان الحقيقي فعلى السيرفر.
افترض دائمًا أن أحدًا يفتح Developer Tools ويعدل الطلب.
6. إصلاح نسيان الـ HTTP Methods
المشكلة: حماية GET فقط أو السماح بـ DELETE/PUT بدون قيود.
الحل خطوة بخطوة:
حدد لكل Endpoint الـ Methods المسموحة فقط، وارفض الباقي بـ 405 Method Not Allowed.
طبق فحص الصلاحيات على كل Method على حدة (DELETE يحتاج صلاحية أعلى عادة من GET).
اختبر كل Method يدويًا، مو بس اللي تستخدمه الواجهة.
7. إصلاح غياب Rate Limiting وحماية Brute Force
المشكلة: الـ API مفتوح للتجربة بلا حدود.
الحل خطوة بخطوة:
طبّق Rate Limiting من أول يوم (مثلاً: عدد طلبات معين لكل IP أو لكل مستخدم في الدقيقة/الساعة).
على نقاط تسجيل الدخول وإعادة تعيين كلمة المرور: حد صارم + تأخير تدريجي أو قفل مؤقت بعد محاولات فاشلة.
استخدم أدوات جاهزة (مثل Redis مع مكتبات Rate Limit) أو حلول السحابة.
راقب الطلبات الشاذة وسجّل المحاولات المشبوهة.
قائمة تحقق سريعة قبل ما تنشر أي API
كل Endpoint حساس يفحص الصلاحيات على السيرفر.
لا أسرار في الكود الأمامي.
فحص ملكية المورد (Owner Check) موجود.
فصل واضح بين المصادقة والصلاحيات.
كل Methods محمية، مو بس GET.
Rate Limiting مفعّل.
Tokens لها صلاحية محدودة وآلية إبطال.
HTTPS فقط.
اختبار يدوي: «لو أحد أرسل الطلب بنفسه بدون الواجهة… وش بيصير؟»
الـ API مو مجرد طريق بين التطبيق والسيرفر. هو الباب الخلفي للتطبيق كله. لو أصلحنا هالأخطاء السبعة من الأساس، نصير نبني تطبيقات أقوى بكثير.
لو عندك API معين تبي نطبق عليه هالخطوات عمليًا، أو تبي أمثلة كود بلغة معينة (Node.js أو Python أو غيرها)، اكتب في التعليقات. تعليقك مهم ويفتح مواضيع جديدة.
خلّونا نكمل المسار مع بعض.
تعليقات