اختبار أمان واجهات API

Q: ماذا يجب أن تعيد الواجهة عند بلوغ الحدّ؟

يعرّف RFC 6585 الرمز 429 Too Many Requests ويذكر أن الاستجابة ينبغي أن تشرح الحالة ويجوز أن تتضمن ترويسة Retry-After. و200 يعيد بصمت صفوفاً أقل من المطلوب مقبول لتقييد حجم الصفحة عندما ينص العقد على ذلك؛ أما 500 أو انتهاء المهلة فعيب: الحدّ مفقود أو لا يصمد.

بقلم فريق ضمان الجودة في متقن سوفت · آخر تحديث 6 أكتوبر 2026 · 23 دقيقة · متوسط

اختبار أمان واجهات API (API Security Testing) يتحقق من أن الواجهة ترفض ما يجب رفضه ولا تعيد إلا ما يحق للمستدعي الحصول عليه عندما تُستدعى مباشرةً لا عبر شاشات التطبيق. فالواجهة تجيب أمر curl كما تجيب تطبيق الجوال، لذا فكل قاعدة تبدو الشاشة وكأنها تفرضها يجب أن يفرضها الخادم مرة أخرى. ومن النتائج المعتادة: يعرض التطبيق للزبون فواتيره فقط، لكن GET /v1/invoices/88213 بعد تغيير الرقم يعيد فاتورة زبون آخر.

أساس الاختبار في هذا الدرس هو قائمة OWASP لأهم عشرة مخاطر في أمان واجهات API (OWASP API Security Top 10) بإصدار 2023، وهي قائمة توعوية بعشرة مخاطر رتّبها فريق مشروع OWASP وفق منهجية OWASP لتقدير المخاطر (OWASP Risk Rating Methodology): مدى سهولة استغلال كل نقطة ضعف، ومدى انتشارها وسهولة اكتشافها، وأثرها التقني. ومدى الانتشار اتفق عليه الفريق ولم يُقَس من بيانات مجمّعة، فالقائمة ترتّب المخاطر ولا تُحصي الحوادث. ستتعلم ما كل خطر وفحصاً آمناً واحداً له، ثم تتعمق في أربعة منها: كسر التفويض على مستوى الكائن (BOLA)، وكسر المصادقة، والكشف المفرط عن البيانات، وغياب تحديد المعدل.

لماذا يهم

الواجهة البرمجية هي التي تحمل البيانات، أما واجهة المستخدم فلا تفعل سوى عرضها. فإخفاء الأزرار والتحقق في جهة العميل لا يحميان شيئاً من مستدعٍ يخاطب الواجهة مباشرةً، ومعظم المستدعين يفعلون ذلك: تطبيقات الجوال وتكاملات الشركاء والخدمات الأخرى. وفحص ملكية واحد مفقود يكشف سجلات كل زبون لكل زبون آخر، ونقطة نهاية لرمز التحقق (OTP) بلا حدّ تسمح لبرنامج بتجربة الرموز حتى ينجح أحدها. وعيوب كهذه تتحول إلى تسريب للبيانات واحتيال، لا إلى أخطاء شكلية.

والخبر الجيد للمختبِر أن معظم هذه الفحوص صور مختلفة لما تفعله أصلاً: غيّر الرمز (Token)، وغيّر المعرّف، واقرأ الاستجابة الخام، وكرّر الطلب، وقارن استجابتين. فهي لا تحتاج إلى ماسح ولا إلى مهارات استغلال، والمختبِر الوظيفي الذي يجريها لكل نقطة نهاية جديدة يكتشف كثيراً من هذه العيوب قبل اختبار الاختراق بوقت طويل.

قائمة OWASP API Security Top 10 (2023) بوصفها قائمة فحص

تنشر OWASP قائمة Top 10 منفصلة للواجهات البرمجية لأن مخاطرها تختلف عن مخاطر صفحات الويب: لا متصفح يُهاجَم، لكن في كل طلب معرّفات، ورموز بدل الجلسات، ولا شاشة تخفي شيئاً. وقد حلّ إصدار 2023 محل إصدار 2019 وأعاد تنظيم القائمة؛ وما زال كثير من الفرق يستخدم اسمين من إصدار 2019: «الكشف المفرط عن البيانات» (Excessive Data Exposure) الذي صار جزءاً من API3، و«نقص الموارد وتحديد المعدل» (Lack of Resources & Rate Limiting) الذي صار API4، لذا يذكر هذا الدرس الاسمين معاً.

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

API1:2023 كسر التفويض على مستوى الكائن (Broken Object Level Authorization – BOLA): تثق الواجهة بمعرّف قادم من العميل دون التحقق من أن المستدعي يحق له الوصول إلى ذلك الكائن. الفحص: الطلب نفسه برمز مستخدم آخر.
API2:2023 كسر المصادقة (Broken Authentication): الرموز وتسجيل الدخول ضعيفة أو بلا حدود: رموز تُقبل بعد انتهاء صلاحيتها أو بعد تسجيل الخروج، ومحاولات غير محدودة لكلمة المرور أو رمز OTP، وبيانات اعتماد في الروابط. الفحص: رمز مفقود ومنتهٍ وملغى ومعدَّل؛ وعدّ المحاولات المسموح بها.
API3:2023 كسر التفويض على مستوى خصائص الكائن (Broken Object Property Level Authorization): تحمل الاستجابة خصائص لا يحق للمستدعي رؤيتها (الكشف المفرط عن البيانات) أو يستطيع الطلب ضبط خصائص لا يحق له ضبطها (الإسناد الجماعي Mass Assignment). الفحص: اقرأ JSON الخام مقابل العقد؛ وأرسل حقلاً إضافياً.
API4:2023 الاستهلاك غير المقيّد للموارد (Unrestricted Resource Consumption): لا حدّ لمعدل الطلبات أو حجم الصفحة أو حجم الرفع أو العمليات التي تكلف مالاً مثل الرسائل النصية. الفحص: كرّر بسرعة، واطلب pageSize=50000، وارفع بايتاً واحداً فوق الحد الأقصى.
API5:2023 كسر التفويض على مستوى الوظيفة (Broken Function Level Authorization): يستطيع دور استدعاء وظيفة دور آخر. الفحص: رمز زبون على نقطة نهاية إدارية، كما في درس اختبار التفويض في واجهات API.
API6:2023 الوصول غير المقيّد إلى تدفقات الأعمال الحساسة (Unrestricted Access to Sensitive Business Flows): تدفق يضر بالعمل إذا أُتمت (شراء المخزون كله، وحجز كل المواعيد، والتسجيل الجماعي) بلا حدّ ولا تحقق إضافي (Step-up) مثل CAPTCHA أو رمز لمرة واحدة، ولا مراجعة. الفحص: أتمت التدفق بحساب واحد وانظر هل يبطئه شيء.
API7:2023 تزوير الطلبات من جهة الخادم (Server Side Request Forgery – SSRF): يجلب الخادم رابطاً يقدمه العميل، مثل webhook أو استيراد صورة، بلا قائمة سماح. الفحص: قدّم رابط التقاط تتحكم فيه (رابط يسجّل كل طلب يصله، مثل رابط من أداة Webhook Tester) وتأكد مما يجلبه الخادم؛ واسأل المطور كيف تُرفض العناوين الخاصة بدلاً من سبرها.
API8:2023 سوء التهيئة الأمنية (Security Misconfiguration): أخطاء مطوّلة تحمل تتبّع المكدس، وHTTP بلا TLS، وCORS يسمح بأي أصل، وطرق غير لازمة، وإعدادات افتراضية. الفحص: طلب واحد مشوّه وترويسات الاستجابة.
API9:2023 سوء إدارة الجرد (Improper Inventory Management): إصدارات قديمة ونقاط نهاية للتصحيح ما زالت تجيب؛ ووثيقة OpenAPI تختلف عن الواجهة المنشورة. الفحص: استدعِ /v1 بعد نشر /v2؛ واحصر ما يجيب وليس موثقاً.
API10:2023 الاستهلاك غير الآمن لواجهات API (Unsafe Consumption of APIs): يُوثَق ببيانات واجهة شريك دون التحقق منها ولا حدود لحجمها ولا فحص لإعادة التوجيه. الفحص: حاكِ الشريك وأعد بيانات سيئة.

كل بند في قائمة OWASP API Security Top 10 (2023) يصبح سؤالاً عن كل نقطة نهاية وفحصاً آمناً واحداً بحساباتك الاختبارية؛ والصفوف المظللة هي المخاطر الأربعة التي يعلّمها هذا الدرس بعمق.

بند OWASP API	موضع الخلل	فحص آمن واحد	المتوقع
API1:2023كسر التفويض على مستوى الكائن (BOLA)	يُوثَق بمعرّف قادم من العميل دون التحقق من أن المستدعي يحق له الوصول إلى ذلك الكائن	الطلب نفسه برمز مستخدم آخر من الدور نفسه	`404` أو `403`؛ ولا بيانات للمستخدم الآخر
API2:2023كسر المصادقة	رموز تُقبل بعد انتهاء صلاحيتها أو تسجيل الخروج؛ ومحاولات غير محدودة لكلمة المرور أو رمز OTP	بلا رمز، وبرمز منتهٍ وملغى ومعدَّل؛ وعدّ محاولات OTP الخاطئة	`401` مع ترويسة `WWW-Authenticate` وبلا بيانات في الجسم؛ و`429` أو قفل بعد محاولات قليلة
API3:2023كسر التفويض على مستوى خصائص الكائن	تحمل الاستجابة خصائص لا يحق للمستدعي رؤيتها (الكشف المفرط عن البيانات)؛ ويستطيع الطلب ضبط خصائص لا يحق له ضبطها (الإسناد الجماعي)	قارن JSON الخام بالعقد؛ وأضف `"role": "admin"` إلى طلب `PATCH` صالح ثم اقرأ الكائن من جديد	حقول العقد فقط؛ و`400` أو تجاهل الحقل وبقاؤه دون تغيير
API4:2023الاستهلاك غير المقيّد للموارد	لا حدّ لمعدل الطلبات أو حجم الصفحة أو حجم الرفع أو العمليات التي تكلف مالاً	كرّر بسرعة بأعداد متفق عليها؛ واطلب `pageSize=50000`؛ وارفع بايتاً واحداً فوق الحد الأقصى	`429`، مع `Retry-After` إن نصّ عليها العقد؛ وصفحة مقيّدة؛ و`400` أو `413`
API5:2023كسر التفويض على مستوى الوظيفة (BFLA)	يستطيع دور استدعاء وظيفة دور آخر	رمز زبون على نقطة نهاية إدارية، من مصفوفة المستخدمين × الطلبات في درس اختبار التفويض في واجهات API	`403` أو `404`؛ ولا شيء تغيّر
API6:2023الوصول غير المقيّد إلى تدفقات الأعمال الحساسة	تدفق يضر بالعمل إذا أُتمت بلا حدّ ولا تحقق إضافي ولا مراجعة	أتمت التدفق بحساب واحد	شيء يبطئه أو يوقفه: حدّ أو تحقق إضافي أو مراجعة
API7:2023تزوير الطلبات من جهة الخادم (SSRF)	يجلب الخادم رابطاً يقدمه العميل بلا قائمة سماح	قدّم رابط التقاط تملكه؛ واسأل المطور كيف تُرفض العناوين الخاصة	لا يُجلب إلا من المضيفين المسموح بهم
API8:2023سوء التهيئة الأمنية	تتبّع المكدس في الأخطاء، وHTTP بلا TLS، وCORS لأي أصل، وطرق غير لازمة، وإعدادات افتراضية	طلب واحد مشوّه؛ واقرأ ترويسات الاستجابة	خطأ عام بلا تفاصيل داخلية؛ وترويسات كما اتُفق عليه مع الفريق
API9:2023سوء إدارة الجرد	إصدارات قديمة ونقاط نهاية للتصحيح ما زالت تجيب؛ ووثيقة OpenAPI تختلف عن الواجهة المنشورة	استدعِ `/v1` بعد نشر `/v2`؛ واحصر ما يجيب وليس موثقاً	الإصدارات المتقاعدة ترفض؛ والوثيقة تطابق المنشور
API10:2023الاستهلاك غير الآمن لواجهات API	يُوثَق ببيانات واجهة شريك دون التحقق منها ولا حدود لحجمها ولا فحص لإعادة التوجيه	حاكِ الشريك وأعد بيانات سيئة	يُتحقق منها وتُرفض؛ لا انهيار ولا تخزين

يعلّمه هذا الدرس بعمق

كل فحص: بحساباتك الاختبارية، وفي بيئة الاختبار، وبإذن كتابي؛ وتوقف عند أول سجل يثبت العيب.

جرّبها: مولّد حالات اختبار من OpenAPI جرّبها: مختبِر Webhook جرّبها: مدقّق ترويسات API

BOLA وكسر المصادقة: غيّر الرمز ثم غيّر المعرّف

BOLA هو الخطر الأول لأن المعرّفات في كل مكان في الواجهات، والتحقق من أن المستدعي يملك الكائن يجب أن يُكتب لكل واحد منها. بنى درس اختبار التفويض في واجهات API مصفوفة المستخدمين × الطلبات؛ أما جولة الأمان فتوسّعها إلى المعرّفات التي تفوتها المصفوفة عادةً: سلاسل الاستعلام مثل ?accountId=، وأجسام الطلبات، والترويسات، والمسارات المتداخلة مثل /parcels/7731/label.pdf، ونقاط نهاية الدفعات والتصدير، وتنزيلات الملفات التي كثيراً ما تُقدَّم عبر مسار شيفرة مختلف بلا أي فحص. استخدم دائماً حسابين من الدور نفسه، وتوقف عند أول سجل يثبت العيب: مهمتك أن تبيّن أن الفحص مفقود، لا أن تجمع بيانات الآخرين.

كسر المصادقة في الواجهة يدور غالباً حول الرموز ونقاط النهاية المحيطة بتسجيل الدخول. لكل نقطة نهاية محمية أرسل الطلب بأربع طرق وتوقع 401 في كل مرة، مع ترويسة WWW-Authenticate كما في درس مصادقة واجهات API، ودون أي بيانات أو تفاصيل داخلية في الجسم: بلا رمز، وبرمز منتهي الصلاحية، وبرمز من جلسة سجّلت خروجها، وبرمز غُيّر حرف واحد من توقيعه. ثم انظر إلى نقاط النهاية التي تصدر بيانات الاعتماد:

التحقق من كلمة المرور ورمز OTP وإعادة تعيين كلمة المرور: عدّ المحاولات الخاطئة التي تقبلها الواجهة قبل 429 أو قفل الحساب. رمز OTP من ستة أرقام له مليون قيمة ممكنة؛ وبلا حدّ يصبح التخمين مسألة وقت.
رموز JWT: يجب ألا تُقبل الترويسة مع "alg": "none"، ويجب رفض رمز صادر لجمهور (audience) آخر أو من مُصدر (issuer) لا تثق به الواجهة؛ ويعرض RFC 8725 (أفضل الممارسات الحالية لرموز JWT) هذه الفحوص. وتُظهر أداتا JWT Header Analyzer وJWT Claims Analyzer ما يدّعيه الرمز قبل أن تختبر ما تفعله الواجهة به.
أجسام الأخطاء: يجب أن تتطابق رسالتا «كلمة مرور خاطئة» و«لا يوجد حساب»، وإلا أكدت نقطة تسجيل الدخول أي الحسابات موجودة.
بيانات الاعتماد والرموز لا مكان لها في الروابط أو السجلات أو رسائل الخطأ؛ فالرمز في سلسلة الاستعلام ينتهي في سجل كل وكيل.

# One protected request, four ways.
# Expected: 401 each time, with WWW-Authenticate and no data in the body
GET /v1/users/me HTTP/1.1
Host: api.example.test
# 1. no Authorization header
# 2. Authorization: Bearer <expired token>
# 3. Authorization: Bearer <token of a session that has logged out>
# 4. Authorization: Bearer <valid token with one signature character changed>

# OTP verification: send code 000001, then 000002, 000003 ...
# Expected: 429 or a lockout after a small number of attempts
POST /v1/auth/otp/verify HTTP/1.1
Host: api.example.test
Content-Type: application/json

{"phone": "+9665XXXXXXXX", "code": "000001"}

جرّبها: مختبِر مصادقة API جرّبها: محلّل ترويسة JWT جرّبها: محلّل مطالبات JWT

الكشف المفرط عن البيانات وغياب تحديد المعدل

يحدث الكشف المفرط عن البيانات عندما تعيد الواجهة الكائن كله وتعتمد على العميل ليعرض جزءاً منه فقط. تعرض شاشة الملف الشخصي اسماً وصورة؛ أما الاستجابة الخام فتحمل أيضاً البريد الإلكتروني ورقم الهاتف ورقم الهوية الوطنية وملاحظات داخلية أو تجزئة كلمة المرور. ويضم إصدار 2023 هذا الخطر مع الإسناد الجماعي في البند API3، لأن كليهما السؤال المفقود نفسه: هل يحق لهذا المستدعي أن يرى هذه الخاصية أو يضبطها؟ اختبر جانب القراءة بمقارنة كل استجابة خام بالعقد، كما في درس التحقق من مخطط واجهات API، وبالسؤال عن كل حقل: هل يحتاج هذا الدور إليه؟ واختبر جانب الكتابة بإضافة خاصية لا يحق للمستدعي التحكم فيها، مثل "role": "admin" أو "balance": 9999 أو "verified": true، إلى طلب PATCH أو POST صالح فيما عدا ذلك، ثم اقرأ الكائن من جديد: النتيجتان الصحيحتان هما 400، أو تجاهل الحقل بصمت وبقاؤه دون تغيير.

تحمي حدود المعدل الموارد التي يستهلكها كل طلب: المعالج والذاكرة وعرض النطاق واتصالات قاعدة البيانات والمال، عندما ترسل نقطة النهاية رسالة نصية أو تستدعي خدمة مدفوعة. وبدونها يستطيع عميل واحد استنزاف الخدمة على الجميع أو تنفيذ هجمات التخمين المذكورة أعلاه. ويعرّف RFC 6585 الرمز 429 Too Many Requests لهذا الغرض ويذكر أن الاستجابة قد تحمل ترويسة Retry-After. وللفحص الآمن ثلاثة أجزاء ومكان واحد:

المعدل: أرسل الطلب نفسه بسرعة، بأعداد متفق عليها مع الفريق، وسجّل رقم الطلب الذي يظهر عنده أول 429 والترويسات التي يحملها، وهل الحدّ لكل مستخدم أم لكل مفتاح API أم لكل عنوان IP، فالحدّ المقتصر على عنوان IP يبدأ من جديد عندما يغيّر العميل عنوانه.
الحجم: اطلب ?pageSize=50000، وأرسل جسماً أو ارفع ملفاً يزيد بايتاً واحداً على الحد الأقصى الموثق، وعشّش جسم JSON أعمق مما يفعله أي عميل. توقع 400 أو 413 وصفحة مقيّدة، لا استجابة من 50000 صف أبداً.
التكلفة: لنقاط النهاية التي ترسل رسائل نصية أو بريداً أو تستدعي شريكاً، تأكد من وجود حدّ يومي لكل مستخدم يفرضه الخادم لا التطبيق.
المكان: بيئة اختبار يُسمح لك بتحميلها فقط، وبأعداد متفق عليها مع الفريق، لأن الفحص نفسه حمل؛ لا في الإنتاج أبداً ولا على نظام أي جهة أخرى.

جرّبها: محلّل استجابات API جرّبها: مدقّق مخططات API جرّبها: منشئ طلبات API

مثال تطبيقي: جولة أمان على واجهة الخدمة الذاتية لشركة اتصالات

واجهة خدمة ذاتية لشركة اتصالات في بيئة الاختبار، وحسابا زبونين A وB لكل منهما خط اختباري، ووثيقة OpenAPI، وإذن كتابي من الفريق. تغطي الخطة خمس نقاط نهاية والمخاطر الأربعة أعلاه، وكُتبت النتائج المتوقعة من العقد قبل أول طلب. ومن الفحوص الثمانية كشفت ستة عن عيوب:

C1، BOLA: رمز B على GET /v1/accounts/A/invoices أعاد 200 مع فواتير A بدلاً من 404. حرج (Critical): أي زبون يستطيع قراءة فواتير أي زبون.
C3، كسر المصادقة: رمز من جلسة سجّلت خروجها ما زال مقبولاً؛ فتسجيل الخروج لم يفعل سوى حذفه من الجهاز. رئيسي (Major).
C4، كسر المصادقة: 50 رمز OTP خاطئاً متتالياً، كلها 400، بلا 429 ولا قفل. حرج: يمكن تخمين رمز الدخول.
C5، الكشف المفرط عن البيانات: GET /v1/users/me أعاد nationalId وpasswordHash، ولا وجود لأي منهما في العقد. حرج: بيانات الهوية وتجزئة كلمة المرور تصل إلى أي عميل.
C6، الإسناد الجماعي: PATCH /v1/users/me مع "planTier": "premium" أعاد 200، وأظهر GET جديد ترقية الباقة. رئيسي، وله أثر مالي.
C7، استهلاك الموارد: ?pageSize=50000 على سجلات استخدام الخط الاختباري للزبون A أعاد السجلات كلها، وعددها 12000، في صفحة واحدة خلال تسع ثوانٍ؛ ولم يُفرض الحد الوارد في العقد (100). رئيسي.

Telecom self-service API, test environment. Customers A and B, each with a test line.

#   Risk  Request (actor)                               Expected     Observed
C1  API1  B: GET /v1/accounts/A/invoices                404          200, A's invoices
C2  API2  no token: GET /v1/users/me                    401          401
C3  API2  A after logout: GET /v1/users/me              401          200
C4  API2  POST /v1/auth/otp/verify, 50 wrong codes      429 early    50 x 400, no lockout
C5  API3  A: GET /v1/users/me, fields vs contract       contract     2 extra fields
C6  API3  A: PATCH /v1/users/me {"planTier":"premium"}  400/ignored  200, plan upgraded
C7  API4  A: GET /v1/accounts/A/usage?pageSize=50000    100 rows     12000 rows, 9 s
C8  API4  A: GET /v1/accounts/A/invoices, 60 in 10 s    429 after 30 429 from request 31

جرّبها: مختبِر REST API جرّبها: مقارنة استجابات API

أخطاء شائعة

الاختبار عبر شاشات التطبيق فقط، فلا ترى الاستجابة الخام أبداً ولا ترسل طلباً لا يرسله التطبيق.
استخدام حساب واحد لكل دور، وهو ما يجعل اختبارات مستوى الكائن مستحيلة، أو استخدام حسابات زبائن حقيقيين وبياناتهم.
الحكم برمز الحالة وحده: فاستجابة 403 ما زال جسمها يحمل الكائن تسريبٌ، و200 لا يخبرك هل حُفظ حقل محظور أم لا؛ فاقرأ الجسم والحالة المخزنة أيضاً.
عدّ معرّفات UUID العشوائية أو نقاط النهاية غير الموثقة حماية: فالمعرّفات تتسرب عبر الروابط والسجلات والاستجابات الأخرى، وكل نقطة نهاية ظاهرة في حركة مرور التطبيق.
تشغيل فحوص المعدل والحجم على الإنتاج أو على بيئة مشتركة، أو دون الاتفاق على الأعداد مع الفريق.
التوقف عند «الماسح لم يجد شيئاً»: الماسح لا يعرف سياسة الوصول لديك، فعيوب BOLA ومستوى الخصائص لا تُكتشف إلا باختبارات مكتوبة منها.
الإبلاغ عن عيب أمني برموز حقيقية أو بيانات شخصية في التذكرة، أو بلا فئة OWASP وخطورة.

من منظور ضمان الجودة

خطط لصفوف الأمان وأنت تصمم اختبارات الواجهة الوظيفية لنقطة نهاية جديدة أو معدّلة، ووثيقة OpenAPI هي أساس الاختبار، وأبقها في حزمة الاختبار نفسها المعتمدة على البيانات لتعمل في خط الأنابيب. اسأل المطور أي الحقول يحتاج إليها كل دور، وأين يُفرض حدّ المعدل وما أرقامه، وأي الإصدارات ما زالت منشورة، وماذا يحدث للرمز بعد تسجيل الخروج؛ واسأل مالك المنتج أي تدفقات الأعمال يجب ألا تُؤتمت؛ وسلّم ما يتجاوز هذا النطاق، كالاستغلال والبنية التحتية، إلى فريق الأمان أو مختبِر اختراق.

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

تمرين عملي

خطط لجولة أمان على واجهة توصيل الطرود

المطلوب

واجهة توصيل طرود في بيئة الاختبار. ينشئ الزبائن الطرود ولا يغيّرون من طرودهم سوى ملاحظات التسليم notes؛ ويرى المندوبون الطرود المسندة إليهم؛ ويخفي العقد الطرود التي لا يحق للمستدعي رؤيتها بـ 404، ويقيّد pageSize بـ 50، ويسمح بعشر محاولات OTP لكل رقم هاتف في الساعة. لديك حسابا الزبونين A وB وحساب المندوب C وإذن كتابي. الطرد 7731 أرسله A وأُسند إلى C.

خطط فحصاً آمناً واحداً لكل خطر في نقاط النهاية الخمس أدناه، ثم احكم على النتائج الثلاث الملاحظة.

المادة

Parcel API, test environment. Parcel 7731: sender A, courier C.

E1  GET    /v1/parcels/{id}            details: address, phone, items, price
E2  GET    /v1/parcels/{id}/label.pdf  shipping label download
E3  POST   /v1/auth/otp/verify         {"phone": "...", "code": "123456"}
E4  PATCH  /v1/parcels/{id}            {"notes": "..."}
E5  GET    /v1/parcels?pageSize=50     the caller's parcels

Observed:
O1  B:  GET /v1/parcels/7731                             -> 404
O2  A:  PATCH /v1/parcels/7731                           -> 200, status DELIVERED
        {"notes": "ring the bell", "status": "DELIVERED"}
O3  POST /v1/auth/otp/verify, 30 wrong codes in 20 s     -> 30 x 400, then 429

الخطوات

لكل نقطة نهاية من E1 إلى E5، سمِّ بنود قائمة OWASP API Security Top 10 التي يجب فحصها؛ وقد ينطبق أكثر من بند.
اكتب فحصاً آمناً واحداً لكل بند: المستدعي، والطلب، والنتيجة المتوقعة.
احكم على O1 إلى O3: صحيح أم عيب، مع بند OWASP والخطورة.
سمِّ فحصاً واحداً يجب ألا تجريه في هذه البيئة دون اتفاق، ولماذا.

إظهار الإجابة النموذجية

الإجابة النموذجية

E1: API1 (رمز B ← 404؛ رمز C ← 200؛ C على طرد غير مسند إليه ← 404) وAPI3 (هل يحتاج المندوب إلى price؟ قارن الحقول الخام بما يحتاج إليه كل دور). E2: API1 مرة أخرى لأن التنزيلات كثيراً ما تتخطى الفحص، وAPI8 إذا عمل رابط الملصق بلا رمز. E3: API2 وAPI4 (الجسم العام نفسه للرمز الخاطئ والهاتف المجهول؛ و429 عند المحاولة الحادية عشرة). E4: API3 (يجب رفض "status" الإضافي أو تجاهله وبقاؤه دون تغيير عند إعادة القراءة) وAPI1 (B على 7731 ← 404 والطرد دون تغيير). E5: API4 (pageSize=50000 ← تقييد عند 50 أو 400) وAPI1 (قائمة B يجب ألا تحتوي على 7731 حتى مع إضافة ?senderId=A).

O1 صحيح. O2 عيب: إسناد جماعي، API3، زبون علّم طرده مسلَّماً؛ رئيسي، وحرج إذا كانت حالة التسليم تحدد مستحقات المندوبين. O3 عيب: يسمح العقد بعشر محاولات لكل هاتف في الساعة والواجهة سمحت بثلاثين؛ API2 وAPI4، رئيسي؛ واسأل أيضاً هل الحدّ لكل رقم هاتف أم لكل عنوان IP، فالحدّ المقتصر على عنوان IP يبدأ من جديد عندما يغيّر العميل عنوانه.

لا يُجرى دون اتفاق: فحوص المعدل والحجم على E3 وE5 بأعداد كبيرة، لأنها تحمّل بيئة مشتركة؛ اتفق مع الفريق على الأعداد والنافذة الزمنية، ولا تشغّلها على الإنتاج أبداً.

أسئلة شائعة

هل هذا هو اختبار الاختراق نفسه؟

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

هل أحتاج إلى ماسح لاختبار أمان الواجهة؟

تكتشف الماسحات سوء التهيئة والترويسات المفقودة والأنماط المعروفة، ويبيّن الدرس التالي موضعها في الاختبار. لكنها لا تستطيع أن تعرف أن الطلبية 9021 ملك للزبون A أو أن المندوب يجب ألا يرى الأسعار، فعيوب BOLA ومستوى الوظيفة ومستوى الخصائص لا تُكتشف إلا باختبارات مكتوبة من السياسة، وهذا ما يعلّمه هذا الدرس.

ما زالت وثائقنا تقول «Excessive Data Exposure» و«Lack of Resources & Rate Limiting». هل هذان الاسمان خاطئان؟

هما اسما إصدار 2019. في إصدار 2023 صار الكشف المفرط عن البيانات والإسناد الجماعي البند API3:2023 كسر التفويض على مستوى خصائص الكائن، وصار نقص الموارد وتحديد المعدل البند API4:2023 الاستهلاك غير المقيّد للموارد. استخدم المعرّفات الحالية في التقارير وأضف الاسم القديم بين قوسين ريثما يعتاد الفريق.

ماذا يجب أن تعيد الواجهة عند بلوغ الحدّ؟

يعرّف RFC 6585 الرمز 429 Too Many Requests ويذكر أن الاستجابة ينبغي أن تشرح الحالة ويجوز أن تتضمن ترويسة Retry-After. و200 يعيد بصمت صفوفاً أقل من المطلوب مقبول لتقييد حجم الصفحة عندما ينص العقد على ذلك؛ أما 500 أو انتهاء المهلة فعيب: الحدّ مفقود أو لا يصمد.

المراجع

OWASP API Security Top 10 (2023)OWASP Foundation · 2023أكثر عشر نقاط ضعف شيوعاً في واجهات API: خلل التفويض على مستوى الكائن، وخلل التوثيق، والاستهلاك غير المقيد للموارد، وغيرها.
OWASP Cheat Sheet Series: REST SecurityOWASP Foundationالقواعد الأمنية لواجهات REST: HTTPS، والتوثيق في كل طلب، والتحقق من المدخلات، واستجابات الخطأ الآمنة، وتحديد المعدل.
RFC 6585: Additional HTTP Status CodesIETF · 2012يعرّف الرموز 428 و429 (طلبات كثيرة جداً) و431 و511، بما فيها ترويسة Retry-After لتحديد المعدل.
RFC 8725: JSON Web Token Best Current PracticesIETF · 2020القواعد الأمنية لتطبيقات JWT: رفض alg=none وتثبيت الخوارزميات والتحقق من iss/aud واستخدام أعمار قصيرة.

اختبار أمان واجهات API

لماذا يهم

قائمة OWASP API Security Top 10 (2023) بوصفها قائمة فحص

BOLA وكسر المصادقة: غيّر الرمز ثم غيّر المعرّف

الكشف المفرط عن البيانات وغياب تحديد المعدل

مثال تطبيقي: جولة أمان على واجهة الخدمة الذاتية لشركة اتصالات

أخطاء شائعة

من منظور ضمان الجودة

تمرين عملي

خطط لجولة أمان على واجهة توصيل الطرود

أسئلة شائعة

المراجع

تدرّب بأدوات متقن

مختبِر مصادقة API

محلّل ترويسة JWT

محلّل مطالبات JWT

محلّل استجابات API

مختبِر REST API

مولّد حالات اختبار من OpenAPI

للتعمّق أكثر

تقدّمك في هذا الموضوع

قبل هذا الموضوع

الموضوعات التالية

موضوعات أخرى في هذه الوحدة

لماذا يهم

قائمة OWASP API Security Top 10 (2023) بوصفها قائمة فحص

BOLA وكسر المصادقة: غيّر الرمز ثم غيّر المعرّف

الكشف المفرط عن البيانات وغياب تحديد المعدل

مثال تطبيقي: جولة أمان على واجهة الخدمة الذاتية لشركة اتصالات

أخطاء شائعة

من منظور ضمان الجودة

تمرين عملي

خطط لجولة أمان على واجهة توصيل الطرود

أسئلة شائعة

المراجع

تدرّب بأدوات متقن

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة

قبل هذا الموضوع

الموضوعات التالية

موضوعات أخرى في هذه الوحدة