USالمقر الرئيسي
الولايات المتحدة
فلوريدا
EST • UTC−5·الاثنين-الجمعة • 9:00، 18:00
الكود المولَّد بالذكاء الاصطناعيتدقيق أمني
الكود الذي يكتبه الذكاء الاصطناعي يبدو غالباً أفضل مما حلّ محله: مكوّنات نظيفة وتسميات منطقية وTypeScript حقيقي. ما لا يكتبه هو طبقة الصلاحيات، ولا ينتبه أحد لأن الواجهة تُخفي كل زر لا يملك المستخدم صلاحيته. نحن ندقّق هذه الأكواد بحثاً عن الأعطال التي لا تظهر إلا حين يتجاوز أحدهم الواجهة تماماً.
v0 · Cursor · Copilot · Claude Codeتقرير التدقيق خلال 3 أيام عملسعر ثابت معلن مسبقاًالمستودع يبقى ملكك
INNOVATION
SCALE
Global Reach
Overview
الكود سليم. الصلاحيات ليست كذلك.
هذا هو الجزء الذي يفاجئ الناس. الكود الذي يولّده v0 أو يُكتب بمساعدة Cursor يكون عادةً جيّد البنية: مُنمّط، مقسّم إلى مكوّنات، وأقرب إلى أعراف أطر العمل الحديثة من كثير من الكود المكتوب يدوياً. ولهذا تحديداً تمرّ الثغرة دون ملاحظة وقتاً طويلاً، إذ لا يوجد شيء يبدو خاطئاً للعين.
حلّلنا تحليلاً ساكناً تسعة مشاريع v0 حقيقية ومنشورة. فيها جميعاً، 360 من أصل 436 مكوّناً تحمل التوجيه "use client" — أي 83% من التطبيق يعمل داخل المتصفح، ووصل أحد المشاريع إلى 95%. في تطبيق Next.js هذا ليس خياراً جمالياً، بل هو ما يحدّد أين يمكن أن يوجد حدّ الأمان أصلاً. أما العلامة التي تمنع وصول وحدة برمجية إلى المتصفح، server-only، فقد ظهرت في مشروع واحد من تسعة.
ثم نظرنا في Server Actions. مشروع واحد يكشف 16 إجراءً موزّعة على 13 ملفاً دون أي تحقق من الصلاحيات في أيٍّ منها، ومن بينها delete-establishment.ts. ومشروع آخر فيه 31 إجراءً مع تحققات في ملف واحد فقط؛ أما createUser وdeleteUser فبلا أي تحقق، وكلاهما يعمل عبر عميل Supabase بصلاحية service-role يذكر تعليقٌ في الكود نفسه أنه يتجاوز أمان مستوى الصف. وفي التطبيق ذاته، أزرار الحذف والتعديل مخفية بشكل صحيح خلف خطّاف usePermissions في المتصفح. الواجهة مقفلة. نقاط النهاية ليست كذلك.
توثّق Vercel هذا بدقة، ومن الأفضل قراءته بكلماتهم لا بكلماتنا: «حين يُنشأ Server Action ويُصدَّر، يصبح قابلاً للوصول عبر طلب POST مباشر، لا عبر واجهة تطبيقك فقط»، و«التحقق من الهوية على مستوى الصفحة لا يمتدّ إلى Server Actions المعرّفة داخلها». الـ middleware الذي أضفته يحمي التنقّل بين الصفحات، ولا يستطيع حماية إجراء.
ما الذي نجده فعلياً
Server Actions بلا تحقق من الصلاحيات
أكثر النتائج الحرجة تكراراً. كل إجراء مُصدَّر هو نقطة POST عامة. نحصرها جميعاً، ونختبر كلاً منها مباشرة دون المرور بالواجهة، ونبلّغك أيها يعدّل أو يحذف بيانات لمستدعٍ غير موثّق.
غياب التحقق من ملكية المورد
إجراء يتحقق من أنك مسجّل الدخول، لكنه لا يتحقق من أن السجل يخصّك. غيّر معرّفاً واحداً في جسم الطلب وستكون تعدّل بيانات عميل آخر. قائمة تدقيق Vercel نفسها تنبّه إلى هذا، ولا يكاد يطبّقه شيء مما يولّده الذكاء الاصطناعي.
عملاء بصلاحية service-role في متناول مدخلات المستخدم
عميل قاعدة بيانات يتجاوز أمان مستوى الصف بحكم تصميمه، يُنشأ داخل معالج يستطيع أي مستدعٍ الوصول إليه. سياسات RLS الصحيحة لا قيمة لها أمامه. نتتبّع كل عميل مميّز رجوعاً إلى الطلب الذي يمكن أن يشغّله.
انهيار الحد بين المتصفح والخادم
حين يعمل 83% من مكوّناتك في المتصفح، تتسرّب الأسرار وقواعد العمل ومنطق الصلاحيات إلى الحزمة. نرسم الحدّ من جديد، ونعزل الوصول إلى البيانات خلف طبقة خادم فقط، ونفحص ما تُرسله خصائص المكوّنات فعلياً إلى المتصفح.
مخاطر الاعتماديات وسلسلة التوريد
أدوات الذكاء الاصطناعي تخترع حزماً غير موجودة. في 576,000 عيّنة مولَّدة وجد الباحثون 205,474 اسم حزمة مختلقاً، و43% منها تكرّر في كل إعادة تشغيل — وهو ما يجعل تسجيل الاسم مغرياً لمهاجم. نفحص ما ثُبِّت لديك فعلاً.
ثغرات أطر العمل التي ورثتها
الثغرة CVE-2025-55182 في React Server Components سُجّلت بدرجة 10.0 وأُدرجت في قائمة CISA للثغرات المستغلّة فعلياً. وهي تطال تطبيقات Next.js App Router المبنية على React 19.0–19.2. نفحص ملف القفل لديك في مواجهتها وغيرها، ونحدّد أيها يعرّضه نشرك الحالي فعلاً.
نطبّق قائمة تدقيق Vercel نفسها على كودك
- عزل الوصول إلى البيانات خلف طبقة مخصّصة بدل تناثره بين المكوّنات
- لكل تصدير "use server": التحقق من الوسائط، وإعادة التحقق من الصلاحيات، وملكية المورد، وتصفية القيم المُعادة
- لكل حدّ "use client": ما الخصائص التي تعبره فعلاً، وأيها ما كان ينبغي أن يعبر
- التحقق من معاملات المسارات الديناميكية بدل الثقة بها
- فحص معالجات proxy.ts وroute.ts (أعاد Next.js 16 تسمية middleware.ts، فالتطبيقات الموروثة خليط بين الاثنين)
- تدقيق ملف القفل في مواجهة تنبيهات أطر العمل والاعتماديات المعروفة
ما الذي لن نقوله لك
لن نقول إن الثغرة CVE-2025-29927 في middleware الخاص بـ Next.js جعلت تطبيقك المستضاف على Vercel قابلاً للاستغلال. لم تفعل — فقد حمت Vercel التطبيقات المستضافة لديها عند الحافة. تهمّ هذه الثغرة إن كنت قد صدّرت التطبيق وتستضيفه بنفسك، وتهمّ كدرس في أن middleware ليس المكان المناسب لتحققك الوحيد من الصلاحيات. هذا كل ما في الأمر.
ولن نقول إن v0 يسرّب أسرارك عبر متغيّرات NEXT_PUBLIC_. بحثنا فلم نجد حالة واحدة. Next.js يستبدل المتغيّرات غير المسبوقة بهذه البادئة بسلسلة فارغة في المتصفح. هذا الادعاء منتشر وهو غير صحيح.
ولن نقول إن هناك حالة موثّقة لكود مولَّد بـ v0 تسبّب بفاتورة استضافة خارجة عن السيطرة. لم نستطع التحقق من أي حالة. الفاتورة الشهيرة البالغة 96,280 دولاراً حقيقية لكنها لم تكن تطبيق v0.
نفضّل خسارة الصفقة على أن نقدّم لمؤسس تقني صفحة يستطيع دحضها في عشر دقائق.
أسئلة عن تدقيق كود الذكاء الاصطناعي
أداة الفحص تقرأ الأنماط. والنتائج أعلاه ليست مطابقات أنماط — فـ Server Action مُصدَّر بلا تحقق يبدو مطابقاً تماماً لآخر فيه تحقق على بُعد ثلاثة أسطر داخل دالة مساعدة. نحن نحصر كل إجراء، ونتتبّع من يستطيع الوصول إليه، ونختبره مباشرة. كما أن أدوات الفحص لا تستطيع إخبارك بأن خطّاف صلاحيات يقفل الزر بينما نقطة النهاية خلفه مفتوحة، لأن كلا الملفين صحيح على حدة.
نمط العطل واحد لكن السبب مختلف. مع v0 لم يكتب المولّد طبقة صلاحيات أصلاً. ومع Cursor كان هناك إنسان في الحلقة، فما يتراكم بدلاً من ذلك هو كود لا يفهمه أحد بالكامل: أنماط غير متسقة، ومنطق مكرّر، واختبارات لا تتحقق من شيء يُذكر. بحث على اختبارات كتبها وكلاء ذكاء اصطناعي عبر 33,596 طلب دمج وجد أن 80.2% منها تحتوي إشارات تحقق ضعيفة أو معدومة. ندقّق الحالتين، والتقرير يختلف.
الاثنان معاً، والجانب المتعلق بالمحرّر لا يُناقش بما يكفي. هناك 22 ثغرة مسجّلة على Cursor، ثمانٍ منها تصنّفها NVD حرجة — ونحن نذكر درجة NVD الأساسية عن قصد، لأن الدرجات التي تسندها الجهة المطوّرة لنفس الثغرات تقلّ عنها بنقطة إلى ثلاث. والنمط أهم من أي إدخال منفرد: قائمة الأوامر المسموح بها، والصندوق الرملي، وملف .cursorignore، ونافذة الموافقة — كلّها صدرت لها ثغرة بسبب إمكان تجاوزها. وبشكل منفصل، أثبتت Pillar Security في مارس 2025 أن تعليمات مخبّأة في ملف .cursor/rules باستخدام محارف عديمة العرض تكون غير مرئية في المحرّر وفي فروقات طلب الدمج على GitHub معاً. وكان موقف Cursor أن هذه المخاطرة تقع على مسؤولية المستخدم.
سعر ثابت قدره 1,500 دولار لتدقيق مدّته ثلاثة أيام، وتُخصم قيمته من كلفة الإصلاح إن تابعت معنا. تحصل على تقرير مفصّل: كل نتيجة ودرجة خطورتها والملف والسطر، مع توصية بالإصلاح أو إعادة البناء وأسبابها موضّحة. أسعار مراحل الإصلاح كاملة منشورة على صفحة الإنقاذ الرئيسية.
في الغالب لا، وهذه إجابة صادقة لا بيعية. الكود الجيّد التوليد الذي تنقصه طبقة الصلاحيات مرشّح جيّد للإصلاح، فبنيته سليمة والجزء الناقص إضافي. نوصي بإعادة البناء حين ينحرف نموذج البيانات بما يكفي ليصبح ترحيله أكلف من إعادة كتابة طبقة الخدمة، وحين نوصي بذلك نعرض عليك المنطق بدل أن نطلب تصديقه.
لا. يجري التدقيق على المستودع، وعلى نسخة تجريبية إن أردت اختبار نقاط النهاية. لا نطلب بيانات اعتماد الإنتاج إطلاقاً. يبقى مستودعك ملكك طوال الوقت، ونعمل داخل فرع مستقل.
جاهزون لتحويل عملكم؟
لنناقش كيف يمكننا إنشاء حل مخصص مدعوم بـ GPT ومصمم خصيصاً لاحتياجاتكم الخاصة وتحديات قطاعكم.
