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

أبرز المخاطر الأمنية للكود المكتوب بالذكاء الاصطناعي مفاتيح سرية متروكة حيث يستطيع أي شخص قراءتها، وقواعد بيانات بلا قواعد وصول، ومستخدمون يفتحون سجلات غيرهم بتغيير رقم المعرّف، ومدخلات لا يتحقق منها أحد، وحزم وهمية أو قديمة، وتعامل ضعيف مع تسجيل الدخول، وغياب أي حد لعدد الطلبات، وبيانات حساسة في السجلات، ونسخ احتياطية لا تعمل. أدوات مثل Cursor وLovable وBolt وReplit وv0 وClaude وChatGPT تكتب كوداً يعمل جيداً في العرض التجريبي، لكنها لا تعرف أي بياناتك يجب أن تبقى خاصة، وكثيراً ما تُغفل هذه الحمايات ما لم يطلبها أحد.

وفي ما يلي كل مشكلة مع كلفتها المحتملة وطريقة إصلاحها، لمؤسسي الشركات الذين بنوا تطبيقاً بالذكاء الاصطناعي وللمطوّرين الذين يتولّون رعايته.

لماذا تتشارك التطبيقات المبنية بالذكاء الاصطناعي نقاط الضعف نفسها

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

وتشير الأبحاث إلى الاتجاه نفسه. ففي تقرير Veracode لعام 2025 عن أمان الكود المولَّد بالذكاء الاصطناعي أنجز أكثر من 100 نموذج لغوي 80 مهمة برمجية، واحتوى نحو 45% من النتائج على نوع معروف من الثغرات الأمنية. ووجدت دراسة من جامعة Stanford عام 2022 أن المطوّرين الذين استخدموا مساعداً بالذكاء الاصطناعي كتبوا كوداً أقل أماناً من الذين عملوا بدونه، وكانوا أكثر ميلاً إلى الاعتقاد بأن كودهم آمن. وفي 2025 فحص باحث 1,645 تطبيقاً من معرض Lovable العام، فوجد 170 تطبيقاً يستطيع أي شخص قراءة قواعد بياناتها أو تعديلها لغياب قواعد الوصول (سُجّلت الثغرة باسم CVE-2025-48757).

لذلك يحتاج الكود الذي تنتجه هذه الأدوات إلى المراجعة نفسها التي تجريها على عمل مطوّر جديد.

تسع مشاكل شائعة في الكود المكتوب بالذكاء الاصطناعي

1. مفاتيح API والأسرار في الواجهة الأمامية أو في مستودع عام

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

ويحدث ذلك لأن أسرع طريقة لتشغيل أي ربط هي لصق المفتاح في الكود مباشرة، وهذا ما تفعله الأداة حين تطلب منها ربط Stripe أو OpenAI. وقد أحصت GitGuardian تسرّب 23.8 مليون سرّ على GitHub العام في 2024، ووجدت نسب تسرّب أعلى في المستودعات التي تستخدم مساعدي الذكاء الاصطناعي.

// Runs in the browser: anyone can read this key
const supabase = createClient(SUPABASE_URL, "eyJhbGciOi...service_role...");
const openai = new OpenAI({ apiKey: "sk-proj-...", dangerouslyAllowBrowser: true });

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

2. قواعد الوصول إلى قاعدة البيانات معطّلة أو مفتوحة

يسمح Supabase وFirebase للمتصفح بالتواصل مع قاعدة البيانات مباشرة، وهذا آمن فقط حين تقرر قاعدة البيانات نفسها من يحق له قراءة كل صف وكتابته. ويسمّى ذلك في Supabase الأمان على مستوى الصفوف (Row Level Security, RLS)، وفي Firebase قواعد الأمان (Security Rules).

تنشئ أدوات الذكاء الاصطناعي الجداول بسرعة، وكثيراً ما تترك RLS معطّلاً، أو تضيف سياسة تسمح بكل شيء حتى تتوقف رسائل الخطأ في التطبيق. وتبدأ بعض مشاريع Firebase في وضع الاختبار ولا تُقفل بعد ذلك أبداً. وفي يوليو 2025 كشف تطبيق Tea لسلامة المواعدة نحو 72,000 صورة، منها صور هويات، من مساحة تخزين بلا أي ضوابط وصول. ونفت الشركة أن يكون الذكاء الاصطناعي قد كتب الكود، وفي الحالتين كانت مساحة التخزين مفتوحة.

// Firebase rules that let anyone read and write everything
allow read, write: if true;

-- Supabase: switch RLS on and let users see only their own rows
alter table invoices enable row level security;
create policy "own invoices" on invoices
  for select using (auth.uid() = user_id);

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

3. مستخدمون يقرؤون بيانات غيرهم بتغيير رقم المعرّف

يسمّى هذا خلل التحكم في الوصول (Broken Access Control)، وهو في رأس قائمة OWASP Top 10 لمخاطر الويب. يفتح مستخدم مسجّل الدخول /invoices/1042، ويغيّره إلى /invoices/1043، فيرى فاتورة شركة أخرى.

تتحقق أداة الذكاء الاصطناعي من أن المستخدم مسجّل الدخول لأنك طلبت تسجيل دخول، وتتجاوز التحقق من أن السجل يخصّه لأن أحداً لم يطلب ذلك.

// Any logged-in user can read any invoice
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  res.json(await Invoice.findById(req.params.id));
});

// Safer: only return the invoice if it belongs to this user's company
const invoice = await Invoice.findOne({ _id: req.params.id, companyId: req.user.companyId });
if (!invoice) return res.status(404).end();

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

4. الثقة بما يكتبه المستخدمون

كل حقل في نموذج وكل مربع بحث وكل معامل في الرابط طريق إلى داخل تطبيقك. ومن دون تحقق، يستطيع المستخدم إرسال نص تنفّذه قاعدة البيانات كأمر، وهو حقن SQL أو NoSQL (SQL Injection)، أو نص ينفّذه المتصفح كسكربت عند زوار آخرين، وهو البرمجة النصية عبر المواقع (Cross-Site Scripting, XSS).

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

// Injection: the search text becomes part of the SQL command
db.query("SELECT * FROM users WHERE email = '" + req.body.email + "'");

// Safer: a parameterized query
db.query("SELECT * FROM users WHERE email = $1", [req.body.email]);

الكلفة المحتملة: بيانات مسروقة أو محذوفة، وحسابات يُستولى عليها عبر سكربت مخفي في تعليق أو ملف شخصي، وموقعك يُستخدم لمهاجمة عملائك أنفسهم. الحل: استخدم استعلامات بمعاملات (Parameterized Queries) أو ORM معروفاً وواسع الاستخدام، وتحقّق من المدخلات على الخادم وفق الصيغة التي تتوقعها، واترك إطار العمل يعالج المخرجات (Escaping) بدل إدراج HTML خام. وفي مقالنا عن تلوّث النموذج الأولي (Prototype Pollution).

5. حزم قديمة أو مختلَقة

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

درس باحثون من ثلاث جامعات أمريكية 576,000 عينة كود من 16 نموذجاً، ووجدوا أن نحو 20% من الحزم التي أوصت بها غير موجودة. ويستطيع المهاجمون تسجيل هذه الأسماء المختلَقة وملأها ببرمجيات خبيثة، وتسمّى هذه الحيلة Slopsquatting.

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

6. أخطاء تسجيل الدخول والجلسات

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

الكلفة المحتملة: الاستيلاء على الحسابات، ومنها حسابات المديرين. الحل: استخدم خدمة أو مكتبة مصادقة مجرّبة بدل واحدة مبنية يدوياً، واحفظ الجلسات في ملفات تعريف ارتباط آمنة من نوع HTTP-only بمدة صلاحية معقولة، وأعد كل فحص للصلاحيات على الخادم.

7. لا حدود لعدد الطلبات

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

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

8. الأسرار والبيانات الشخصية في السجلات

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

console.log("Login attempt", req.body);   // includes the password

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

9. نسخ احتياطية غائبة أو غير مختبرة

النسخ الاحتياطية من ضوابط الأمان أيضاً. ففي يوليو 2025 أفاد Jason Lemkin، مؤسس SaaStr، بأن وكيل الذكاء الاصطناعي في Replit حذف قاعدة بيانات التشغيل الفعلي لديه أثناء فترة تجميد الكود، ولم تكن هناك نسخة احتياطية تلقائية لاستعادتها. ويمكن لترحيل بيانات خاطئ أو لهجوم فدية (Ransomware) أن يُحدث الضرر نفسه.

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

متى تكون البرمجة بالإيحاء آمنة بما يكفي

البرمجة بالإيحاء (Vibe Coding)، أي بناء تطبيق بوصفه لأداة ذكاء اصطناعي، طريقة سريعة لاختبار فكرة. والنموذج الأولي ببيانات وهمية وعدد قليل من المستخدمين التجريبيين خطره قليل. لكن الصورة تتغير حين يحمل التطبيق بيانات عملاء حقيقية، أو يقبل المدفوعات، أو يتصل بأنظمة عملك، أو يُفتح للجمهور. فمن تلك اللحظة تحتاج الأسئلة الواردة في هذا المقال إلى إجابات مدعومة بالأدلة، من جهة غير الأداة التي كتبت الكود.

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

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

هل الكود المكتوب بالذكاء الاصطناعي أقل أماناً من الكود الذي يكتبه الناس؟

تقيس الدراسات ذلك بطرق مختلفة، لكنها تتفق على أنه يحتوي في كثير من الأحيان على ثغرات معروفة. فقد وجدت Veracode ثغرات معروفة في نحو 45% من الكود الذي أُنتج في اختباراتها لعام 2025، لذلك راجع الكود المكتوب بالذكاء الاصطناعي بالعناية نفسها التي تراجع بها كود موظف جديد.

هل Lovable أو Supabase غير آمن بحد ذاته؟

توفّر هذه المنصات أدوات حماية بياناتك، مثل الأمان على مستوى الصفوف (Row Level Security) في Supabase. وتأتي المشاكل من تطبيقات لم تُفعَّل فيها هذه القواعد أصلاً أو كُتبت لتسمح بكل شيء. وقد أضافت Lovable فحصاً أمنياً بعد نتائج 2025، لكن الفحص لا يغني عن مراجعة قواعد الوصول الخاصة بك.

هل أستطيع أن أطلب من أداة الذكاء الاصطناعي إصلاح المشاكل الأمنية بنفسها؟

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

ماذا أفعل إذا كان مفتاح سري قد انكشف بالفعل؟

ألغِ المفتاح لدى المزوّد وأنشئ مفتاحاً جديداً فوراً، ثم راجع سجلات المزوّد وفواتيره بحثاً عن استخدام لا تعرفه. وحذف المفتاح من الكود لا يكفي، لأنه يبقى في سجل المستودع وربما نُسخ بالفعل.

كيف أعرف أن تطبيقي المبني بالذكاء الاصطناعي آمن للإطلاق؟

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

افحص تطبيقك قبل أن يكتشف مستخدموك الثغرات

إذا كان عملك يعتمد على تطبيق مبني بالذكاء الاصطناعي، فالمراجعة الخارجية تكلّف أقل بكثير من الاختراق. وخدمة تقييم الكود المكتوب بالذكاء الاصطناعي لدينا تفحص أي تطبيق، أيّاً كانت الأداة أو التقنيات التي بُني بها، وتراجع أمانه وجودة الكود وسهولة صيانته وجاهزيته للتشغيل الفعلي. ونوقّع اتفاقية عدم إفصاح (NDA) قبل أن نطّلع على الكود. وتحصل على تقرير فيه دليل على كل اكتشاف وترتيب واضح لما يجب إصلاحه أولاً. ويبدأ التقييم من $1,000. ولتعرف ما الذي سيشمله تقييم تطبيقك، فاحجز مكالمة مجانية مدتها 30 دقيقة.