تكامل واجهات البرمجة (API) والأنظمة الخارجية

الملخص المرئي بالإنجليزية؛ والنص الكامل بالعربية أدناه.

التحدي

كانت لدى منصة ERP متعددة المستأجرين (Multi-tenant) مشكلتان:

يمكن الوصول إلى قواعد بيانات المستأجرين من مستأجر آخر عبر نقاط RPC.
الواجهة الداخلية بين لوحة التحكم المركزية وكل مستأجر بلا حماية من إعادة الإرسال (Replay) ولا تحقق من محتوى الطلب، فيمكن إعادة إرسال أي طلب تم التقاطه.

كتبت أداة اختبار هجومي (Attack Harness) أولاً: قاعدة بيانات حقيقية وخادم HTTP حقيقي، وكل اختبار يحاول ثغرة واحدة.
شغّلتها على الكود الأصلي لإثبات وجود كل ثغرة (18 حالة فشل)، وبعدها فقط عدّلت الكود.

بروتوكول وكيل موقّع (الإصدار الثاني): توقيع HMAC-SHA256 على بصمة المحتوى والطابع الزمني، ونافذة سماح للفارق الزمني، وحماية من إعادة الإرسال عبر Nonce، والتحقق من المحتوى، والمنع الافتراضي (Default-deny) للصلاحيات.
سياسة ربط النطاق بقاعدة البيانات مطبّقة على خدمات RPC وعلى قائمة قواعد البيانات للمهام المجدولة (Cron)، فلا يصل طلب مستأجر إلى قاعدة بيانات مستأجر آخر.
مفاتيح REST API مخزّنة كبصمات SHA-256 ومقارنة بـ hmac.compare_digest، مع حدود لمعدل الطلبات.

ساهمت في تطوير تكامل للفوترة الإلكترونية وتكامل مع بوابات الدفع، وهذه الأنماط مأخوذة من ذلك العمل:

طابور مهام صادر: يُعالَج عبر مهمة مجدولة، مع مفاتيح عدم التكرار (Idempotency Keys) وإعادة محاولة متدرّجة بعد 1 و5 و15 و60 دقيقة. يُعاد فقط ما يقبل الإعادة (أخطاء الشبكة وحدود المعدل)؛ أما أخطاء الإعداد فتفشل فوراً.
انضباط عميل HTTP: التحقق من شهادات TLS، ومهلات زمنية، ومعرّف تتبع (Correlation ID)، وسجل لطلبات الـ API، ومعالجة منفصلة لأخطاء 429 و5xx.
إشعارات الدفع (Webhooks): مقارنة السر بزمن ثابت، وعدم الوثوق بمحتوى الإشعار بل إعادة قراءة حالة الدفع من واجهة المزوّد، وقفل الصف FOR UPDATE NOWAIT لمنع التسابق بين الإشعار وصفحة العودة.

الكود الأصلي: 18 حالة فشل. بعد الإصلاح: 27/27 اختباراً ناجحاً في أداة الاختبار الهجومي، و79/79 في حزمة اختبارات المنصة.
ما لا ندّعيه: إطلاق هذه المنصة في بيئة الإنتاج غير موثّق في الأدلة. وتكاملا الفوترة الإلكترونية وبوابات الدفع عمل جماعي؛ كنت مساهماً فيهما ولست المؤلف الوحيد.