أمان Vibe Coding

قبل أن تغرد معلنًا إطلاقك، نفّذ هذه الفحوصات الـ69. إنها تطابق الأنماط الدقيقة وراء ثغرة Lovable RLS (CVE-2025-48757، أكثر من 170 تطبيقًا، 2025)، وتسريب Moltbook (1.5 مليون رمز API، فبراير 2026)، واختراق منصة Lovable في أبريل 2026 (الكود المصدري + مفاتيح الخدمة لمشاريع مستخدمين آخرين، تعرّضت لنحو 2.5 شهر).

تريد الحزمة الكاملة؟ 50 مهارة تدقيق، 15 ملف .cursorrules، إعداد MCP واحد + 4 وصفات CLI، 30 موجه مراجعة عدائية، 10 دراسات حالة. تثبيت في 5 دقائق. 10 دولارات فقط.

→ rishabhvaai.gumroad.com/l/plddbd

---

في تدقيق نُشر في أكتوبر 2025، فحصت Escape.tech 5,600 تطبيق حقيقي مولّد بالذكاء الاصطناعي عبر 14,600 أصل (المنهجية). وأبلغت عن 2,038 ثغرة حرجة، وأكثر من 400 سر مسرّب، و175 حالة تعرّض لبيانات شخصية (PII) عبر 1,400 من تلك التطبيقات (النتائج). جاءت الأسرار مباشرة من حزم الواجهة الأمامية: مفاتيح Stripe وOpenAI وSupabase موجودة في JavaScript من جانب العميل. لم يتحسن الوضع منذ ذلك الحين: أحصى تقرير GitGuardian لعام 2026 وجود 28.6 مليون سر جديد على GitHub العام في 2025 (زيادة 34% على أساس سنوي)، وارتفاع أسرار خدمات الذكاء الاصطناعي بنسبة 81%، وتسريب الالتزامات (commits) التي شارك في كتابتها وكلاء البرمجة للأسرار بمعدل يبلغ ضعف معدل البشر تقريبًا. هذه قائمة مرجعية من 69 بندًا محددًا وقابلًا للاختبار. كل بند يطابق نمط حادثة حقيقية. إذا استطعت تحديد كل البنود الـ69، فانشر. وإذا لم تستطع، فأصلح ما يعيقك.

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

---

قائمة الفحوصات الأمنية الـ69 قبل الإطلاق

أنت على بُعد 30 دقيقة من النشر. توقف. نفّذ هذا أولًا.

ثغرة Lovable RLS وحدها (CVE-2025-48757، 2025، CVSS 9.3) كشفت أكثر من 170 تطبيق إنتاج. وكشف Moltbook 1.5 مليون رمز API في فبراير 2026 — يمكن الاستعلام عنها بأمر curl واحد. لم تكن هذه حالات حافة. بل كانت عمليات إطلاق سائدة.

تجمّع هذه القائمة 69 بندًا محددًا وقابلًا للاختبار عبر المصادقة والأسرار وواجهات API وقواعد البيانات والواجهة الأمامية والذكاء الاصطناعي/LLM وأدوات الوكلاء والنشر. إذا لم تستطع تحديد كل البنود الـ69، فلا تنشر.

---

المصادقة (8 بنود)

• 1. أمان مستوى الصفوف في قاعدة البيانات (RLS) مفعّل على كل جدول في قاعدة بياناتك.
• 2. توجد سياسات RLS لكل جدول ولكل دور (anon، authenticated، service_role).
• 3. يتم التحقق من رموز JWT من جانب الخادم على كل مسار API محمي (لا تثق أبدًا في الواجهة الأمامية للتحقق من المصادقة).
• 4. يتم تدوير الجلسات أو إبطالها بعد تسجيل الدخول (حماية من CSRF وتثبيت الجلسة).
• 5. الروابط السحرية (مصادقة بدون كلمة مرور) مخصصة للاستخدام مرة واحدة، وتنتهي صلاحيتها في أقل من 15 دقيقة، ومرتبطة بعنوان IP الخاص بالمستخدم أو بصمة الجهاز.
• 6. لا يمكنك تحديث أو حذف المستخدمين أو الطلبات أو السجلات الحساسة بناءً على المعرّفات المقدمة من المستخدم وحدها. الاختبار: حاول تحديث سجل مستخدم آخر بتغيير المعرّف في الطلب.
• 7. يتم التحقق من رموز CSRF في الطلبات التي تغيّر الحالة (POST، PUT، DELETE) عبر ملف تعريف ارتباط مزدوج الإرسال أو SameSite=Strict.
• 8. تحتوي ملفات تعريف ارتباط الجلسة على العلامات HttpOnly وSecure وSameSite=Strict.

الأسرار والبيئة (7 بنود)

• 9. لا أسرار في متغيرات NEXT_PUBLIC_* أو ملفات .env الخاصة بـ Vue/React أو سلاسل نصية مكتوبة بشكل ثابت. ابحث بـ NEXT_PUBLIC_ ودقق في كل المتغيرات.
• 10. ملفات .env و.env.local و.env.*.local موجودة في .gitignore ولا تُرسل أبدًا إلى المستودع. تحقق من سجل git: git log --all -p | grep -i "api_key\|secret".
• 11. مفتاح service_role في Supabase موجود فقط في .env من جانب الخادم (Node، Python، Go، إلخ)، ولا يُوضع أبدًا في حزم الواجهة الأمامية أو .env.local. مفتاح service_role يتجاوز RLS بالكامل — تسريب واحد يعني قراءة/كتابة كاملة لكل جدول.
• 12. مفاتيح Stripe: المفتاح العام في NEXT_PUBLIC_*، والمفتاح السري للخادم فقط، مع التحقق من توقيع webhook.
• 13. مفاتيح OpenAI وAnthropic وxAI API ليست في كود الواجهة الأمامية أبدًا؛ تُمرَّر دائمًا عبر API الخاص بك كوسيط.
• 14. لا مفاتيح API مكتوبة بشكل ثابت، ولا روابط قواعد بيانات، ولا بيانات اعتماد في أي مكان في المصدر (بما في ذلك التعليقات والكود غير المستخدم).
• 15. يتم تدوير الأسرار بعد الإطلاق أو إذا تعرضت للكشف في تاريخ المصدر.

تحصين API (10 بنود)

• 16. تحديد المعدل (Rate limiting) مفعّل على /api/auth/* و/api/login و/api/register. الاختبار: 100 طلب/دقيقة يجب أن يُرجع 429.
• 17. يتم التحقق من كل مدخلات المستخدم إلى /api/* باستخدام Zod أو Yup أو ما يشابههما قبل لمس قاعدة البيانات. لا يُمرَّر req.body خام إلى الاستعلامات.
• 18. لا تعيين جماعي: لا يمكن للمستخدم تعيين admin=true أو role=admin أو حقول حساسة أخرى بإرسالها عبر POST.
• 19. يتم التحقق من توقيعات Webhook (قارن رأس توقيع HMAC-SHA256 بالقيمة المتوقعة باستخدام مقارنة في زمن ثابت).
• 20. CORS غير مضبوط على *. الأصول المسموح بها مكتوبة بشكل ثابت ولا تتضمن localhost في بيئة الإنتاج.
• 21. تستخدم استعلامات SQL عبارات معلمة فقط. لا دمج لسلاسل مدخلات المستخدم في SQL.
• 22. لا تدمج استعلامات NoSQL (MongoDB وFirebase وغيرها) مدخلات المستخدم في عوامل التصفية أو المحددات.
• 23. يتم التحقق من رفع الملفات (نوع mime + حجم الملف)، وتخزينها خارج جذر الويب، وإعادة تسميتها لمنع اجتياز المسار (path traversal).
• 24. عمليات إعادة التوجيه بعد تسجيل الدخول في قائمة بيضاء. لا يمكن إعادة التوجيه إلى نطاق خارجي عبر إعادة توجيه مفتوحة.
• 25. لا يقوم API بطلبات خارجية غير موثقة. تأكد من أن الروابط المستخدمة في الطلبات من جانب الخادم تأتي من قائمتك المسموح بها، وليس من مدخلات المستخدم (منع SSRF).

قاعدة البيانات (6 بنود)

• 26. RLS مفروض على كل الجداول. لا يمكن لدور anon تنفيذ SELECT/INSERT/UPDATE/DELETE على أي جدول بدون سياسة صريحة تمنحه ذلك.
• 27. لا يملك دور anon العام أي صلاحيات افتراضية. تمنح السياسات ما هو مطلوب فقط. قراءة فقط على القوائم العامة، ولا كتابة أبدًا.
• 28. يُستخدم مفتاح service-role فقط في كود جانب الخادم. تحقق: grep -r "service_role" src/. يجب أن يُرجع صفر نتائج في ملفات الواجهة الأمامية.
• 29. عزل بيانات المستخدم: تقوم الاستعلامات دائمًا بالتصفية عبر auth.uid() أو team_id. لا يُرجع أي استعلام كل السجلات عبر كل المستخدمين.
• 30. الحذف الناعم (علامة is_deleted) أو جداول الأرشفة يمنع فقدان البيانات العرضي. يتم تسجيل الحذف القاسي مع الفاعل + الطابع الزمني.
• 31. توجد نسخ احتياطية لقاعدة البيانات وتم اختبارها. تحققت من قدرتك على الاستعادة من النسخة الاحتياطية قبل هذا الإطلاق.

الواجهة الأمامية (8 بنود)

• 32. لا dangerouslySetInnerHTML أو innerHTML بدون تنقية DOMPurify. دقق في كل حالة في قاعدة الكود.
• 33. يتم فحص كل تبعيات npm/pip/gem بحثًا عن CVEs معروفة. نفّذ npm audit أو pnpm audit أو npx osv-scanner --lockfile=package-lock.json قبل الإطلاق — وتحقق من الإصدارات المحددة في KNOWN-VULNERABLE-VERSIONS.md، لأن npm audit يلتقط CVEs المنشورة وليس الحزم الخبيثة.
• 34. سياسة أمان المحتوى (CSP) مفعّلة في بيئة الإنتاج (strict-dynamic، بدون unsafe-inline). اختبرها في بيئة التدريج أولًا.
• 35. لا توجد نقاط نهاية /api/debug أو /admin/backdoor أو نقاط نهاية اختبار داخلية يمكن الوصول إليها في بيئة الإنتاج. ابحث بـ grep عن مسارات "debug" و"mock" و"test-only".
• 36. تم تعيين X-Frame-Options: DENY. تحقق من إرسال الرأس في كل استجابة (يمنع clickjacking).
• 37. لا تسرّب رسائل الخطأ المسارات الداخلية أو تتبعات المكدس أو مخطط قاعدة البيانات في بيئة الإنتاج. اختبر أخطاء 404 و500 وأخطاء الصلاحيات.
• 38. لا تلوث للنموذج الأولي (prototype pollution): لا يتم دمج الكائنات المقدمة من المستخدم في كائنات التطبيق بدون تنقية.
• 39. React: لا معالجات أحداث مضمّنة مع بيانات مستخدم غير منقاة. استخدم react-dompurify أو ما يعادله لأي محتوى مستخدم يُعرض كـ HTML.

الذكاء الاصطناعي وLLM (10 بنود)