الرقم في العنوان سيناريو توضيحي، مش نتيجة شخصية ولا إنجازًا اتقاس. لكن السؤال مهم: لو مساعد ذكاء اصطناعي ولّد تغييرًا كبيرًا بسرعة، إيه الدليل اللي يخلّيك تثق فيه؟
الإجابة مش عدد الأسطر أو الملفات أو المرات اللي البرومبت نجح فيها. الثقة بتيجي من فهم التغيير، واختبار الحدود المهمة، ومراقبة سلوك النظام في ظروف قريبة من الواقع. الكود المولّد محتاج نفس المراجعة الهندسية اللي بنعملها للكود المكتوب يدويًا.
الكود اللي بيشتغل مش بالضرورة جاهز للإنتاج
«اشتغل» غالبًا معناها إن المسار المتوقع نجح مرة. لكن الميزة في الإنتاج لازم تتصرف صح كمان مع المستخدم الغلط، والطلب المتكرر، والطلبات المتزامنة، والبيانات الناقصة، والخدمة البطيئة، والفشل الجزئي.
ممكن endpoint يرد بالنتيجة المتوقعة، لكنه يكشف سجلّ عميل تاني. وممكن الدفع ينجح في العرض، ثم يتخصم مرتين لما الشبكة تعيد الطلب. وممكن شاشة الحجز تعرض مكانًا واحدًا، بينما شخصان يحجزانه في اللحظة نفسها.
جاهزية الإنتاج صفة للمسار كله: الواجهة، والـAPI، والصلاحيات، وقيود قاعدة البيانات، وإعادة المحاولة، والسجلات، والنشر والاستعادة. نجاح اختبار للمسار السليم دليل مفيد، لكنه لا يقول شيئًا عن حالة لم يختبرها.
BOLA / IDOR: تغيير المعرّف لا ينبغي أن يغيّر صاحب البيانات
ثغرة Broken Object Level Authorization، أو IDOR كما تُسمّى كثيرًا، بتحصل لما الطلب يحدد سجلًا لكن الخادم مايتأكدش إن المستخدم الحالي مسموح له يتعامل معاه. عنوان مثل /api/invoices/105 مش محمي لمجرد إن المستخدم سجّل الدخول. لو تغيير 105 إلى 106 رجّع فاتورة شخص آخر، يبقى حدّ الصلاحيات ناقص.
الفحص الآمن مكانه الخادم، ويجمع هوية المستخدم الموثوقة مع السجل المطلوب. مثلًا، الاستعلام عن الفاتورة يشترط رقمها ومالكها أو المؤسسة المسموح بها. إخفاء الزر، أو استخدام رقم صعب التخمين، أو تصفية البيانات في المتصفح مش قواعد صلاحيات.
راجع كل معرّف ممكن يوصل من رابط أو نموذج أو مهمة خلفية أو أداة ذكاء اصطناعي. اسأل: هوية مين اللي بتُستخدم؟ إيه العلاقة اللي تسمح بالوصول؟ وإيه اللي يحصل لو السجل موجود لكنه ملك شخص تاني؟ OWASP بتصنّف ده ضمن API1:2023، وبتوصي بفحص صلاحية الوصول لكل كائن يُقرأ أو يتغير باستخدام معرّف.
سباق التزامن: طلبان صحيحان ممكن ينتج عنهما وضع مستحيل
تخيّل إن فيه موعد واحد فاضي. طلبان قرأوا remaining = 1، وكل واحد قرر إن الحجز متاح، وبعدها الاتنين سجّلوا الحجز. كل طلب كان صحيحًا لوحده، لكن النتيجة النهائية مستحيلة.
الحماية لازم تكون ذرّية عند نقطة تغيير الحالة المشتركة. حسب نموذج البيانات، ده ممكن يكون تحديثًا مشروطًا، أو قيدًا في قاعدة البيانات، أو معاملة بمستوى عزل مناسب، أو قفلًا. بعد كده اختبر طلبين في نفس الوقت وتأكد إن واحدًا بس ينجح. الاختبار المتتابع مايثبتش إن السباق اتقفل.
النمط نفسه يظهر في المخزون، وحجز المقاعد، والكوبونات، والأرصدة، وتسليم الواجبات. حدّد القاعدة اللي لازم تفضل صحيحة، وطبّقها عند نقطة التقاء الطلبات المتزامنة، مش في الواجهة بس.
Idempotency: إعادة المحاولة ما تكرّرش أثرًا حقيقيًا
إعادة المحاولة شيء طبيعي. المتصفح ممكن يعيد الطلب بعد انتهاء المهلة، ومزوّد الدفع ممكن يكرر webhook، والطابور ممكن يسلّم الرسالة مرتين. لو كل مرة بتنشئ خصمًا أو طلبًا أو رسالة جديدة، فالنظام اعتبر الإعادة نية جديدة.
استخدم مفتاحًا ثابتًا للعملية أو معرّف الحدث، واحفظه مع قيد يمنع التكرار، ونفّذ الأثر الجانبي مرة واحدة. احتفظ بالنتيجة بحيث إعادة المحاولة ترجع النتيجة الأصلية. لازم كمان يكون للمفتاح نطاق واضح للمستخدم أو العملية ومدة احتفاظ مقصودة.
توثيق Stripe مثال محدد على استخدام مفاتيح idempotency في واجهات API. والمبدأ نفسه ينطبق على webhooks والمهام الخلفية الخاصة بك، لكن التفاصيل تعتمد على الأثر الذي يجب أن يحدث مرة واحدة وما الذي يمكن تكراره بأمان.
الحالات الطرفية والدين التقني جزء من الميزة
الكود المولّد غالبًا يتبع الطريق الواضح في الطلب. ممكن يفوته ما يحدث لما سجل يُحذف أثناء عملية، أو القائمة تبقى فارغة، أو البيانات تبقى قديمة، أو الطلب ينتهي بعد ما الخادم حفظ التغيير، أو تحديثان يوصلوا بترتيب مختلف.
الدين التقني مش دليل إن الميزة بايظة. هو تكلفة مستقبلية ناتجة عن اختصار أو قيد لم يُحل. سجّل القرار وأثره والشرط اللي يخلي حلّه أولوية. ماتدفنوش تحت تعليق «TODO» غامض أو تفترض إن الذكاء الاصطناعي هيفتكره بعدين.
لكل تغيير، اكتب القاعدة التي يجب أن تظل صحيحة، وسلوك الفشل، وطريقة الاستعادة. اختبر أعلى الحالات خطورة: مالك غير مصرح له، طلب مكرر، تحديث متزامن، سجل مفقود، انتقال حالة غير صالح، وفشل خدمة خارجية.
مراجعة الأمان: افحص الصلاحيات والمدخلات والآثار الجانبية
مشاكل الأمان كثيرًا ما تكون أخطاء منطقية عادية عند حدود النظام. تأكد إن الخادم يستخرج الهوية من جلسة موثوقة، ويتحقق من كل مدخل، ويحدّ ما يستطيع المستخدم قراءته أو تغييره، ولا يكشف الأسرار أو تفاصيل الخطأ الداخلية. راجع عمليات الإدارة وتغيير الأدوار بشكل مستقل عن صلاحيات القراءة.
في ميزات الذكاء الاصطناعي، راجع الأدوات التي يستطيع النموذج استدعاءها، وصلاحية المستخدم التي تعمل بها كل أداة، والبيانات التي تدخل إلى السياق، وهل تحتاج الإجراءات المقترحة إلى تأكيد، وما الذي يُسجّل أو يُحتفظ به. تعليمات النموذج ليست فحص صلاحيات. التطبيق نفسه لازم يفرضها داخل تنفيذ الأداة.
استخدم تنبيهات المكتبات والتحليل الساكن كنقاط بداية، مش بديلًا عن فهم مسار الكود. الفاحص ممكن يحدد مكتبة معروفة بثغرة؛ لكن على المراجع أن يحدد هل المسار المتأثر قابلًا للوصول وكيف يُستخدم.
قائمة مراجعة قبل إطلاق كود مولّد بالذكاء الاصطناعي
- اقرأ التغيير كاملًا واشرح كل مسار تغيّر من غير الاعتماد على نص البرومبت.
- حدّد حدود البيانات والصلاحيات لكل endpoint وأداة.
- اختبر معرّف سجل لا يملكه المستخدم، مش مثالًا مصرحًا فقط.
- جرّب الطلبات المكررة والتحديثات المتزامنة والفشل الجزئي.
- راجع قيود قاعدة البيانات والمعاملات للقواعد المهمة.
- افحص التحقق من البيانات، والحالات الفارغة والقديمة، والمهل الزمنية والاستعادة.
- راجع الأسرار والسجلات والوصول للملفات وتنبيهات المكتبات والاتصالات الخارجية.
- شغّل فحوص الأنواع والاختبارات وبناء الإنتاج، وافهم ما لا تغطيه.
- احتفظ بقائمة قصيرة للقيود المقبولة والدليل الذي قد يغيّر القرار.
حدود المراجعة
مافيش قائمة تثبت إن النظام آمن أو خالٍ من العيوب. الاختبارات تغطي سيناريوهات مختارة، والمراجعات ممكن تفوّت افتراضات، وسلوك الإنتاج يعتمد على البيانات والضغط والإعدادات. الهدف إننا نستبدل «الذكاء الاصطناعي قال خلص» بأدلة تناسب خطورة التغيير.
الكود المولّد ممكن يسرّع الشغل. لكن مسؤولية تحديد ما يُسمح له بفعله، وفحص الحدود، وتحمل نتيجة تشغيله تظل مسؤولية الفريق.