• منتديات شباب الرافدين .. تجمع عراقي يقدم محتوى مميز لجميع طلبة وشباب العراق .. لذا ندعوكم للانضمام الى اسرتنا والمشاركة والدعم وتبادل الافكار والرؤى والمعلومات. فأهلاَ وسهلاَ بكم.
10 ثغرات أمنية قد يضعها الذكاء الاصطناعي في كود مشروعك وكيف تكتشفها

10 ثغرات أمنية قد يضعها الذكاء الاصطناعي في كود مشروعك وكيف تكتشفها

Ibn AliraQ

Ibn AliraQ

ヅ واحد من الناس ヅ
السمعة: 100%
النقاط 297
الحلول 0
إنضم
2018-08-28
المشاركات
17,598
مستوى التفاعل
6,957
النقاط
297
الإقامة
العراق
Ibn AliraQ
أخطر ثغرات الكود المولد بالذكاء الاصطناعي - دليل المراجعة الأمنية قبل نشر تطبيقك
قد يكتب لك الذكاء الاصطناعي تطبيقًا يعمل بصورة تبدو مثالية. يستطيع إنشاء واجهة تسجيل دخول، وربط قاعدة البيانات، وبناء واجهات API، وإضافة رفع الملفات والدفع الإلكتروني خلال وقت قصير. لكن نجاح التطبيق في التشغيل لا يعني بالضرورة أنه آمن.

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

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

محرر كود بالذكاء الاصطناعي محاط بتحذيرات من ثغرات أمنية خفية​

أظهرت دراسة بحثية نُشرت عام 2025 حول أمان الكود الذي يولده ChatGPT أن النموذج استطاع اكتشاف وإصلاح بعض الثغرات، لكنه أخفق في اكتشاف ثغرات أخرى، بل إن عددًا من المشكلات المؤكدة في العينة كان قد أُدخل بواسطة النموذج نفسه. لا يعني ذلك أن عليك التوقف عن استخدام الذكاء الاصطناعي، بل يعني أن السرعة يجب أن تتبعها مراجعة واختبارات أمنية حقيقية.

لماذا ينتج الذكاء الاصطناعي كودًا يعمل لكنه غير آمن؟​

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

ملخص أهم الثغرات التي يجب فحصها​

الثغرةالخطر الأساسيأول شيء يجب فحصه
حقن SQLقراءة البيانات أو تعديلهاالاستعلامات المجمعة بالنصوص
BOLA أو IDORالوصول إلى سجلات مستخدمين آخرينالتحقق من ملكية السجل
غياب تحديد المعدلالتخمين الآلي وإغراق الخدمةنقاط تسجيل الدخول والاستعادة
استعادة كلمة المرور غير الآمنةالاستيلاء على الحسابصلاحية الرمز واستخدامه مرة واحدة
إعداد JWT السيئسرقة الجلسة أو إعادة استخدام الرمزالتوقيع والانتهاء والإلغاء
Mass Assignmentترقية الصلاحيات أو تعديل حقول حساسةربط الطلب مباشرة بنموذج البيانات
XSSتنفيذ JavaScript داخل متصفح الضحيةعرض محتوى غير موثوق كـ HTML
الأسرار المضمنة في الكودتسريب الحسابات والخدمات السحابيةمفاتيح API داخل المستودع
تسجيل البيانات الحساسةتسريب الرموز والبيانات عبر السجلاتمحتوى رسائل الخطأ وملفات Logs
رفع الملفات غير الآمنرفع برمجيات خبيثة أو استنزاف الخادمالنوع والحجم ومكان التخزين

خريطة تصنف مخاطر الكود المولد بالذكاء الاصطناعي حسب تأثيرها الأمني​

1. حقن SQL وفصل البيانات عن الاستعلامات​

تظهر ثغرة حقن SQL عندما تُدمج مدخلات المستخدم مباشرة داخل الاستعلام. تخيل أن التطبيق ينشئ استعلامًا بالاعتماد على قيمة قادمة من مربع البحث أو عنوان URL:
كود: 
SELECT * FROM users WHERE name = 'مدخل المستخدم'
إذا جمع الكود النص الذي أدخله المستخدم مع الاستعلام، فقد يستطيع المهاجم تغيير معنى الاستعلام، وليس مجرد البحث عن اسم.

الحل الأساسي هو استخدام الاستعلامات المعلّمة أو Parameterized Queries، بحيث يتعامل محرك قاعدة البيانات مع المدخل باعتباره قيمة، لا جزءًا من تعليمات SQL.
استخدام ORM مثل Entity Framework أو Hibernate أو Prisma يقلل فرص الوقوع في الخطأ، لكنه لا يمنع الثغرة تلقائيًا. قد يعود الخطر إذا أنشأ المطور استعلامات ديناميكية أو دمج النصوص يدويًا داخل ORM.
وفق تصنيف OWASP للحقن لعام 2025، يجب فصل البيانات عن الأوامر والاستعلامات، مع استخدام التحقق من المدخلات واختبارات الكود الآلية واليدوية.

ابحث داخل الكود المولد عن:
  • جمع النصوص داخل استعلام SQL.
  • استخدام مدخل المستخدم داخل أوامر نظام التشغيل.
  • الاستعلامات الخام Raw Queries.
  • استخدام Execute أو Eval مع قيم خارجية.
  • استعلامات ORM التي تتكون من سلاسل نصية ديناميكية.

2. الوصول غير المصرح إلى السجلات BOLA أو IDOR​

لنفترض أن لديك الرابط التالي:
كود: 
/api/orders/100
قد يكون المستخدم مسجلًا في حسابه ويحق له مشاهدة الطلب رقم 100. لكن ماذا يحدث إذا غيّر الرقم إلى 101؟
إذا جلب الخادم الطلب اعتمادًا على المعرف فقط، دون التأكد من أنه يخص المستخدم الحالي، فقد يستطيع أي مستخدم مشاهدة طلبات الآخرين بتغيير الرقم.
تسمى هذه المشكلة في تطبيقات الويب غالبًا Insecure Direct Object Reference، بينما يستخدم تصنيف OWASP لواجهات API مصطلح Broken Object Level Authorization.
الفحص الصحيح لا يكون في الواجهة الأمامية فقط. إخفاء زر أو صفحة لا يمنع المهاجم من إرسال طلب HTTP مباشر. يجب على الخادم التحقق من ملكية السجل أو صلاحية المستخدم في كل عملية قراءة أو تعديل أو حذف.

بدل البحث عن الطلب بالمعرف وحده، ينبغي أن يربطه الاستعلام بالمستخدم الحالي، مثل:
كود: 
ابحث عن الطلب حيث: رقم الطلب = الرقم المطلوب والمستخدم المالك = المستخدم المسجل حاليًا
تضع OWASP التحكم المكسور في الوصول في المرتبة الأولى ضمن قائمة مخاطر تطبيقات الويب لعام 2025، لأن نتيجته قد تشمل كشف البيانات أو تعديلها أو حذفها أو رفع الصلاحيات.

مقارنة بين API غير آمنة وAPI تتحقق من ملكية المستخدم للسجل​

3. غياب تحديد معدل الطلبات Rate Limiting​

يساعد Rate Limiting على تقليل قدرة المهاجم على إرسال عدد ضخم من الطلبات خلال مدة قصيرة. ويكون مهمًا خصوصًا في:
  • تسجيل الدخول.
  • إرسال رموز التحقق.
  • استعادة كلمة المرور.
  • إنشاء الحسابات.
  • البحث المكلف.
  • رفع الملفات.
  • واجهات API المدفوعة أو التي تستهلك موارد كبيرة.
من الأخطاء الشائعة أن ينشئ الذكاء الاصطناعي نقطة تسجيل دخول تعمل، لكنه لا يضيف أي قيود على عدد المحاولات. عندها يمكن تشغيل أدوات آلية لتجربة كلمات مرور كثيرة أو استخدام بيانات مسربة من خدمات أخرى.
لكن Rate Limiting ليس حلًا منفردًا. ينبغي دمجه مع كلمات مرور قوية، والمصادقة متعددة العوامل، ومراقبة السلوك غير المعتاد، ومنع استخدام كلمات المرور المخترقة، وتنبيهات الأمان.
كما لا توجد قيمة واحدة تناسب جميع الواجهات. قد تحتاج نقطة تسجيل الدخول إلى سياسة مختلفة عن صفحة عامة أو API داخلية. ويمكن تطبيق الحدود بناءً على الحساب أو عنوان IP أو الجلسة أو مفتاح API أو مزيج منها، مع الانتباه إلى المستخدمين الذين يشتركون في شبكة واحدة.

4. استعادة كلمة المرور بطريقة غير آمنة​

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

5. أخطاء JWT وتخزين رموز الجلسة​

JSON Web Token أو JWT ليس نظام أمان كاملًا بمفرده. هو تنسيق للرموز الموقعة، وتبقى سلامته مرتبطة بطريقة الإصدار والتحقق والتخزين والإلغاء.
عند مراجعة كود JWT، تحقق من:
  • فرض خوارزمية توقيع محددة وآمنة.
  • التحقق من التوقيع في كل طلب محمي.
  • التحقق من الجهة المصدرة Issuer.
  • التحقق من الجمهور Audience.
  • التحقق من وقت الانتهاء Expiration.
  • عدم قبول الرموز غير الموقعة.
  • استخدام مدة قصيرة لرمز الوصول.
  • وجود آلية لتدوير Refresh Tokens وإلغائها.
  • تغيير المفاتيح السرية بصورة دورية.
  • عدم وضع بيانات حساسة داخل الحمولة؛ فالتوقيع لا يعني التشفير.
قد تساعد Cookies التي تحمل خصائص HttpOnly وSecure وSameSite في تقليل وصول JavaScript إلى الرمز، لكنها لا تلغي جميع المخاطر. فعند استخدام Cookies يجب أيضًا دراسة هجمات CSRF.
وفي المقابل، تخزين Bearer Tokens الحساسة في Local Storage يجعلها متاحة لكود JavaScript الموجود في الصفحة، ولذلك يمكن أن تتعرض للسرقة عند نجاح هجوم XSS.
لا توجد طريقة تخزين واحدة مثالية لكل التطبيقات. يعتمد الاختيار على بنية النظام، ونوع العميل، ونموذج التهديدات، وطريقة الحماية من XSS و CSRF.

دورة حياة Access Token وRefresh Token من الإصدار إلى الانتهاء والإلغاء​

6. التعيين الجماعي Mass Assignment أو Overposting​

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

يمكن للمهاجم إرسال الحقل يدويًا حتى إن لم يظهر في الواجهة:
كود: 
{
"name": "User",
"email": "[user@example.com](mailto:user@example.com)",
"isAdmin": true
}

إذا مرر الخادم الجسم بالكامل إلى ORM دون تحديد الحقول المسموحة، فقد يتحول المستخدم إلى مدير.

توصي إرشادات OWASP الخاصة بـ Mass Assignment باستخدام قائمة سماح للحقول القابلة للتعديل، أو استخدام Data Transfer Objects لا تحتوي أصلًا على الحقول الحساسة.
القاعدة العملية هنا بسيطة: لا تجعل نموذج الطلب الخارجي هو نفسه نموذج قاعدة البيانات.

7. البرمجة عبر المواقع XSS​

تظهر XSS عندما يعرض التطبيق محتوى غير موثوق بطريقة تسمح للمتصفح بتفسيره على أنه HTML أو JavaScript.
قد يحدث ذلك عند استخدام وظائف مثل:
كود: 
innerHTML
dangerouslySetInnerHTML
Html.Raw
document.write

وجود هذه الوظائف لا يعني أن التطبيق مخترق تلقائيًا، لكنه يتطلب مراجعة دقيقة لمصدر المحتوى وطريقة تنظيفه.
يمكن لهجوم XSS أن:
  • ينفذ إجراءات بصلاحيات المستخدم داخل التطبيق.
  • يقرأ بيانات ظاهرة في الصفحة.
  • يسرق الرموز أو Cookies غير المحمية بـ HttpOnly.
  • يغير محتوى الصفحة.
  • يرسل طلبات إلى خادم المهاجم.
  • يعرض نماذج تسجيل دخول مزيفة.
لكن من غير الدقيق القول إن XSS يجلب تلقائيًا جميع جلسات الخادم أو كل Cookies. المتصفح يمنع JavaScript من قراءة Cookies التي تحمل خاصية HttpOnly، كما أن المهاجم لا يحصل مباشرة على مخزن الجلسات داخل الخادم. ومع ذلك، قد يستطيع تنفيذ إجراءات داخل جلسة الضحية حتى إن لم يقرأ قيمة Cookie نفسها.
الحماية الصحيحة تشمل ترميز المخرجات حسب موضعها، واستخدام وظائف عرض آمنة، وتنظيف HTML عند السماح للمستخدم بإدخال تنسيق، وتفعيل Content Security Policy بوصفها طبقة إضافية لا بديلًا عن المعالجة الصحيحة.

8. الأسرار المضمنة داخل الكود Hardcoded Secrets​

من أخطر الأخطاء وضع مفاتيح API وكلمات مرور قواعد البيانات ومفاتيح خدمات الدفع داخل ملفات المشروع.
قد يظهر الكود هكذا:
كود: 
PAYMENT_SECRET = "secret-key-here"
DATABASE_PASSWORD = "password-here"
إذا رُفع المشروع إلى مستودع عام أو وصل إليه شخص غير مصرح له، فقد تُستخدم هذه الأسرار للوصول إلى الخدمات أو استهلاك الرصيد أو إرسال رسائل أو قراءة البيانات.

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

توفر GitHub ميزة Push Protection التي تفحص عمليات الدفع وتمنع بعض الأسرار المعروفة من الوصول إلى المستودع.
إذا تسرب مفتاح، فلا يكفي حذف السطر من آخر Commit. يجب إلغاء المفتاح أو تدويره فورًا، لأن القيمة قد تبقى في سجل Git أو النسخ المتفرعة أو ذاكرة أدوات البناء.
ولا ترسل أسرارك الحقيقية إلى نموذج ذكاء اصطناعي كي يكتب التكامل. استخدم قيمًا وهمية واضحة، ثم اربط الأسرار الحقيقية من بيئة التشغيل.
أنقر للتوسيع...

9. تسجيل البيانات الحساسة ورسائل الخطأ التفصيلية​

السجلات ضرورية لتشخيص المشكلات واكتشاف الهجمات، لكنها قد تتحول إلى قاعدة بيانات حساسة إذا سُجل كل شيء دون تنقية.
لا ينبغي أن تحتوي السجلات على:
  • كلمات المرور.
  • رموز JWT الكاملة.
  • رموز استعادة كلمة المرور.
  • مفاتيح API.
  • بيانات البطاقات المصرفية الكاملة.
  • Cookies أو معرفات جلسات قابلة للاستخدام.
  • بيانات شخصية لا توجد حاجة تشغيلية لتسجيلها.
  • نصوص طلبات كاملة تحتوي على أسرار.
كما يجب ألا يرى المستخدم النهائي Stack Trace أو مسارات الملفات الداخلية أو أوامر قاعدة البيانات أو تفاصيل البنية التحتية.

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

10. رفع الملفات دون قيود آمنة​

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

مع ذلك، يمكن لرفع الملفات غير الآمن أن يؤدي إلى:
  • رفع ملف قابل للتنفيذ.
  • رفع HTML أو SVG يحتوي على JavaScript.
  • استغلال ثغرة في مكتبة معالجة الصور أو المستندات.
  • استنزاف مساحة التخزين بملفات ضخمة.
  • رفع ZIP Bomb.
  • الكتابة فوق ملف موجود.
  • رفع ملفات تصيد أو برمجيات ضارة.
توصي إرشادات OWASP لرفع الملفات بقائمة سماح للامتدادات، وعدم الثقة في Content-Type، والتحقق من توقيع الملف، وتغيير الاسم، وتحديد الحجم، وتخزين الملفات خارج Web Root أو في خادم منفصل.
ويجب منع صلاحية التنفيذ عن مجلد الرفع، وفحص الملفات عند الحاجة، وعدم استخدام الاسم الأصلي مباشرة في مسار التخزين.

ثغرات أخرى قد يغفل عنها الكود المولد بالذكاء الاصطناعي​

لا تتوقف المخاطر عند الأخطاء السابقة. توجد ثلاث مناطق أخرى تحتاج إلى مراجعة:

الاعتماديات وسلسلة التوريد البرمجية​

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

الإعدادات الافتراضية غير الآمنة​

قد يترك الكود وضع Debug مفعّلًا، أو يسمح بجميع مصادر CORS، أو يستخدم حسابات افتراضية، أو يفتح قاعدة البيانات على الإنترنت.
راجع ملفات الإعداد لكل بيئة، ولا تفترض أن إعداد التطوير يصلح للإنتاج.

صلاحيات وكيل البرمجة نفسه​

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

سير عمل آمن لاستخدام الذكاء الاصطناعي في البرمجة​

يمكنك الاستفادة من سرعة الذكاء الاصطناعي دون تسليم أمن المشروع بالكامل له عبر الخطوات التالية:
  1. حدد متطلبات الأمان قبل توليد الكود: اشرح الأدوار والصلاحيات والبيانات الحساسة ونموذج الجلسات.
  2. قسّم العمل إلى تغييرات صغيرة: مراجعة Pull Request صغير أسهل من مراجعة مشروع كامل وُلد دفعة واحدة.
  3. اطلب تفسير القرارات الأمنية: لا تطلب الكود فقط، بل اسأل لماذا اختيرت هذه الطريقة وما التهديدات التي تغطيها.
  4. راجع الاختلافات سطرًا بسطر: انتبه إلى المصادقة والصلاحيات ومدخلات المستخدم والاستعلامات والملفات.
  5. اكتب اختبارات للصلاحيات: اختبر أن المستخدم لا يستطيع قراءة أو تعديل سجل مستخدم آخر.
  6. استخدم SAST: افحص الكود قبل التشغيل للبحث عن الأنماط الضعيفة.
  7. استخدم DAST واختبارات API: اختبر التطبيق أثناء التشغيل، وليس الملفات فقط.
  8. افحص الأسرار والاعتماديات: أضف Secret Scanning وفحص الحزم إلى CI/CD.
  9. اختبر في بيئة Staging: لا تجعل أول تجربة حقيقية للكود داخل الإنتاج.
  10. اطلب مراجعة بشرية متخصصة: خصوصًا لأنظمة الدفع والصحة والبيانات الشخصية والبنية السحابية.
  11. راقب النظام بعد النشر: المراجعة قبل النشر لا تغني عن السجلات والتنبيهات والاستجابة للحوادث.

مطالبة عملية لمراجعة الكود أمنيًا​

يمكنك استخدام الصيغة التالية مع وكيل البرمجة، لكن لا تعتبر نتيجتها بديلًا عن أدوات الفحص والمراجعة البشرية:
راجع هذا التغيير بوصفك مهندس أمن تطبيقات. لا تعدّل الكود قبل تحليل المخاطر. افحص التحكم في الوصول، وملكية السجلات، وحقن SQL والأوامر، و XSS، و CSRF، وMass Assignment، و إعدادات JWT و الجلسات، واستعادة كلمة المرور، وتحديد معدل الطلبات، ورفع الملفات، والأسرار، والسجلات، ورسائل الخطأ، والاعتماديات.

لكل مشكلة:
1. حدد الملف والسطر.
2. اشرح سيناريو الاستغلال.
3. صنف الخطورة دون مبالغة.
4. اقترح إصلاحًا متوافقًا مع إطار العمل.
5. اكتب اختبارًا يثبت أن الثغرة أُغلقت.
6. اذكر ما لا تستطيع التحقق منه من الكود المتاح.
أنقر للتوسيع...

سير عمل آمن لمراجعة واختبار الكود المولد بالذكاء الاصطناعي قبل الإنتاج​

أسئلة شائعة حول أخطر ثغرات الكود المولد بالذكاء الاصطناعي​

هل الكود الذي يولده الذكاء الاصطناعي غير آمن دائمًا؟​

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

هل يكفي أن أطلب من الذكاء الاصطناعي كتابة كود آمن؟​

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

هل استخدام ORM يمنع SQL Injection بالكامل؟​

لا. تقلل أدوات ORM الخطر عند استخدام واجهاتها الآمنة والاستعلامات المعلّمة، لكن الاستعلامات الخام أو الديناميكية ودمج النصوص قد يعيد الثغرة.

هل HttpOnly يمنع جميع هجمات XSS؟​

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

متى أحتاج إلى تدقيق أمني متخصص؟​

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

خلاصة القول​

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

شاركنا في الردود: ما أكثر ثغرة أو خطأ أمني اكتشفته داخل كود مولد بالذكاء الاصطناعي؟
دمتم بود!

المصادر والمراجع​

 
دليل كتابة المهارات Skills باحتراف لزيادة الإنتاجية
دليل كتابة المهارات Skills باحتراف لزيادة الإنتاجية
عودة
أعلى أسفل