إذا كنت قد قمت بترميز تطبيق باستخدام Claude أو Cursor وأنت على وشك تسليمه لعميل يدفع، توقف. يأتي الكود الذي ينتجه الذكاء الاصطناعي مع ثغرات أمنية يمكن التنبؤ بها — مفاتيح API مكشوفة، والتحقق من المدخلات مفقود، أذونات قاعدة البيانات الافتراضية التي تسمح لأي مستخدم برؤية بيانات الآخرين. هذه ليست حالات حدية. تحدث في كل قاعدة كود تقريباً ينتجها الذكاء الاصطناعي في المحاولة الأولى.
هذا الدليل هو قائمة التحقق من الأمان قبل الإطلاق. اتبعها خطوة بخطوة قبل أن يلمس أي مستخدم حقيقي تطبيقك. تم كتابته لأكثر مكدس ترميز حسي شيوعاً (Next.js + Supabase + Vercel)، لكن المبادئ تنطبق بغض النظر عن الأدوات التي تستخدمها.
لماذا يحتوي الكود الذي ينتجه الذكاء الاصطناعي على مشاكل أمنية
تحسين نماذج الذكاء الاصطناعي لـ "هل يعمل؟" وليس "هل هو آمن؟" عندما تخبر Claude "بناء مدير مهام مع حسابات المستخدمين"، سيقوم بإنشاء كود ينشئ مستخدمين، ويخزن المهام، ويعرضها. ما لن يفعله تلقائياً على الأرجح: التأكد من أن المستخدم أ لا يمكنه رؤية مهام المستخدم ب، التحقق من أن حقول الإدخال لا تقبل نصوص ضارة، إخفاء مفاتيح API الخاصة بك عن أدوات مطور المتصفح، أو إضافة حدود معدل لمنع شخص ما من إرسال طلبات متكررة إلى نقاط نهايتك.
هذه ليست إخفاقات الذكاء الاصطناعي — إنها فجوات في الحث. يبني الذكاء الاصطناعي ما طلبت منه. ربما لم تطلب الأمان لأنك كنت تركز على الميزات. الآن حان الوقت للعودة وإضافته.
الخطوة 1: تدقيق متغيرات البيئة الخاصة بك
هذا هو الخطأ الأكثر شيوعاً والأخطر في التطبيقات المرمزة حسياً. تحقق من كل ملف في مشروعك بحثاً عن مفاتيح API أو عناوين قواعد البيانات أو أسرار مرمزة بشدة.
ما تبحث عنه: ابحث في قاعدة الكود الخاصة بك عن السلاسل التي تبدأ بـ sk-, eyJ, sbp_, supabase, postgres://, أو أي سلاسل طويلة تبدو عشوائية. تحقق من هذه الملفات بشكل خاص: أي ملف في مجلد /app أو /pages، أي ملف مكون، ملف next.config.js، وأي ملفات مساعدة.
الحل: انقل كل سر إلى متغيرات البيئة. في Next.js، فقط المتغيرات التي تبدأ بـ NEXT_PUBLIC_ يتم الكشف عنها للمتصفح. عنوان قاعدة البيانات الخاصة بك ومفتاح دور الخدمة وأسرار API لا يجب أن يكون لديها هذا البادئة.
# .env.local (لا تقم أبداً بارتكاب هذا الملف)
SUPABASE_SERVICE_ROLE_KEY=your-secret-key
DATABASE_URL=postgres://...
# هذه على ما يرام للكشف عنها للمتصفح:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-keyتحقق: تحقق من أن ملف .gitignore الخاص بك يتضمن .env.local. إذا كنت قد ارتكبت بالفعل أسرار إلى Git، فإنها موجودة في سجلك حتى بعد الحذف — قم بتدوير (إعادة تسجيل) كل مفتاح مكشوف على الفور.
الخطوة 2: تفعيل أمان مستوى الصف في Supabase
هذه هي الخطوة الأكثر أهمية بشكل فردي إذا كنت تستخدم Supabase. بشكل افتراضي، جداول Supabase لا توجد قيود الوصول — أي شخص لديه مفتاحك المجهول يمكنه قراءة وكتابة كل صف في كل جدول. هذا يعني أن المستخدم أ يمكنه رؤية بيانات المستخدم ب برسالة API بسيطة.
الحل: تفعيل أمان مستوى الصف (RLS) في كل جدول، ثم إنشاء سياسات تقيد الوصول.
انتقل إلى لوحة التحكم الخاصة بك Supabase → محرر الجدول → حدد كل جدول → انقر على "RLS معطل" لتفعيله. ثم أضف السياسات:
بالنسبة لتطبيق نموذجي حيث يجب على المستخدمين رؤية بياناتهم فقط، أنشئ سياسة SELECT: auth.uid() = user_id. أنشئ سياسات مماثلة لـ INSERT و UPDATE و DELETE.
اختبره: قم بتسجيل الدخول كمستخدم أ، حاول الوصول إلى بيانات المستخدم ب من خلال API. إذا كان بإمكانك رؤيتها، فإن سياساتك خاطئة. يحتوي Supabase على محرر SQL حيث يمكنك اختبار السياسات مباشرة.
خطأ الذكاء الاصطناعي الشائع: غالباً ما يقوم Claude بإنشاء استعلامات Supabase باستخدام مفتاح service_role (الذي يتجاوز RLS) بدلاً من مفتاح anon مع سياسات RLS المناسبة. تحقق من أن الكود من جانب العميل الخاص بك يستخدم مفتاح anon فقط. يجب أن يكون مفتاح دور الخدمة موجوداً فقط في الكود من جانب الخادم (مسارات API، إجراءات الخادم) وليس أبداً يتم الكشف عنه للمتصفح.
الخطوة 3: إضافة المصادقة بشكل صحيح
يعمل كود المصادقة الذي ينتجه الذكاء الاصطناعي غالباً لكنه يأخذ اختصارات. تحقق من هذه المشاكل المحددة:
إدارة الجلسة: تأكد من انتهاء الجلسات. تحقق من أن إعداد المصادقة الخاص بك يتضمن انتهاء جلسة معقول (قيم Supabase الافتراضية عادة ما تكون جيدة، لكن تحقق). تأكد من أن تسجيل الخروج يبطل الجلسة فعلاً، وليس فقط مسح ملف تعريف الارتباط المحلي.
متطلبات كلمة المرور: إذا كان لديك مصادقة البريد الإلكتروني / كلمة المرور، فرض طول كلمة المرور الأدنى (8+ أحرف). يتعامل Supabase مع هذا في إعدادات المشروع الخاص بك → المصادقة → متطلبات كلمة المرور.
المسارات المحمية: كل صفحة تعرض بيانات خاصة بالمستخدم تحتاج إلى برمجيات وسيطة للمصادقة. في Next.js App Router، أنشئ برمجيات وسيطة تتحقق من جلسة صحيحة وتعيد توجيه المستخدمين غير المصرح لهم إلى صفحة تسجيل الدخول. لا تعتمد على الفحوصات من جانب العميل وحدها — يمكن للمستخدم أن يتجاوزها بالوصول المباشر إلى API الخاص بك.
التحقق من البريد الإلكتروني: تفعيل تأكيد البريد الإلكتروني في إعدادات Supabase Auth. هذا يمنع الأشخاص من إنشاء حسابات بعناوين بريد إلكترونية وهمية ويضيف طبقة أساسية من صحة الحساب.
تحصل على القيمة من هذا؟ ننشر غوص عميق واحد في الأسبوع عن أدوات الذكاء الاصطناعي وسير العمل والأدلة العملية. انضم إلى القراء الذين يحصلون عليه أولاً →
الخطوة 4: التحقق من جميع المدخلات
عادة ما يحتوي النماذج التي ينتجها الذكاء الاصطناعي على تحقق أساسي (الحقول المطلوبة وتنسيق البريد الإلكتروني) ولكن نادراً ما تحمي من المدخلات الضارة.
ما يجب إضافته:
التحقق من جانب الخادم في كل نقطة نهاية API. لا تثق في التحقق من جانب العميل وحده — يمكن تجاوزه بإرسال طلبات مباشرة إلى API الخاص بك. استخدم مكتبة تحقق مثل Zod (لـ TypeScript) لتحديد المخططات لكل جزء من البيانات التي يقبلها تطبيقك.
تطهير HTML في أي محتوى ينتجه المستخدم يتم عرضه. إذا كان لتطبيقك تعليقات أو أوصاف أو أي حقل نص يتم عرضه في المتصفح، فاستخدم مكتبة مثل DOMPurify لتجريد النصوص البرمجية الخطرة. بدون هذا، يمكن لشخص ما حقن JavaScript يسرق جلسات المستخدمين الآخرين (Cross-site scripting / XSS).
حد من حجم نوع الملف إذا كان تطبيقك يقبل تحميلات الملفات. معالجات التحميل التي ينتجها الذكاء الاصطناعي غالباً لا توجد حدود، مما يعني أن شخص ما يمكنه تحميل ملف 2GB أو ملف قابل للتنفيذ. أضف حدود الحجم (5MB معقولة لمعظم التطبيقات) وقيد أنواع الملفات لما تحتاجه فعلاً (الصور وملفات PDF وما إلى ذلك).
الخطوة 5: تأمين مسارات API الخاصة بك
تحقق من كل مسار API أو إجراء خادم في التطبيق الخاص بك بحثاً عن هذه المشاكل:
المصادقة في كل نقطة نهاية. كل مسار API يعود ببيانات المستخدم أو يعديلها يجب أن يتحقق من جلسة المستخدم أولاً. يولد الذكاء الاصطناعي غالباً مسارات API التي تقبل الطلبات من أي شخص.
التفويض بما يتجاوز المصادقة. حتى بعد تأكيد أن المستخدم مسجل دخول، تحقق من أنهم مسموح لهم بالوصول إلى المورد المحدد الذي يطلبونه. "المستخدم أ مسجل دخول" لا يعني "المستخدم أ يمكنه تحرير ملف تعريف المستخدم ب." تحقق من الملكية عند كل وصول بيانات.
حد المعدل. بدون حد المعدل، يمكن لشخص ما إرسال آلاف الطلبات في الثانية إلى API الخاص بك، إما لكشط البيانات أو للإرهاق بخادمك. أضف حد معدل أساسي باستخدام مكتبة مثل rate-limiter-flexible أو استخدم حد المعدل المدمج في Vercel على Edge Functions.
طرق HTTP. تأكد من أن مسارات API الخاصة بك تستجيب فقط لطرق HTTP التي يجب أن تستجيب لها. لا يجب أن يرد مسار يتعامل مع طلبات POST على طلبات DELETE ما لم تقم بتصميمه صراحة للقيام به.
الخطوة 6: تحقق من تكوين النشر الخاص بك
لديك منصة النشر الخاصة بك إعدادات أمان لا يقوم الذكاء الاصطناعي بتكوينها لك.
إعدادات Vercel المراد التحقق منها: تفعيل "حماية النشر" (يتطلب المصادقة لعرض نشرات المعاينة — يمنع العملاء من مشاركة عناوين URL للمعاينة عن طريق الخطأ التي تكشف العمل الجاري). قم بإعداد حدود الإنفاق لمنع الرسوم غير المتوقعة إذا حصل التطبيق الخاص بك على طفرات حركة المرور. قم بتكوين نطاقاتك المسموحة في رؤوس CORS.
النطاق المخصص و SSL: إذا كنت تسلم هذا لعميل، فقم بإعداد النطاق المخصص الخاص بهم باستخدام HTTPS. يتعامل Vercel و Netlify مع SSL تلقائياً. لا تسلم تطبيق عميل أبداً على نطاق فرعي .vercel.app — يبدو غير احترافي والعميل لا يمكنه نقله بسهولة.
الرؤوس: أضف رؤوس الأمان إلى next.config.js أو vercel.json: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (يمنع موقعك من كونه مدمجاً في iframes للهجوم بالنقر)، Strict-Transport-Security (يفرض HTTPS). هذه إضافات لمرة واحدة تمنع فئات كاملة من الهجمات.
الخطوة 7: قم بإجراء فحص أمان نهائي
قبل تسليم أي شيء لعميل، قم بتشغيل هذه الفحوصات المجانية:
npm audit: قم بتشغيل npm audit في مجلد المشروع الخاص بك. يشير إلى الثغرات المعروفة في التبعيات الخاصة بك. أصلح المشاكل الحرجة والعالية الخطورة. قم بتشغيل npm audit fix للإصلاحات التلقائية حيث يتوفر.
Lighthouse: افتح موقعك المنشور في Chrome، افتح DevTools، قم بتشغيل تدقيق Lighthouse. تحقق من درجة "أفضل الممارسات" — يمسك المشاكل الأمان الشائعة مثل HTTPS المفقود، والمكتبات الضعيفة، ورؤوس غير آمنة.
الاختبار اليدوي: قم بتسجيل الدخول كمستخدم واحد، حاول الوصول إلى بيانات مستخدم آخر بتعديل عناوين URL أو استدعاءات API. حاول تقديم نماذج فارغة ومدخلات كبيرة الحجم وأحرف خاصة (مثل حمولات XSS المشفرة). إذا كان أي من هذه يعمل، لديك مشاكل للإصلاح.
قائمة التحقق قبل الإطلاق
اطبع هذا وتحقق من كل عنصر قبل الانتقال للعمل:
- جميع الأسرار في متغيرات البيئة (لا توجد مفاتيح مرمزة بشدة)
.env.localفي.gitignore(وليس أي أسرار في سجل Git)- Supabase RLS ممكن في كل جدول
- سياسات RLS تم اختبارها (المستخدم أ لا يمكنه رؤية بيانات المستخدم ب)
- الكود من جانب العميل يستخدم مفتاح anon فقط (مفتاح دور الخدمة من جانب الخادم فقط)
- المصادقة في كل مسار API
- فحوصات التفويض (التحقق من الملكية) على وصول البيانات
- التحقق من المدخلات في كل نموذج (من جانب الخادم، وليس من جانب العميل فقط)
- حدود تحميل الملفات (الحجم والنوع) إن أمكن
- حد المعدل في نقاط نهاية API
- رؤوس الأمان المكونة
npm auditتم التشغيل والمشاكل الحرجة تم إصلاحها- نطاق مخصص مع SSL محتوى
- نشرات المعاينة محمية
- اختبار الوصول المتقاطع للبيانات اليدوي نجح
النقطة الأساسية
تأمين تطبيق مرمز حسياً لا يتعلق بأن تصبح خبيراً في الأمان. يتعلق بتشغيل قائمة تحقق تمسك الفجوات التنبؤية التي يتركها الذكاء الاصطناعي. الخطوات أعلاه تأخذ 2-4 ساعات وتمنع أكثر الثغرات شيوعاً. بالنسبة لتطبيق يواجه العميل، هذا ليس اختياراً — إنه الفرق بين العمل الاحترافي والمسؤولية.
إذا كنت تقوم ببناء تطبيقك المرمز حسياً الأول، ابدأ بـ دليلنا الكامل للترميز الحسي. إذا كنت تريد تحسين الحث الذي تستخدمه مع Claude أو Cursor، جرب محسِّن الحث المجاني. وللحصول على تفصيل أدوات الترميز الأفضل، راجع Claude Code مقابل Codex.
هذا ما نفعله كل أسبوع. غوص عميق واحد على أدوات الذكاء الاصطناعي وسير العمل والآراء الصريحة — بدون إثارة، بدون مواد حشو. انضم إلينا →
إفصاح: بعض الروابط في هذه المقالة هي روابط تابعة. ننصح فقط بالأدوات التي اختبرناها شخصياً واستخدمناها بانتظام. راجع سياسة الإفصاح الكاملة الخاصة بنا.