كيف يعمل توثيق واجهات API بالرموز؟
تُوثّق معظم الواجهات كل طلب ببيانات اعتماد تُرسَل في ترويسة: رمز bearer (غالباً JWT صادر عن تدفق OAuth 2.0)، أو مفتاح API، أو بيانات Basic عبر TLS. يتحقق الخادم منها في كل نداء — التوقيع والانتهاء والجمهور والنطاقات — ويجيب بـ 401 عند غيابها أو بطلانها وبـ 403 عندما تكون صالحة لكنها غير مصرَّح لها. اختبار التوثيق يعني تجربة كل هذه المسارات لا المسار السعيد فقط.
ملاحظة أمنية: خلل التوثيق وخلل التفويض على مستوى الكائن يتصدران قائمة OWASP لأمن الواجهات. اختبر أن الرمز المنتهي أو المعدَّل أو الخاص بمستخدم آخر يُرفض، وأن كل معرّف كائن يُفحص مقابل المستدعي — لا نقطة النهاية فقط.
اقرأ الدليل: ما هو JWT؟ شرح رموز JSON Web Token
الإجابة: لا
النتيجة: 401الصفوف:No credentials،Empty token،Empty key،Wrong scheme،Key in the wrong placeالإجابة: نعم
سؤال 2: هل هي صالحة؟التوقيع والانتهاء والجمهور، أو البحث عن المفتاح أو كلمة المرورالإجابة: لا
النتيجة: 401الصفوف:Tampered token،Tampered key،Wrong password،Empty passwordالإجابة: نعم
سؤال 3: هل يُسمح لهذا المستدعي بذلك؟النطاقات، وفحص كل معرّف كائن مقابل المستدعيالإجابة: لا
النتيجة: 403افحصه على حدة برمز مستخدم آخر أو دور آخر، إذ ستُظهر الأداة صف «Valid credentials» بحالة FAILليس ضمن المصفوفةالإجابة: نعم
النتيجة: 2xxالصف:Valid credentials
أسماء الصفوف كما تطبعها الأداة، ويرسل كل تشغيل خمسة صفوف للنوع المختار. وينجح كل صف عدا «Valid credentials» بـ 401 أو 403 ويخفق بـ 2xx أو 5xx، وتُعطي الأداة تحذيراً عند 401 بلا ترويسة WWW‑Authenticate أو بجسم خطأ يسرّب معلومات.
كيفية استخدام مختبِر مصادقة API
- أدخل نقطة النهاية والطريقة، ثم بيانات الاعتماد الصالحة.
- اختيارياً أضف ترويسات إضافية أو جسم طلب.
- شغّل المصفوفة وراجع الجدول: تعني PASS أن واجهة API تصرفت بشكل صحيح مع ذلك المتغير.
- وسّع أي صف لفحص الاستجابة الكاملة، وانسخ ملخّص Markdown إلى نتائجك.
مزايا مختبِر مصادقة API
- يرسل الطلب نفسه ببيانات اعتماد صالحة ومفقودة ومعدَّلة وفارغة وموضوعة في المكان الخطأ
- يدعم رموز Bearer ومصادقة Basic ومفاتيح API في الترويسات أو معاملات الاستعلام
- حكم لكل متغير مع الحالة المتوقّعة مقابل الفعلية، إضافةً إلى فحص ترويسة WWW-Authenticate وأجسام الأخطاء التي تسرّب معلومات
- استجابة كاملة قابلة للتوسيع لكل متغير
- ملخّص Markdown للتقارير؛ ولا تُخزَّن بيانات الاعتماد أبداً
مثال على مختبِر مصادقة API
نقطة نهاية محمية برمز Bearer
الإدخال:
GET https://httpbin.org/bearer
Bearer token: demo-token-1234567890النتيجة:
Valid credentials 200 PASS Accepted (200).
No credentials 401 PASS Rejected with 401.
Tampered token 200 FAIL accepted — authentication is NOT enforced for this case.
Empty token 401 PASS
Wrong scheme 401 PASSالأسئلة الشائعة حول مختبِر مصادقة API
ماذا ترسل المصفوفة؟
الطلب نفسه مع (1) بيانات اعتمادك الصالحة، و(2) بدون بيانات اعتماد، و(3) بيانات اعتماد معدَّلة، و(4) بيانات اعتماد فارغة، و(5) بيانات الاعتماد بنظام (scheme) أو موضع خاطئ. وتُقارن كل استجابة بالحالة المتوقّعة 2xx/401/403.
ماذا تعني FAIL؟
أن متغيراً بلا بيانات اعتماد صالحة قد قُبل (2xx)، أو أن بيانات الاعتماد الصالحة رُفضت، أو أن بيانات الاعتماد المشوّهة سبّبت خطأ 5xx. أما التحذيرات فتشير إلى تفاصيل مثل غياب ترويسة WWW-Authenticate أو أجسام الأخطاء المفرطة التفصيل.
هل تُخزَّن بيانات اعتمادي؟
لا. تُستخدم لهذا التشغيل فقط ولا تغادر الصفحة إلا داخل الطلبات التي طلبت إرسالها.
هل يمكنني اختبار مفاتيح API في سلسلة الاستعلام؟
نعم — اختر مفتاح API واضبط «إضافة إلى: معامل الاستعلام». كما تجرّب المصفوفة إرسال المفتاح في الموضع الآخر.
ملاحظات تقنية
يبدّل التعديل (tampering) حرفاً واحداً قرب نهاية السرّ حتى تفشل التوقيعات وعمليات البحث بينما تبقى الصيغة معقولة. وتُفحص أجسام استجابات 401/403 بحثاً عن أنماط تتبّع المكدس (stack trace) والحجم غير المعتاد، وهما مؤشران شائعان على تسرّب المعلومات.
المراجع
- RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usageكيف يُرسَل رمز bearer (Authorization: Bearer …) واستجابات الخطأ التي يعيدها خادم الموارد.
- RFC 6749: The OAuth 2.0 Authorization Frameworkأدوار OAuth 2.0 وأنواع المنح ونقاط نهاية الرموز التي تُصدر رموز الوصول والتحديث.
- RFC 9700: Best Current Practice for OAuth 2.0 Securityإرشادات الأمان الحالية لـ OAuth 2.0: استخدام PKCE للعملاء العامين ومطابقة عناوين إعادة التوجيه بدقة وتقييد الرموز بالمرسل.