مخاطر أمان البرمجة بالحدس: 8 أمور تفحصونها قبل الإطلاق

يعني "Vibe coding" بناء البرمجيات عبر وصف ما تريده لذكاء اصطناعي وقبول ما ينتجه. وقد وضع هذا النهج بناء التطبيقات في متناول المؤسسين والمصممين والمشغّلين الذين لم يكونوا قادرين على البرمجة قبل عام أو عامين. كما أوجد نوعاً جديداً من الثغرات الأمنية: برمجيات تعمل وتبدو مكتملة لكن لم يراجعها أحد يفكر بعقلية المهاجم.

يسرد هذا الدليل المخاطر الأمنية الثمانية التي سنفحصها أولاً في تطبيق مبني بأسلوب vibe-coding، وسبب حدوث كل منها، وما ينبغي فعله حيالها. لا يتطلب أي منها أن تقرأ الشيفرة. بل يتطلب أن تطرح الأسئلة الصحيحة قبل وصول المستخدمين الحقيقيين.

لماذا تتميز التطبيقات المولّدة بالذكاء الاصطناعي بملف مخاطر خاص

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

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

الخطر 1: التحكم المعطوب في الوصول

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

الاختبار: استخدم حسابين وحاول الوصول إلى بيانات بعضهما بتغيير المعرّفات في عناوين URL والطلبات.

الخطر 2: الأسرار المكشوفة

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

الإصلاح: احتفظ بالأسرار في متغيرات البيئة على جانب الخادم، وابحث في حزمتك (bundle) ومستودعك عن المفاتيح، وبدّل أي شيء تعرّض للكشف يوماً.

الخطر 3: المدخلات غير المتحقق منها

النماذج وعناوين URL ومعاملات API يتحكم بها المهاجم. فإذا كان التطبيق يبني استعلامات قاعدة البيانات بضم السلاسل النصية، أو يطبع مدخلات المستخدم في الصفحات دون ترميزها، فقد يكون عرضة لحقن SQL أو للبرمجة عبر المواقع (cross-site scripting). تمنع أطر العمل الحديثة ومنشئات الاستعلام معظم ذلك افتراضياً، لكن الشيفرة المولّدة تتجاوزها أحياناً.

الإصلاح: استخدم الاستعلامات ذات المعاملات (parameterised)، وتحقق من المدخلات على الخادم، وراجع أي موضع تُبنى فيه استعلامات خام أو HTML خام.

الخطر 4: التبعيات الوهمية والقديمة

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

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

الخطر 5: الإعدادات الافتراضية غير الآمنة

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

الإصلاح: راجع إعدادات الإنتاج بمعزل عن التطوير، وعطّل كل ما وُجد لمجرد الراحة.

الخطر 6: غياب حدود للاستخدام أو التكلفة

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

الإصلاح: أضف تحديد المعدل (rate limiting)، وحدّد سقوف استخدام لكل مفتاح طرف ثالث، ونبّه عند قفزة الإنفاق.

الخطر 7: حقن الأوامر (prompt injection) في ميزات الذكاء الاصطناعي لديك

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

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

الخطر 8: لا تسجيل، وبالتالي لا وسيلة للمعرفة

لا تستطيع تطبيقات vibe-coding كثيرة الإجابة عن أسئلة أساسية بعد وقوع خلل: من وصل إلى ماذا، ومتى بدأ الخطأ، وأي طلب فشل. وبدون سجلات ومراقبة، قد تستمر الحادثة أسابيع قبل أن يلاحظها أحد، ولا يمكنك معرفة ما تعرّض للكشف.

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

جولة أمنية مدتها 30 دقيقة يمكنك إجراؤها اليوم

1. أنشئ حسابَي اختبار وحاول رؤية بيانات بعضهما وتغييرها وحذفها.
2. ابحث في مستودعك وفي شيفرة موقعك المبني عن مفاتيح API ورموز الخدمات.
3. تحقق من مستودعات التخزين وجداول قاعدة البيانات القابلة للقراءة علناً.
4. افتح طلبات الشبكة في تطبيقك وابحث عن أسرار أو عناوين URL داخلية أو أخطاء مسهبة.
5. أدرج كل تبعية وتأكد من أن كلاً منها حقيقية وحديثة ومقصودة.
6. تأكد من وجود حدود للمعدل وسقوف للإنفاق على تسجيل الدخول والتسجيل وأي ميزة ذكاء اصطناعي.
7. تحقق من أن الأخطاء والإجراءات الحساسة تُسجَّل في مكان يمكنك قراءته.

ما تستطيع أدوات الذكاء الاصطناعي فعله حيال هذا وما لا تستطيعه

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

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