أمان الكود المولَّد بالذكاء الاصطناعي: قائمة فحص قبل إطلاق موقعك أو تطبيقك

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

الخلاصة السريعة

• الكود الذي يعمل ليس بالضرورة كوداً آمناً؛ البناء بالذكاء الاصطناعي يُحسّن ما تراه، والثغرات تسكن فيما لا تراه.
• أي مفتاح سري يصل إلى المتصفح يُعدّ مكشوفاً، مهما بدا مخفياً داخل الملفات.
• الصلاحيات تُفحص في الخادم مع كل طلب؛ إخفاء الأزرار ليس حماية.
• حدّث إطار العمل والمكتبات فور صدور الإصدارات الأمنية، كإصدار Next.js الأمني في 25 أغسطس 2026.
• امنح وكلاء الذكاء الاصطناعي وأدوات MCP أقل صلاحية تكفي للمهمة، واشترط موافقة بشرية على العمليات الحساسة.
• إن كان موقعك يجمع بيانات شخصية أو يستقبل مدفوعات، فاختبار الاختراق قبل الإطلاق قرار مسؤول لا رفاهية.

لماذا يحتاج الكود المولَّد بالذكاء الاصطناعي فحصاً أمنياً خاصاً؟

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

ومع انتقال 2026 إلى الوكلاء البرمجيين الذين يعدّلون الملفات وينفّذون الأوامر بأنفسهم، اتسع ما يحتاج إلى مراجعة، وبقي اكتشاف مشكلات الأمان مسؤولية بشرية كما شرحنا في مقال من البرمجة بالوصف إلى الوكلاء البرمجيين.

قائمة الفحص قبل إطلاق موقعك أو تطبيقك

الجدول التالي يجمع أهم ما يجب التحقق منه في موقع أو تطبيق بُني بالذكاء الاصطناعي، مع طريقة تحقق يستطيع صاحب المشروع أو مطوّر مبتدئ تنفيذها.

البند	لماذا يهم	كيف تتحقق
لا مفاتيح سرية في كود الواجهة	كل ما يصل إلى المتصفح يستطيع أي زائر قراءته واستخدامه	ابحث في ملفات الموقع المنشورة عن كلمات مثل key وsecret وtoken
التحقق من الصلاحيات في الخادم	إخفاء الزر لا يمنع إرسال الطلب مباشرة	سجّل الدخول بحساب عادي وجرّب فتح رابط أو واجهة برمجية مخصصة للمدير
عزل بيانات كل مستخدم	تغيير رقم في الرابط قد يكشف بيانات عميل آخر	افتح طلباً أو فاتورة بحسابين مختلفين وبدّل المعرّف في الرابط
التحقق من المدخلات وترميز المخرجات	يمنع تحوّل نص المستخدم إلى سكربت ينفَّذ عند غيره (XSS)	أدخل نصاً فيه رموز HTML في الحقول، وتأكد أنه يظهر نصاً عادياً
استعلامات مُعلَمة لقاعدة البيانات	تمنع حقن SQL	راجع الكود بحثاً عن استعلامات تُبنى بدمج نصوص المستخدم
مكتبات محدَّثة وموثوقة	ثغرات الإطار والحزم تُصلَح في إصدارات أمنية	شغّل أداة تدقيق الحزم وراجع كل حزمة جديدة
رفع ملفات مقيّد	ملف ضار قد يُنفَّذ أو يستنزف الخادم	جرّب رفع نوع غير مسموح وحجم كبير، وتأكد من الرفض
حدود لعدد الطلبات	تحمي تسجيل الدخول والنماذج من التخمين والإغراق	أرسل محاولات دخول متتالية سريعة وتأكد من ظهور منع مؤقت
HTTPS وترويسات الأمان	تحمي الاتصال وتحدّ من أثر XSS والتضمين الخبيث	افحص ترويسات الاستجابة في أدوات المطوّر
سجلات بلا أسرار	تحتاجها للتحقيق في أي حادث، لكنها قد تسرّب بيانات	راجع عينة من السجلات بحثاً عن كلمات مرور أو رموز دخول
نسخ احتياطية مُجرَّبة	النسخة التي لم تُسترجع قط ليست ضماناً	استرجع نسخة فعلياً في بيئة منفصلة
صلاحيات الوكلاء وأدوات MCP	وكيل بصلاحيات واسعة يضاعف أثر أي خطأ أو تلاعب	اسرد كل أداة متصلة وصلاحياتها، واحذف غير اللازم
الالتزام بنظام حماية البيانات الشخصية	النظام نافذ بالكامل منذ سبتمبر 2024	راجع ما تجمعه وسببه وسياسة الخصوصية

ولتنظيم العمل اتبع هذا الترتيب، فهو يبدأ بما يسبب أكبر ضرر إن تُرك:

1. أزل الأسرار المكشوفة وألغِ أي مفتاح سري ظهر في الواجهة.
2. افحص الصلاحيات وعزل البيانات بحسابين مختلفين.
3. راجع المدخلات والاستعلامات ورفع الملفات.
4. حدّث الإطار والمكتبات.
5. فعّل HTTPS وترويسات الأمان وحدود الطلبات.
6. جهّز السجلات والنسخ الاحتياطية وجرّب الاسترجاع.
7. راجع التزامات البيانات الشخصية، ثم قرّر هل تحتاج اختبار اختراق.

الأسرار والمصادقة والصلاحيات: أين تقع أخطر الأخطاء؟

من أخطر ما قد يتسلل إلى مشروع مولَّد بالذكاء الاصطناعي خطآن: سرّ وُضع في كود الواجهة، وصلاحية فُحصت في الواجهة بدل الخادم.

المفاتيح السرية في كود الواجهة

حين تطلب من المساعد «اربط الموقع بخدمة الرسائل» أو «أضف الدفع»، قد يضع مفتاح الخدمة مباشرة في ملف JavaScript يُرسل إلى المتصفح، فيستطيع أي زائر قراءته واستخدامه على حسابك. القاعدة: المفاتيح السرية تبقى في الخادم ومتغيرات البيئة، والواجهة تستدعي خادمك، وخادمك يستدعي الخدمة. وأي مفتاح سري ظهر في الواجهة أو في مستودع عام يُعدّ محروقاً: ألغه وأصدر بديلاً. أما المفاتيح العامة (publishable) المصمَّمة للواجهة فمسموحة، بشرط أن تكون صلاحياتها محدودة كما تحددها الخدمة. وينطبق هذا بشدة على مفاتيح الدفع، فراجع دليل بوابات الدفع في السعودية قبل ربط أي بوابة بموقعك.

المصادقة والصلاحيات

المصادقة تجيب عن سؤال «من أنت؟»، والصلاحيات تجيب عن «ماذا يحق لك أن تفعل؟». الخطأ الذي يجب أن تبحث عنه أن تُخفي الواجهة زر «حذف المستخدم» عن غير المدير، بينما يقبل الخادم طلب الحذف من أي مستخدم مسجّل. فكل طلب يجب أن يتحقق فيه الخادم من هوية المرسل وصلاحيته على هذا المورد تحديداً.

وانتبه لعزل البيانات: إن كان رابط الفاتورة ينتهي برقم، فجرّب تغييره وأنت مسجّل بحساب آخر. إن ظهرت فاتورة عميل غيرك، فالتطبيق يتحقق من تسجيل الدخول لا من الملكية. وتأكد كذلك أن كلمات المرور تُخزَّن بخوارزمية تجزئة مخصصة مثل bcrypt أو Argon2، وأن الجلسات تنتهي صلاحيتها.

المدخلات: XSS وحقن SQL ورفع الملفات

كل ما يُدخله المستخدم يُعامل بوصفه بيانات غير موثوقة: يُتحقق منه في الخادم، ويُرمَّز عند عرضه، ويُمرَّر إلى قاعدة البيانات عبر معاملات لا عبر دمج النصوص.

XSS: حين يتحول نص المستخدم إلى كود

تحدث ثغرة XSS حين يُعرض نص أدخله مستخدم داخل الصفحة بطريقة تسمح للمتصفح بتنفيذه سكربتاً، فيصل إلى جلسات زوار آخرين. تُرمّز React النصوص تلقائياً عند عرضها، لكن هذه الحماية تسقط حين يُدرج الكود HTML خاماً عبر dangerouslySetInnerHTML أو innerHTML. ابحث عن هذه المواضع، وإن احتجت إليها فمرّر المحتوى عبر مكتبة تنقية موثوقة. ومن الجديد أن React 19.3.0 الصادر في 9 سبتمبر 2026 أضاف دعم Trusted Types، وهي آلية دفاع في المتصفح ضد ثغرات XSS القائمة على DOM.

حقن SQL: الاستعلامات المُعلَمة

يحدث حقن SQL حين يُبنى الاستعلام بدمج نص المستخدم داخله مباشرة. والحل المعروف هو الاستعلامات المُعلَمة، إذ يُرسل الاستعلام والقيم منفصلين فلا تُفسَّر القيمة جزءاً من الأمر. مثال آمن بمكتبة pg في Node.js:

const result = await pool.query(
  'SELECT id, name FROM customers WHERE email = $1',
  [email]
);

وإن كان مشروعك يستخدم ORM، فالمواضع التي تحتاج مراجعة هي تلك التي يلجأ فيها الكود إلى استعلامات خام.

رفع الملفات

ميزة رفع الملفات تحتاج قيوداً صريحة: أنواع مسموحة يتحقق منها الخادم من محتوى الملف لا من امتداد اسمه، وحد أقصى للحجم، وأسماء يولّدها الخادم، وتخزين خارج المسارات التي قد يُنفَّذ منها كود.

المكتبات وسلسلة الإمداد وصلاحيات الوكلاء

الكود الذي كتبه الذكاء الاصطناعي جزء من مشروعك فقط؛ فالمكتبات والإطار والأدوات المتصلة بالوكيل تحتاج مراجعة أيضاً.

نظافة الحزم

راجع كل حزمة أضافها المساعد: هل هي موجودة فعلاً؟ هل اسمها مطابق للحزمة المعروفة لا مشابه لها بحرف؟ هل ما زالت تُصان؟ فالنماذج قد تقترح أسماء حزم غير موجودة أو قريبة من أسماء معروفة، وقد يستغل ذلك من ينشر حزمة ضارة بالاسم نفسه. ثبّت الإصدارات بملف القفل، وشغّل أداة تدقيق مثل npm audit.

تحديثات الإطار الأمنية

مثال حديث: في 25 أغسطس 2026 أصدر فريق Next.js تحديثاً أمنياً أصلح ثغرتين مصنّفتين حرجتين، في الإصدار 16.3.3 من خط الدعم طويل الأمد النشط، والإصدار 15.5.24 من خط دعم الصيانة. إن كان موقعك مبنياً على Next.js، فتأكد أن الإصدار المنشور فعلاً لا يقل عن 16.3.3 أو 15.5.24، وإن كان على خطٍّ أقدم (مثل 13 أو 14) فلا يوجد إصدار مُرقَّع له، والحل هو الترقية إلى 15.5.24 أو 16.3.3. ولماذا يهم هذا صاحب المنشأة لا المطوّر وحده، فصّلناه في دليل Next.js 16.3 وReact 19.3 لأصحاب الأعمال.

حقن التعليمات وأدوات MCP

حين يقرأ وكيل الذكاء الاصطناعي صفحة ويب أو ملفاً أو رسالة، قد يحتوي المحتوى على تعليمات مدسوسة تحاول توجيهه لفعل ما لم تطلبه، وهذا ما يُعرف بحقن التعليمات. والدفاع الأساسي ألا يملك الوكيل صلاحيات تجعل هذا التلاعب مؤذياً. بروتوكول MCP معيار مفتوح لربط الوكلاء بالأدوات والبيانات، وقد نشرت وكالة الأمن القومي الأمريكية في مايو 2026 إرشادات أمنية خاصة به، وخوادم MCP العامة تتفاوت كثيراً في مستوى أمانها وليس كلها يعتمد مصادقة قوية مثل OAuth، فعامل أي خادم خارجي بوصفه غير موثوق حتى تتحقق منه (التفاصيل في مقال بروتوكول MCP ووكلاء الذكاء الاصطناعي في 2026). لذلك:

• اسرد كل خادم MCP أو أداة متصلة بالوكيل، واحذف ما لا تحتاجه.
• امنح كل أداة أقل صلاحية تكفي، كالقراءة فقط حيث تكفي القراءة.
• لا تربط الوكيل مباشرة بقاعدة بيانات الإنتاج أو بمفاتيح الدفع.
• اشترط موافقة بشرية قبل أي حذف أو نشر أو دفع.

البنية التشغيلية: HTTPS والترويسات وحدود الطلبات والسجلات والنسخ الاحتياطية

البنية التشغيلية هي ما يحمي موقعك حين يخطئ الكود أو يُهاجَم، وتشمل التشفير والترويسات والحدود والسجلات والنسخ.

• HTTPS: لا تُطلق موقعاً بلا شهادة SSL، وحوّل كل طلبات HTTP إلى HTTPS. وعند النشر بنقرة واحدة عبر مبرمج تحصل على شهادة SSL مجانية، ويمكنك أيضاً النشر على نطاقك الخاص.
• ترويسات الأمان: أضف Strict-Transport-Security وContent-Security-Policy وX-Content-Type-Options، وقيّد تضمين صفحاتك داخل إطارات مواقع أخرى، وابدأ سياسة CSP في وضع التقرير ثم شدّدها تدريجياً.
• حدود الطلبات: على تسجيل الدخول واستعادة كلمة المرور والنماذج، وأي واجهة تستدعي خدمة مدفوعة كنماذج الذكاء الاصطناعي.
• السجلات: سجّل محاولات الدخول الفاشلة وتغييرات الصلاحيات والعمليات الحساسة، دون كلمات المرور أو أرقام البطاقات. وحدّد أدوار الفريق بوضوح؛ ففي مبرمج مثلاً أدوار مشاهد ومحرر ومدير مع سجل نشاط.
• النسخ الاحتياطية: نسخ دورية لقاعدة البيانات والملفات المرفوعة، ونسخة خارج الخادم نفسه، وتجربة استرجاع فعلية قبل أن تحتاج إليها.

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

البيانات الشخصية: التزاماتك وفق نظام حماية البيانات الشخصية

إن كان موقعك يعالج بيانات شخصية في السعودية، كالأسماء وأرقام الجوال والعناوين، فأنت معنيّ بنظام حماية البيانات الشخصية النافذ بالكامل منذ سبتمبر 2024، وكون الكود مولَّداً بالذكاء الاصطناعي لا يغيّر شيئاً من مسؤوليتك. وعلى المستوى العملي قبل الإطلاق:

• اجمع الحد الأدنى: راجع كل حقل في كل نموذج واسأل: هل نحتاجه فعلاً؟ فالمساعد قد يضيف حقولاً لم تطلبها.
• وضّح الغرض: سياسة خصوصية واضحة بالعربية تبيّن ما تجمعه ولماذا ومع من تشاركه.
• احترم حقوق أصحاب البيانات: جهّز طريقة للاطلاع على البيانات وتصحيحها وطلب إتلافها.
• اعرف مسار بياناتك: أين تُخزَّن، وأي خدمات خارجية تصل إليها.
• جهّز خطة للتسرب: من يُبلَّغ وكيف، وفق ما يفرضه النظام ولوائحه.

هذه نقاط تشغيلية لا استشارة قانونية؛ ارجع إلى النص الرسمي للنظام ولوائحه أو إلى مستشار مختص.

متى تشتري اختبار اختراق؟

اشترِ اختبار اختراق حين يكون ضرر الثغرة أكبر من كلفة الاختبار: قبل إطلاق منصة تستقبل مدفوعات أو تحفظ بيانات شخصية، وبعد أي تغيير كبير في المصادقة أو الصلاحيات، وحين يشترطه عميل أو عقد.

قائمة الفحص تكشف الأخطاء الواضحة، لكنها لا تحاكي مهاجماً يربط ثغرتين صغيرتين ليصل إلى ما لا تصل إليه كل منهما وحدها. وهنا يفيد التمييز بين خدمتين:

• تقييم الثغرات: فحص منهجي يحدد نقاط الضعف ويرتبها حسب خطورتها، ويناسب التكرار الدوري.
• اختبار الاختراق: محاولة منظمة ومأذونة لاستغلال الثغرات كما يفعل مهاجم، مع تقرير بطريقة الإصلاح، ويناسب ما قبل الإطلاق وما بعد التغييرات الجوهرية.

وبعد الإطلاق، تكشف المراقبة والاستجابة للحوادث المشكلة مبكراً بدل أن يخبرك بها عميل. وتقدّم الشركة التي تطوّر مبرمج هذه الخدمات ضمن خدمات الأمن السيبراني: اختبار الاختراق، وتقييم الثغرات، والمراقبة والاستجابة للحوادث.

الأسئلة الشائعة

هل الكود الذي يولّده الذكاء الاصطناعي أقل أماناً من كود المطوّرين؟

ليس بالضرورة، فالمطوّرون قد يقعون في الأخطاء نفسها. الفرق أن البناء بالذكاء الاصطناعي سريع ويُراجَع كثيراً بالعين، فقد تمر الثغرات غير المرئية دون انتباه. والمعيار واحد في الحالتين: مراجعة وفحص قبل الإطلاق.

هل إخفاء الأزرار عن المستخدمين يكفي لحماية لوحة الإدارة؟

لا. أي مستخدم يستطيع إرسال الطلب إلى الخادم مباشرة دون الضغط على الزر. يجب أن يتحقق الخادم من هوية المرسل وصلاحيته مع كل طلب، أما إخفاء الزر فتحسين لتجربة الاستخدام فقط.

ماذا أفعل إذا اكتشفت مفتاح API مكشوفاً في موقعي؟

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

هل يلزمني نظام حماية البيانات الشخصية إذا كان موقعي صغيراً؟

لا تفترض أن صغر الموقع يعفيك؛ السؤال الأول هو: هل تعالج بيانات شخصية؟ إن كان موقعك يجمع أسماء أو أرقام جوال أو عناوين، فراجع التزاماتك وفق النظام النافذ بالكامل منذ سبتمبر 2024، واستشر مختصاً عند الشك.

هل أحتاج اختبار اختراق لصفحة هبوط بسيطة؟

في الغالب لا، إن كانت الصفحة ثابتة ونموذج التواصل لا يجمع إلا الحد الأدنى من البيانات. يكفي تطبيق قائمة الفحص: HTTPS، وحدود للطلبات على النموذج، وخلو الكود من المفاتيح، وحماية بيانات النموذج وفق نظام حماية البيانات الشخصية. أما إن كانت تستقبل مدفوعات أو تحفظ بيانات عملاء، فيصبح اختبار الاختراق مبرراً.

ابدأ الآن

ابدأ بتطبيق الجدول أعلاه على مشروعك بنداً بنداً، وأصلح ما تجده قبل الإطلاق لا بعده. وإن كان مشروعك يتعامل مع مدفوعات أو بيانات حساسة وتريد رأياً مستقلاً، فيمكنك طلب تقييم ثغرات أو اختبار اختراق عبر خدمات الأمن السيبراني.