اختراق Moltbook: عندما يصبح البرمجة بالذكاء الاصطناعي كابوسًا أمنيًا

ما الذي حدث فعلاً في Moltbook؟

دعني أوضح بالضبط ما الذي خطأ، لأن التفاصيل مهمة.

تم بناء Moltbook باستخدام Supabase — بديل Firebase مفتوح المصدر شائع يوفر قواعد بيانات PostgreSQL المستضافة. أصبح Supabase الخيار الأول للخلفية لتطبيقات البرمجة بالذكاء الاصطناعي لأنه يتعامل مع المصادقة وقواعد البيانات والتخزين بأقل تكوين ممكن.

المشكلة؟ قام شخص (أو بعض الذكاء الاصطناعي) بوضع مفتاح API الخاص بـ Supabase مباشرة في كود JavaScript الخاص بالعميل. هذا خطأ أمني أساسي. مفاتيح API تعود إلى الخادم، ولا يجب أبدًا أن تكون في كود يعمل في متصفح المستخدم.

لكن الأمور أسوأ.

كان لتلك المفتاح البرمجي صلاحية قراءة وكتابة كاملة لقاعدة البيانات بأكملها. ولم يكن Moltbook قد فعّل أمان مستوى الصفوف (RLS) — وهي ميزة في Supabase تتحكم في من يمكنه الوصول إلى أي بيانات. RS اختياري تمامًا مثل حزام الأمان. قد تعتقد أنك لا تحتاجه حتى تصطدم.

وجد باحثو الأمن في Wiz المفتاح المكشوف خلال دقائق من النظر إلى الموقع. كان بإمكانهم:

• تم تنزيل 1.5 مليون مفتاح API (بما في ذلك المفاتيح الخاصة بـ OpenAI و Anthropic ومزودي ذكاء اصطناعي آخرين)
• الوصول إلى رسائل خاصة بين وكلاء الذكاء الاصطناعي
• عدّل أو حذف أي بيانات في قاعدة البيانات
• اختطاف أي حساب مستخدم
• تشغيل فواتير ضخمة باستخدام مفاتيح API مسروقة

المفاجأة؟ اعترف المؤسس أنه "برمج المنصة بأكملها بالاهتزاز الذهني" (vibe-coded). بدون مراجعة أكواد. بدون تدقيق أمني. مجرد أوامر لـ AI ونسخ ولصق النتائج.

لماذا يستمر هذا؟

هذا هو ما هو مزعج في هذه القصة: ليست فريدة من نوعها.

تذكر عندما تعرض DeepSeek لمفاتيح API الخاصة بهم؟ أو Base44؟ يتكرر النمط لأن فلسفة البرمجة بالذكاء الاصطناعي تثبط بنشاط الممارسات التي تمنع هذه الاختراقات.

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

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

تحدثت مع باحث أمني متخصص في الأكواد المولّدة بالذكاء الاصطناعي. إليك ما يبقيه مستيقظًا في الليل:

• عدم فهم ما يحدث: عندما تطلب من الذكاء الاصطناعي "بناء نظام تسجيل دخول"، تحصل على كود يبدو كنظام تسجيل دخول لكن قد يحتوي على أخطاء خفية لا يلاحظها إلا الخبراء
• الثقة في الذكاء الاصطناعي: يفترض المستخدمون أن الكود المولد بالذكاء الاصطناعي آمن لأن... إنه من ذكاء اصطناعي؟ هذا الافتراض خاطئ تماماً
• نقص الأساسيات: غالبًا ما لا يعرف مبرمجو الإحساس (Vibe coders) ما لا يعرفونه عن الأمان

مشكلة الـ 45%

دعني أعطيك رقمًا يجب أن يبقيك مستيقظًا: 45%.

هذا هو نسبة الكود المُولَّد بالذكاء الاصطناعي الذي يحتوي على ثغرات أمنية، وفقًا لأبحاث Veracode حول أمن البرمجيات المُولّدة بالذكاء الاصطناعي^[1].

هذا ليس عن نماذج ذكاء اصطناعي سيئة أو مطوّرين غير أكفاء. إنه يتعلق بالطبيعة الجوهرية لتوليد الأكواد. نماذج الذكاء الاصطناعي مدرّبة على أكواد موجودة — بما في ذلك أكواد غير آمنة. إنها تكرّر الأنماط التي رأتها، بما في ذلك الأنماط الضعيفة.

الثغرات الشائعة في الأكواد المُنشأة بالذكاء الاصطناعي تشمل:

كان اختراق Moltbook في الواقع مشكلتين: مفتاح API مبرمج بصلابة (أسرار مبرمجة بصلابة) وRLS مفقود (تكوين غير آمن). أي منهما وحده كان سيئًا. معًا، أنشأا كارثة.

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

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

ما زلت تحتاج إلى فهم الأمان

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

أنت لا تحتاج أن تصبح خبير أمن. لكنك تحتاج أن تفهم:

• لا تضع أبدًا الأسرار في كود جانب العميل
• فعّل دائماً أمان مستوى الصفوف على قواعد البيانات
• استخدم متغيرات البيئة للإعدادات الحساسة
• تنفيذ التحقق الصحيح من المدخلات
• تشغيل فحوصات أمنية على الكود المُنشأ

نموذج أولي سريع، ثم هندسة

سير العمل الحالي الخاص بي:

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

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

استخدم الأداة المناسبة للمهمة

قد يكون هذا مثيرًا للجدل، لكنني لا أعتقد أن البرمجة بالذكاء الاصطناعي مناسبة لـ:

• تطبيقات تتعامل مع بيانات المستخدم الحساسة (الرعاية الصحية، المالية)
• أنظمة معالجة المدفوعات
• أي شيء يتطلب متطلبات الامتثال التنظيمي
• تطبيقات قد تسبب أضرارًا حقيقية في حالة فشل الأمان

للأدوات الداخلية وMVP والنماذج الأولية؟ انطلق بحرية. للأنظمة الإنتاجية التي تتعامل مع بيانات المستخدم الحقيقية؟ مهندسها بشكل صحيح.

كيف تحمي نفسك

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

لـ Supabase/الخلفية الخاصة بك

javascript
// WRONG - Never do this
const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE')
// Your service_role key is also exposed here!

// CORRECT - Use environment variables, server-side only
const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_ANON_KEY
)

قائمة التحقق الأمنية الأساسية

• [ ] تفعيل أمان مستوى الصف في ALL جداول قاعدة البيانات
• [ ] احفظ مفاتيح API في متغيرات البيئة، وليس في الكود
• [ ] شغّل فحص أمني على جميع الأكواد المُولَّدة (Snyk، CodeQL، أو GitHub Advanced Security)
• [ ] لا تكشف أبدًا عن مفاتيح service_role للعميل
• [ ] نفّذ التحقق الصحيح من المدخلات على جميع مدخلات المستخدم
• [ ] إعداد تحديد معدل لمنع الإساءة
• [ ] الحصول على اختبار اختراق قبل إطلاق أي شيء مع مستخدمين حقيقيين

أدوات تساعدك

ماذا يعني هذا للصناعة

أنا قلق حقًا بشأن الاتجاه الذي نتجه إليه.

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

لكننا ننشئ أيضًا جيلًا من التطبيقات بدون أحد يراقب المتجر.

ها هو ما أعتقد أنه يجب أن يحدث:

• أدوات البرمجة بالذكاء الاصطناعي تحتاج إلى أمان افتراضي أفضل — توقف عن توليد كود يحتوي على ثغرات أمنية مدمجة
• يجب أن يتحدث المجتمعات أكثر عن هذا — كل مقال مدونة عن vibe coding يجب أن يذكر الأمان
• نحتاج إلى أدوات أفضل — يجب أن يكون المسح الأمني الآلي مدمجًا في كل سير عمل برمجة بالذكاء الاصطناعي
• على المؤسسين أن يتحملوا المسؤولية — لا يمكنك إلقاء اللوم على الذكاء الاصطناعي عندما يسوء شيء ما

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

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

الخلاصة

Moltbook ليس حالة فردية. إنه لمحة عما هو قادم.

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

هذا ليس حجة ضد البرمجة بالشعور. إنه حجة للصدق حول حدودها.

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

منشورات ذات صلة

• ما هو الترميز بالذكاء الاصطناعي (Vibe Coding)؟ الدليل الشامل 2026
• Cursor مقابل Windsurf للبرمجة بالذكاء الاصطناعي: أيهما يفوز في 2026؟
• كيف تبني تطبيق ذكاء اصطناعي في 7 أيام (خطوة بخطوة
• كيف تحصل على 100 مستخدم بيتا بسرعة

جاهز لإطلاق تطبيقك بأمان؟ أدرج تطبيقك على GetFree — دليل مُختار حيث يشارك المطورون رموز العرض الترويجي والوصول إلى النسخ التجريبية مع آلاف المختبرين المستهدفين.

المصادر

نُشر أصلاً على مدونة GetFree.APP — آخر تحديث: 17 فبراير 2026