7 أخطاء كارثية في أمن واجهات API يقع فيها المطورون يوميًا
أخطاء الناس في أمن الـ API… والكوارث اللي تصير بسببها
يا جماعة، خلونا نتكلم بصراحة اليوم.
كثير ناس يظنون إنهم سووا أمن للتطبيق، بس الواقع إنهم سووا "وهم أمن". الـ API صارت أهم نقطة في أي تطبيق حديث، ومع ذلك الناس يسوون فيها أخطاء تضحك لو ما كانت خطيرة.
خلونا نعدد أشهر الكوارث اللي أشوفها كل يوم:
1. "أنا أخفيت الزر، خلاص محمي"
هذي من أكثر الأشياء اللي تخلي الواحد ينهار من الضحك.
المطور يقول: "المستخدم العادي ما يشوف زر الحذف، يعني ما يقدر يحذف".
طيب والـ Endpoint؟
DELETE /api/users/55
لو ما في فحص صلاحيات على السيرفر، أي واحد يقدر يرسل الطلب بنفسه.
إخفاء الزر من الواجهة ما يحمي شيء. الأمان الحقيقي يكون على السيرفر، مو على واجهة المستخدم.
2. "الـ Token موجود، خلاص آمن"
كثير يرسلون الـ Token في الـ Header ويظنون إن الموضوع خلص.
بس ما يتحققون:
هل الـ Token منتهي الصلاحية؟
هل يقدرون يستخدمون نفس الـ Token بعد ما يسجلون خروج؟
هل الـ Token فيه صلاحيات أكثر من اللي يحتاجها المستخدم؟
وفي ناس أسوأ من كذا: يحطون الـ API Key أو الـ Secret داخل ملفات JavaScript اللي أي واحد يقدر يفتحها من المتصفح. هذي كارثة بكل معنى الكلمة.
3. تغيير الـ ID وخلاص
واحد يسجل دخول بحسابه، يشوف رابط زي:
/api/orders/1024
يغير الرقم لـ 1025… ويطلع طلب شخص ثاني.
هذي اسمها BOLA أو IDOR، ومن أكثر الثغرات اللي لسا موجودة بكثرة. السبب؟ المطور ما تحقق إن هذا الـ ID يخص المستخدم الحالي ولا لا.
4. "الـ Authentication موجود، يعني الصلاحيات موجودة"
لا يا حبيبي.
Authentication تجاوب على سؤال: مين أنت؟
Authorization تجاوب على سؤال: وش يحق لك تسوي؟
كثير تطبيقات تتحقق إنك مسجل دخول، بس ما تتحقق إنك تقدر تشوف أو تعدل أو تحذف هالشيء. والنتيجة؟ مستخدم عادي يقدر يوصل لبيانات الأدمن.
5. الاعتماد على الـ Frontend بالكامل
بعض الناس يسوون التحقق كله في الـ Frontend (مثل التحقق من نوع الملف أو حجم الطلب أو حتى الصلاحيات).
أي واحد يفتح Developer Tools يقدر يتخطى كل هالتحققات. التحقق لازم يكون على السيرفر دائمًا.
6. نسيان الـ HTTP Methods
واحد يحمي الـ GET ويظن إن الموضوع خلص.
بس الـ PUT و DELETE و PATCH مفتوحة بدون صلاحيات.
أو العكس: يسمح بـ DELETE لأي مستخدم مسجل دخول. النتيجة؟ كارثة حذف بيانات.
7. ما في Rate Limiting ولا حماية من Brute Force
الـ API مفتوح للتجربة بلا حدود. أي واحد يقدر يجرب آلاف كلمات المرور أو يرسل طلبات بشكل مكثف لحد ما يطيح السيرفر أو يخمن الـ Token.
كيف تتجنب هالكوارث؟
لا تعتمد أبدًا على الواجهة. كل شيء يمر على السيرفر لازم يتحقق منه السيرفر.
فرّق بين Authentication و Authorization.
اختبر تغيير الـ IDs بنفسك في بيئة اختبار.
لا تضع أسرار في الكود الأمامي أبدًا.
استخدم HTTPS دائمًا، وحدد صلاحية الـ Tokens، وأبطلها لما يسجل المستخدم خروج.
اختبر كل الـ Methods، مو بس اللي تستخدمها الواجهة.
وحط Rate Limiting من أول يوم.
الـ API مو مجرد "طريق" بين التطبيق والسيرفر. هو الباب الخلفي للتطبيق كله. لو الباب الخلفي مفتوح، ما يهمك الباب الأمامي كم كان محكم.
إذا كنت تبني تطبيق أو تختبر واحد، اسأل نفسك هالسؤال دائمًا:
"لو أحد أرسل الطلب هذا بنفسه بدون ما يمر على الواجهة… وش بيصير؟"
إذا الجواب يخوفك، يعني في مشكلة لازم تصلحها اترك تعليق تعليقك بالنسبه لي مهم
تعليقات