كيف تؤمّن تطبيقًا مبنيًا بأسلوب Vibe Coding قبل أن تشاركه
الجواب السريع
قبل أن يستخدم زملاؤك تطبيقًا بنيته بالذكاء الاصطناعي، تحقق أولًا من أربعة أشياء: لا أحد يتجاوز تسجيل الدخول بحساب الشركة، ولا يدخل إلا أصحاب حسابات شركتك، ولا توجد مفاتيح في الشيفرة التي تعمل في المتصفح، ولا يمكن قراءة قاعدة البيانات دون المرور بالتطبيق. ثم تحقق ممن يستطيع فعل ماذا داخله، ومن يملكه عندما تغادر.
معظم التسريبات من التطبيقات المبنية بالذكاء الاصطناعي ليست هجمات ذكية. إنها أبواب مفتوحة: رابط عام، أو قاعدة بيانات قواعدها معطّلة، أو مفتاح داخل الصفحة. قائمة التحقق هذه للشخص الذي بنى التطبيق ولمن يراجعه من فريق تقنية المعلومات. كل بند يذكر ما الذي يسوء، وكيف تتحقق منه بكلمات بسيطة، وما يتولاه TeamOnly وما يبقى عليك.
آخر تحديث كتبه فريق TeamOnly. نحن نستضيف تطبيقات داخلية مبنية بالذكاء الاصطناعي، وكل بند يذكر بصدق أين نساعد وأين لا نساعد.
01لماذا يهم هذا
ما الذي يسوء في التطبيقات المبنية بالذكاء الاصطناعي
أدوات الذكاء الاصطناعي بارعة في جعل التطبيق يعمل. وأقل حرصًا على من يعمل لهم أيضًا. ثلاث نتائج من العامين الماضيين تُظهر النمط.
380,000
أصل يمكن الوصول إليه علنًا على Lovable وBase44 وNetlify وReplit، وجدتها شركة الأمن Red Access في مايو 2026. نحو 5,000 منها احتوت بيانات حساسة لشركات، وكثير منها فهرسه Google.
170 من 1,645
تطبيقًا على Lovable فُحصت في مارس 2025 سمحت لأي شخص بقراءة البيانات في قاعدة بيانات Supabase الخاصة بها أو تغييرها دون تسجيل الدخول، لأن قواعد الوصول إلى قاعدة البيانات كانت مفقودة أو خاطئة (CVE-2025-48757).
205,474
اسم حزمة مختلَق اقترحها 16 نموذج ذكاء اصطناعي عبر 576,000 عينة شيفرة، في دراسة من 2025. يمكن للمهاجمين نشر حزم بتلك الأسماء وانتظار أن يثبّتها أحد.
لم يحتج أيٌّ من هذا إلى مهاجم ذكي. كانت الأبواب مفتوحة. وهذا خبر جيد: الأبواب المفتوحة سهلة الفحص، ولا تحتاج إلى قراءة الشيفرة لتفعل ذلك.
نفّذها بالترتيب. الأولى تُبقي الغرباء في الخارج، واللاحقة تكشف الأخطاء داخل الشركة.
لا شيء يُحمَّل قبل تسجيل الدخول بحساب الشركة
ما الذي يسوء
كثيرًا ما تبني أدوات الذكاء الاصطناعي شاشة تسجيل الدخول صفحةً واحدة من صفحات التطبيق. بقية التطبيق، وواجهة API الخاصة به، تظل تجيب أي شخص يتخطى تلك الصفحة أو يستدعي API مباشرة. وجدت Red Access تطبيقات شركات منحت صلاحيات المسؤول لكل من وصل إلى العنوان.
تحقق بنفسك
افتح التطبيق في نافذة تصفح خاصة. يجب أن ترى شاشة تسجيل دخول ولا شيء غيرها. ثم اسأل أداة الذكاء الاصطناعي: «اذكر كل مسارات API وقل لي أيها يعمل دون تسجيل الدخول». يجب أن يكون الجواب: لا شيء.
على TeamOnly
متكفَّل به. كل طلب إلى كل تطبيق يُفحص قبل أن تعمل أي شيفرة لك، بما في ذلك استدعاءات API، التي تحصل على 401 دون جلسة. لا يوجد إعداد لجعل تطبيق عامًا.
لا يدخل إلا أصحاب حسابات شركتك
ما الذي يسوء
«تسجيل الدخول عبر Google» يُدخل أي حساب Google افتراضيًا، بما فيه Gmail الشخصي. إعداد hd من Google يضيّق قائمة اختيار الحساب فقط، وGoogle تحذّر من الاعتماد عليه لأن الطلب يمكن تغييره. يجب التحقق من النطاق على الخادم.
تحقق بنفسك
حاول تسجيل الدخول بحساب Gmail أو Outlook شخصي. يجب أن تُرفض. اسأل أداة الذكاء الاصطناعي أين يتحقق الخادم من نطاق البريد، وهل يتحقق من الرمز الموقَّع من Google أم من قيمة أرسلها المتصفح.
على TeamOnly
متكفَّل به. يسجّل الزملاء الدخول بحساب Google للعمل، أو بحساب Microsoft للعمل، أو برمز يُرسل إلى بريد العمل. يُقارَن النطاق في رمز تسجيل الدخول الموثَّق بنطاقات شركتك، وتُرفض الحسابات الشخصية.
الأشخاص المناسبون فقط داخل الشركة
ما الذي يسوء
تطبيق فيه رواتب أو تقييمات أداء أو بيانات عملاء يُشارك مع الشركة كلها لأن ذلك كان الإعداد الافتراضي. أو يبني الذكاء الاصطناعي قائمة سماح خاصة به داخل الشيفرة لا يحدّثها أحد.
تحقق بنفسك
اسأل: هل يجب أن يرى الجميع في الشركة هذه البيانات؟ إن لم يكن، فاكتب أسماء من يجب أن يروها، وتحقق من أن شخصًا خارج تلك القائمة يُرفض.
على TeamOnly
متكفَّل به، وأنت تختار. الوصول إما للشركة كلها أو لقائمة بأسماء محددة، يُضبط من لوحة التحكم أو بـ npx teamonly access only priya@acme.com. يُفحص مع كل طلب، فيسري حذف شخص خلال دقيقة.
ليس على رابط عام، ولا في نتائج البحث
ما الذي يسوء
بعض منصات بناء التطبيقات تنشر على عنوان عام ما لم تختر «خاص». والتطبيقات العامة تُكتشف: أفادت Red Access بأن كثيرًا من تطبيقات الشركات المكشوفة فهرسها Google ومحركات بحث أخرى.
تحقق بنفسك
ابحث في Google عن site: متبوعًا بعنوان تطبيقك. تحقق من إعداد ظهور المشروع على المنصة التي بنيته بها. إذا كان «عامًا»، فغيّره قبل أي شيء آخر.
على TeamOnly
متكفَّل به. تعمل التطبيقات على yourapp.yourcompany.teamonly.app خلف شاشة تسجيل الدخول. كل استجابة، بما فيها شاشة تسجيل الدخول، تطلب من محركات البحث عدم فهرستها، وشاشة تسجيل الدخول لا تعرض إلا اسم التطبيق وطرق تسجيل الدخول.
لا مفاتيح في الشيفرة التي تعمل في المتصفح
ما الذي يسوء
تضع أدوات الذكاء الاصطناعي مفاتيح API في شيفرة React أو في متغيرات تبدأ بـ VITE_ أو NEXT_PUBLIC_. كل ما يُرسل إلى المتصفح يمكن أن يقرأه أي شخص يفتح التطبيق. وتقول Supabase إن مفتاحها السري يجب ألا يكون في متصفح أبدًا، لأنه يتجاوز كل قواعد قاعدة البيانات.
تحقق بنفسك
اسأل أداة الذكاء الاصطناعي: «هل يوجد أي مفتاح أو رمز أو كلمة مرور في شيفرة الواجهة، أو في متغير VITE_، أو في ملف .env مُضاف إلى المستودع؟». في المتصفح، افتح أدوات المطور وابحث في الملفات المحمَّلة عن key وsecret وsk_. إذا انكشف مفتاح في أي وقت، فغيّره لدى الخدمة التي أصدرته.
على TeamOnly
متكفَّل به جزئيًا. تُحفظ المفاتيح بـ npx teamonly secrets set NAME، خارج الشيفرة، ولا تقرؤها إلا شيفرة الخادم في تطبيقك. التعليمات التي يضيفها TeamOnly تطلب من أداة الذكاء الاصطناعي ألا تستخدم مفاتيح VITE_ أبدًا. لا شيء يمنعك من لصق مفتاح في الشيفرة بنفسك، فتحقق مع ذلك.
لا يمكن قراءة قاعدة البيانات بتجاوز التطبيق
ما الذي يسوء
مع Supabase والخدمات المشابهة، يتحدث المتصفح إلى قاعدة البيانات مباشرة، وقواعد الوصول (row-level security) تحدد ما يمكنه رؤيته. عندما تكون تلك القواعد معطّلة أو خاطئة، يستطيع أي شخص لديه المفتاح العام قراءة جداول كاملة أو تغييرها. كانت تلك نتيجة فحص Lovable.
تحقق بنفسك
في Supabase، افتح Advisors ثم Security Advisor. أي خطأ «RLS disabled in public» يعني جدولًا يستطيع أي شخص قراءته. وجود قاعدة لا يكفي: سجّل الدخول كزميل عادي وحاول فتح سجل شخص آخر.
على TeamOnly
متكفَّل به في وجه الغرباء. ليس لقاعدة بيانات أي تطبيق عنوان خاص بها على الإنترنت. لا يمكن الوصول إليها إلا عبر شيفرة الخادم في تطبيقك، بعد تسجيل الدخول. أما أي صفوف يحق لكل شخص مسجّل رؤيتها، فضبطها يبقى على شيفرة تطبيقك (انظر الفحص 8).
بيانات كل تطبيق منفصلة
ما الذي يسوء
عدة تطبيقات تتشارك قاعدة بيانات واحدة أو حاوية تخزين واحدة لأن ذلك كان أسرع. عندها يفتح مفتاح أو خلل في تطبيق واحد كل التطبيقات.
تحقق بنفسك
اسأل: هل يستخدم أي تطبيق آخر قاعدة البيانات أو التخزين أو المفاتيح نفسها التي يستخدمها هذا التطبيق؟ إن كان الجواب نعم، فأضعف تطبيق يحدد مدى أمان الجميع.
على TeamOnly
متكفَّل به. يحصل كل تطبيق على قاعدة بيانات وتخزين ملفات وأسرار خاصة به عند النشر الأول، وملف تعريف ارتباط الجلسة مربوط بعنوانه هو. لا تستطيع التطبيقات الوصول إلى بيانات بعضها.
من يستطيع فعل ماذا، مع التحقق على الخادم
ما الذي يسوء
يخفي الذكاء الاصطناعي زر «اعتماد» عن معظم الناس لكنه يترك مسار الاعتماد مفتوحًا لأي شخص سجّل الدخول. أو يثق الخادم بدور أو بريد يرسله المتصفح. ضعف التحكم في الوصول هو الأول في قائمة OWASP Top 10. والمدخلات غير المفحوصة من الفصيلة نفسها: مبلغ سالب، أو استعلام SQL مبني من مربع نص.
تحقق بنفسك
سجّل الدخول كزميل عادي وجرّب ما يجب أن يقتصر على المديرين. اسأل أداة الذكاء الاصطناعي: «لكل مسار API، من يحق له استدعاؤه، وأين يُتحقق من ذلك على الخادم؟ هل تستخدم كل استعلامات قاعدة البيانات عناصر نائبة (placeholders)؟».
على TeamOnly
متكفَّل به جزئيًا. يحصل تطبيقك على الشخص الموثَّق (ctx.user) والأدوار التي توزّعها في لوحة التحكم (ctx.user.roles)، وتُزال ترويسات الهوية المزيّفة. تطلب التعليمات من أداة الذكاء الاصطناعي استخدام العناصر النائبة في الاستعلامات وفحص المدخلات على الخادم. التحقق من الدور في كل مسار مسؤولية شيفرة تطبيقك. TeamOnly لا يراجعها.
كل حزمة حقيقية ولازمة
ما الذي يسوء
تقترح أدوات الذكاء الاصطناعي أحيانًا حزمًا غير موجودة. ينشر المهاجمون حزمًا بتلك الأسماء، فيؤدي تثبيت واحدة منها إلى تشغيل شيفرة غريب داخل تطبيقك.
تحقق بنفسك
افتح package.json. لكل اسم لا تعرفه، ابحث عنه في npmjs.com: الحزمة الحقيقية لها تاريخ، ومستودع شيفرة مصدرية مرتبط، وتنزيلات منتظمة. شغّل npm audit قبل النشر، واحذف الحزم التي لم يعد التطبيق يستخدمها.
على TeamOnly
غير متكفَّل به. TeamOnly لا يفحص الحزم. لا يستطيع التطبيق الوصول إلا إلى بياناته ومفاتيحه، وهذا يحدّ مما يمكن أن تمسّه حزمة سيئة، لكنها داخل ذلك التطبيق قد تقرأ كل شيء.
سجل بمن غيّر ماذا
ما الذي يسوء
شيء يُعتمد أو يُحذف أو يتغير ولا أحد يستطيع أن يقول من فعل ذلك. نادرًا ما تحتفظ التطبيقات المبنية بالذكاء الاصطناعي بسجل ما لم تطلبه.
تحقق بنفسك
اطلب من أداة الذكاء الاصطناعي أن تسجّل من أنشأ كل سجل ومن غيّره آخر مرة، ومتى، وأن تحتفظ بجدول سجل للاعتمادات وعمليات الحذف. جرّب ذلك: غيّر سجلًا، ثم ابحث عن اسمك عليه.
على TeamOnly
متكفَّل به جزئيًا. تعرض لوحة التحكم كل عملية نشر لكل تطبيق، مع من نشر ومتى، وسجلات مباشرة. السجلات مباشرة ولا تُحفظ. سجلات التدقيق لعمليات تسجيل الدخول وتغييرات الوصول ضمن خطة Business، وتُضبط معك. أما السجل داخل التطبيق (من اعتمد مصروفًا) فمسؤولية تطبيقك.
مالك، ونسخة احتياطية، وخطة للمغادرين
ما الذي يسوء
يغادر المُنشئ ويظل التطبيق يعمل على حسابه الشخصي، أو يتوقف عندما تُلغى بطاقته. أو يمسح تغيير سيئ جدولًا ولا توجد نسخة.
تحقق بنفسك
اكتب من يملك التطبيق ومن يتولاه بعده. احتفظ بالشيفرة في مستودع Git تابع للشركة. اطلب من أداة الذكاء الاصطناعي إضافة تصدير CSV للجداول الرئيسية، وجرّبه.
على TeamOnly
متكفَّل به جزئيًا. التطبيقات ملك لشركتك، ويستطيع المسؤولون تسليم تطبيق إلى مالك جديد. تعطيل حساب العمل لشخص ما يوقف عمليات تسجيل الدخول الجديدة. من سجّلوا الدخول بالفعل يبقون حتى تنتهي جلستهم، ويختار المسؤولون مدتها، من 8 ساعات إلى 30 يومًا. لا يوجد اليوم زر نسخ احتياطي أو تصدير في لوحة التحكم، فابنِ التصدير داخل التطبيق.
03اطبع هذا
فحص الدقيقة الواحدة
أحد عشر سؤالًا جوابها نعم أو لا. أي «لا» هو الشيء التالي الذي تصلحه.
قبل أن أشارك هذا التطبيق
نافذة التصفح الخاصة تعرض تسجيل الدخول بحساب الشركة ولا شيء غيره.
حساب Gmail أو Outlook الشخصي يُرفض.
لا يستطيع فتحه إلا من يحتاجون هذه البيانات.
بحث site: عن عنوان التطبيق لا يجد شيئًا.
لا يوجد مفتاح أو رمز أو كلمة مرور في شيفرة المتصفح أو في المستودع.
لا يمكن الوصول إلى قاعدة البيانات دون المرور بالتطبيق.
بيانات هذا التطبيق ومفاتيحه غير مشتركة مع أي تطبيق آخر.
الزميل العادي لا يستطيع فعل ما يجب أن يقتصر على المديرين.
كل حزمة في package.json حقيقية وما زالت مستخدمة.
السجلات تُظهر من أنشأها ومن غيّرها.
شخص آخر يعرف أنه يملك هذا التطبيق إن غادرتُ، والبيانات قابلة للتصدير.
خمس عشرة دقيقة مع المُنشئ، مع مشاركة الشاشة. أنت تتحقق من الإعداد، لا تقرأ كل سطر من الشيفرة.
أين يوجد ومن يمكنه الوصول إليه
احصل على العنوان. افتحه من جهاز لم يسجّل الدخول، ومن حساب شخصي. اسأل أي منصة تستضيفه وأي حساب يدفع ثمنه. الحساب الشخصي أول ما يجب تغييره.
ما البيانات التي يحتويها
اسأل ما الذي يدخل إليه ومن أين يأتي. البيانات الشخصية للعملاء، أو بيانات الدفع، أو البيانات الصحية، أو كلمات مرور أنظمة أخرى ترفع مستوى المتطلبات، وقد تعني أن التطبيق يجب أن يقتصر على قائمة بأسماء محددة.
أين المفاتيح
اذكر كل خدمة خارجية يستدعيها التطبيق. يجب أن يكون كل مفتاح في إعدادات الأسرار لدى المستضيف، بصلاحيات تقتصر على ما يحتاجه التطبيق، وغير مشترك مع تطبيقات أخرى. غيّر أي مفتاح كان في أي وقت في الشيفرة أو في محادثة.
من يستطيع فعل ماذا
اطلب من المُنشئ تسجيل الدخول كمستخدم عادي، أو اطلب ذلك من زميل، وجرّب إجراءات المسؤول. اطلب من المُنشئ أن يجعل أداة الذكاء الاصطناعي تذكر كل مسار API وأين يتحقق من الدور. الثغرات هنا تُصلح في شيفرة التطبيق.
الحزم والشيفرة
انظرا معًا في package.json وشغّلا npm audit. اطلب أن تكون الشيفرة في مستودع Git تابع للشركة، لا على الحاسوب المحمول للمُنشئ فقط.
المالك، ويوم مغادرته
اكتب التطبيق ومالكه ومالكًا احتياطيًا وبياناته ومستخدميه في قائمة تطبيقاتك. اتفقوا على ما يحدث عندما يغادر المالك. في دليل تطبيقات الذكاء الاصطناعي الظلي سياسة من صفحة واحدة يمكنك نسخها.
يمكن أن تكون كذلك. المشكلات الشائعة تتعلق بمكان التطبيق وطريقة إعداده: رابط عام، أو لا تسجيل دخول حقيقي، أو مفاتيح في المتصفح، أو قواعد قاعدة البيانات معطّلة. كل واحدة منها يمكن التحقق منها في دقائق. طبّق قائمة التحقق في هذه الصفحة قبل أن ترسل الرابط.
ما أكبر خطر أمني في تطبيق مبني بأسلوب Vibe Coding؟
بيانات يمكن لأي شخص الوصول إليها دون تسجيل الدخول. يحدث ذلك عادةً بإحدى طريقتين: التطبيق على رابط عام لا يسبقه تسجيل دخول، أو قاعدة البيانات تجيب عن الطلبات مباشرة وقواعد الوصول فيها معطّلة (row-level security في Supabase). الحالتان تتعلقان بالإعداد، لا بكتابة الذكاء الاصطناعي شيفرة سيئة.
هل وضع مفتاح anon من Supabase في المتصفح آمن؟
مفتاح anon أو المفتاح القابل للنشر (publishable) مصمَّم ليكون في المتصفح، لكن فقط لأن row-level security يحدّ مما يمكنه الوصول إليه. إذا كان row-level security معطّلًا على جدول، فأي شخص لديه ذلك المفتاح يستطيع قراءته وتغييره. أما المفتاح السري أو مفتاح service_role فيجب ألا يكون في المتصفح أبدًا: فهو يتجاوز كل القواعد.
هل يقصر «تسجيل الدخول عبر Google» التطبيق على شركتي؟
ليس وحده. افتراضيًا يمكن لأي حساب Google تسجيل الدخول، بما فيه Gmail الشخصي. إعداد hd من Google يضيّق قائمة اختيار الحساب فقط، وGoogle تقول إنه لا ينبغي الاعتماد عليه. يجب أن يتحقق خادم التطبيق من النطاق في رمز تسجيل الدخول الموثَّق مع كل طلب.
كيف أعرف إن كان Google قد فهرس تطبيقي؟
ابحث في Google عن site: متبوعًا بعنوان تطبيقك، مثلًا site:myapp.lovable.app. إذا ظهرت صفحات، فالتطبيق عام ومفهرس. اجعل التطبيق خاصًا أو انقله خلف تسجيل الدخول بحساب الشركة، ثم اطلب من Google إزالة الصفحات بأداة Removals في Search Console إذا كنت تملك النطاق.
هل أطلب من أداة الذكاء الاصطناعي كتابة شيفرة آمنة؟
نعم، ومن الأفضل أن تعطيها تعليمات دائمة بدل أن تطلب مرة واحدة. ملف قواعد في المشروع (CLAUDE.md أو AGENTS.md أو قاعدة في Cursor) يخبر الأداة أين توضع المفاتيح، وكيف تُكتب استعلامات قاعدة البيانات، وأين يُتحقق من الأدوار. يضيف npx teamonly init هذه التعليمات لتطبيقات TeamOnly. ثم طبّق الفحوص بنفسك مع ذلك: التعليمات تقلل الأخطاء ولا تلغيها.
هل يفحص TeamOnly شيفرة تطبيقي بحثًا عن مشكلات أمنية؟
لا. يضع TeamOnly تسجيل الدخول بحساب الشركة أمام كل تطبيق، ويفصل بيانات كل تطبيق ومفاتيحه، ويبقي التطبيقات خارج محركات البحث. لا يراجع شيفرتك، ولا يفحص حزمك، ولا يتحقق من القواعد داخل تطبيقك. تلك البنود في قائمة التحقق تبقى عليك.
ما الذي يجب أن يتحقق منه فريق تقنية المعلومات قبل اعتماد تطبيق مبني بالذكاء الاصطناعي؟
أين يُستضاف ومن يمكنه الوصول إليه، وكيف يُقيَّد تسجيل الدخول، وأين المفاتيح، وما البيانات التي يحتويها، ومن يملكه، وماذا يحدث عندما يغادر ذلك الشخص. قسم «لتقنية المعلومات» في هذه الصفحة مراجعة قصيرة يمكنك إجراؤها في 15 دقيقة مع المُنشئ.