AIM Tech

🔐 Authentication & Authorization Testing

خليني أبسطلك الموضوع:

  • Authentication (المصادقة): يعني النظام لازم يعرف إنت مين؟ (تسجيل دخول + هوية).
  • Authorization (التفويض): حتى لو اتأكد إنك مستخدم صحيح، النظام لازم يعرف مسموحلك تعمل إيه؟ (صلاحياتك).

👀 تخيل السيناريو ده:

إنت نايم ومرتاح، فجأة تصحى تلاقي إشعارات:

  • Transaction بمبلغ كبير خرج من حسابك!
  • أو رصيدك كله اختفى واتحول بالسالب!

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


⚠️ أمثلة لاختبارات Critical:

1️⃣ Expired Token Test
لو أي مستخدم حاول يعمل Transaction باستخدام Token منتهي الصلاحية، المفروض الـ Backend يرجع:

Status Code: 401 Unauthorized

لكن لو النظام نفذ العملية؟ 😱 يبقى كده الحسابات كلها معرضة للاختراق.

2️⃣ Role-Based Authorization Test

  • موظف خدمة عملاء مثلاً مش لازم يقدر يحوّل فلوس بين الحسابات.
  • لو الـ system مش عامل Authorization صح، ممكن موظف بيساعد عميل يدخل على صلاحيات مش بتاعته.

3️⃣ Invalid / Manipulated Token Test

  • لو حد غيّر أي جزء من الـ Token يدويًا أو دخل Token تبع مستخدم تاني.
  • لازم السيرفر يرفضه مباشرة.

🛠️ خطوات عملية بالـ Postman:

  1. افتح الـ Request اللي فيه Transaction.
  2. في Authorization Tab اختار Bearer Token.
  3. جرب:
    • حط expired token.
    • حط token غلط أو متلاعب فيه.
    • جرّب تعمل Transaction بصلاحيات مش مسموح بيها.
  4. شوف رد السيرفر:
    • لو رجعلك 401 Unauthorized أو 403 Forbidden → ✅ النظام آمن.
    • لو العملية تمت → 🚨 عندك مشكلة كبيرة.

🚨 ليه النوع ده من الاختبار Critical؟

  • لأنه بيحمي أموال المستخدمين.
  • بيمنع أي هاكر يستغل ثغرة صغيرة في الـ API ويعمل Transactions مكانك.
  • بيحافظ على سمعة الشركة قدام السوق والعملاء.
  • بيوفر على الشركة خسائر مالية فادحة.
  • والأخطر: ممكن ينقذها من قضايا قانونية ومساءلة جنائية.

✨ الخلاصة

الـ Authentication & Authorization Testing مش مجرد خطوة عابرة، دي خط الدفاع الأول ضد أي اختراق محتمل.
وعلشان كده، أي QA محترف لازم يديها أولوية مطلقة في خطة اختبار الـ API.