إذا كنت قد برمجت تطبيقاً بشكل سريع مع Claude أو Cursor وأنت على وشك تسليمه لعميل يدفع ثمنه، توقف. الكود الذي تنتجه الذكاء الاصطناعي يأتي مع ثغرات أمان يمكن التنبؤ بها — مفاتيح API مكشوفة، التحقق من صحة الإدخال ناقص، أذونات قاعدة بيانات افتراضية تسمح لأي مستخدم برؤية بيانات جميع المستخدمين الآخرين. هذه ليست حالات استثنائية. إنها تحدث في كل تقريباً كود أولي تنتجه الذكاء الاصطناعي.
هذا الدليل هو قائمة التحقق من الأمان قبل الإطلاق. اتبعها خطوة بخطوة قبل أن يلمس أي مستخدم حقيقي تطبيقك. تم كتابتها لأكثر مجموعات البرمجة السريعة شيوعاً (Next.js + Supabase + Vercel)، لكن المبادئ تنطبق بغض النظر عن الأدوات التي تستخدمها.
لماذا يحتوي الكود الذي تنتجه الذكاء الاصطناعي على مشاكل الأمان
نماذج الذكاء الاصطناعي تحسّن "هل يعمل؟" وليس "هل هو آمن؟" عندما تخبر Claude "بناء لي مدير مهام مع حسابات المستخدمين"، سيقوم بإنشاء كود ينشئ المستخدمين ويخزن المهام ويعرضها. ما لن يفعله تلقائياً على الأرجح: ضمان عدم رؤية المستخدم أ لمهام المستخدم ب، التحقق من أن حقول الإدخال لا يمكنها قبول البرامج النصية الضارة، إخفاء مفاتيح API الخاصة بك من أدوات المتصفح للمطورين، أو إضافة حد معدل لمنع شخص ما من إرسال عدد كبير من الطلبات إلى نقاطك النهائية.
هذه ليست أخطاء من الذكاء الاصطناعي — إنها فجوات في الطلب. الذكاء الاصطناعي يبني ما طلبته. ربما لم تطلب الأمان لأنك كنت مركزاً على الميزات. حان الوقت الآن للعودة وإضافتها.
الخطوة 1: فحص متغيرات البيئة الخاصة بك
هذا هو الخطأ الأكثر شيوعاً والأكثر خطورة في التطبيقات البرمجية السريعة. افحص كل ملف في مشروعك بحثاً عن مفاتيح API مرمزة بشكل ثابت أو عناوين URL لقاعدة البيانات أو الأسرار.
ما الذي تبحث عنه: ابحث في مشروعك عن السلاسل التي تبدأ بـ sk-، eyJ، sbp_، supabase، postgres://، أو أي سلاسل عشوائية طويلة المظهر. تحقق من هذه الملفات بشكل خاص: أي ملف في دليل /app أو /pages، أي ملف مكون، ملف next.config.js الخاص بك، وأي ملفات مساعدة.
الحل: انقل كل سر إلى متغيرات البيئة. في Next.js، فقط المتغيرات التي تبدأ بـ NEXT_PUBLIC_ تُكشف للمتصفح. عنوان URL لقاعدة البيانات الخاصة بك ومفتاح دور الخدمة والأسرار 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 ليس لديها قيود على الوصول — أي شخص لديه مفتاح anon الخاص بك يمكنه قراءة وكتابة كل صف في كل جدول. هذا يعني أن المستخدم أ يمكنه رؤية بيانات المستخدم ب باستخدام مكالمة 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 يسرق جلسات المستخدمين الآخرين (البرمجة النصية للموقع / XSS).
حدد حجم ملف والأنواع إذا كان تطبيقك يقبل تحميل الملفات. غالباً ما لا يكون لدى معالجات تحميل الملفات التي ينتجها الذكاء الاصطناعي حدود، مما يعني أن شخصاً ما يمكنه تحميل ملف بحجم 2GB أو ملف قابل للتنفيذ. أضف حدود الحجم (5MB معقول لمعظم التطبيقات) وقيد أنواع الملفات إلى ما تحتاجه فعلاً (صور وPDFs، إلخ).
الخطوة 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)- تفعيل RLS لـ Supabase على كل جدول
- سياسات RLS المختبرة (المستخدم أ لا يمكنه رؤية بيانات المستخدم ب)
- الكود على جانب العميل يستخدم مفتاح anon فقط (مفتاح دور الخدمة على جانب الخادم فقط)
- المصادقة على كل مسار API
- فحوصات التفويض (التحقق من الملكية) على الوصول إلى البيانات
- التحقق من الإدخال على كل نموذج (جانب الخادم وليس فقط جانب العميل)
- حدود تحميل الملفات (الحجم والنوع) إذا كان ذلك مناسباً
- حد المعدل على نقاط نهاية API
- رؤوس الأمان المكونة
npm auditتم تشغيله والمشاكل الحرجة تم إصلاحها- النطاق المخصص مع SSL المكوّن
- نشرات المعاينة المحمية
- اختبار الوصول إلى بيانات العديد من المستخدمين نجح
الخلاصة
تأمين تطبيق برمجي سريع ليس عن أن تصبح خبير أمان. يتعلق الأمر بتشغيل قائمة تحقق تمسك الفجوات المتنبأ بها التي يتركها الذكاء الاصطناعي وراءه. تستغرق الخطوات أعلاه ساعتين إلى 4 ساعات وتمنع أكثر الثغرات الأمانية شيوعاً. بالنسبة لتطبيق موجه نحو العميل، هذا ليس اختياراً — إنه الفرق بين العمل الاحترافي والمسؤولية.
إذا كنت تبني تطبيقك الأول السريع، ابدأ بـ دليلنا الكامل للبرمجة السريعة. إذا كنت تريد تحسين الطلبات التي تستخدمها مع Claude أو Cursor، جرّب محسّن الطلبات المجاني الخاص بنا. وللحصول على تفصيل أفضل أدوات الترميز، انظر Claude Code مقابل Codex.
هذا ما نفعله كل أسبوع. ملخص عميق واحد حول أدوات الذكاء الاصطناعي وسير العمل والآراء الصريحة — بدون ضجة وبدون حشو. انضم إلينا →
الإفصاح: بعض الروابط في هذا المقال روابط تابعة. نوصي فقط بالأدوات التي اختبرناها شخصياً واستخدمناها بانتظام. انظر سياسة الإفصاح الكاملة الخاصة بنا.