5 أخطاء أمنية يرتكبها كل مبرمج Vibe (وكيفية إصلاحها)

الكود المُنتج بالذكاء الاصطناعي يعمل. ينفّذ البرنامج. يبدو صحيحاً. لكنه يأتي أيضاً مع نفس خمس ثغرات أمنية في تقريباً كل مشروع. هذه ليست مخاطر نظرية — بل هي الثغرات المحددة التي تظهر في تقريباً كل قاعدة بيانات مُنتجة بواسطة Claude أو Cursor أو Replit أو Copilot عندما لا تطلب الأمان بشكل صريح.

لقد قمت بتدقيق عشرات المشاريع المُنتجة بـ "vibe-coding" خلال السنة الماضية، وتظهر نفس الأخطاء الخمسة في ما لا يقل عن 80% منها. كل واحدة تستغرق أقل من 30 دقيقة لإصلاحها. إليك ما يجب البحث عنه وكيفية إصلاحه بالضبط.

الخطأ 1: مفاتيح API مشفرة بشكل مباشر في كود الواجهة الأمامية

كيف يحدث: تخبر Claude "اتصل بـ Supabase" أو "أضف دفعات Stripe"، وينتج عنه كود بمفتاح API مُدرج مباشرة في مكون React. يعمل الكود بشكل مثالي — ومفتاحك السري مرئي لأي شخص يفتح DevTools والدخول للعلامة Network أو المصدر JavaScript.

لماذا هذا خطير: مفتاح Supabase service role يتجاوز كل أمان قاعدة البيانات. مفتاح Stripe السري يدع أي شخص يشحن بطاقات أو يصدر استرجاعات. مفتاح OpenAI يدع أي شخص يراكم آلاف الدولارات في استدعاءات API على حسابك. البوتات تفحص النسخ المستودعات العامة والمواقع المنشورة بنشاط بحثاً عن المفاتيح المكشوفة.

الحل: انقل كل سر إلى متغيرات البيئة. في Next.js، فقط المتغيرات التي تبدأ بـ NEXT_PUBLIC_ تصل إلى المتصفح. أي مفتاح يمنح وصول كتابة أو وصول المسؤول أو وصول مالي يجب أن يكون على جانب الخادم فقط.

بعد نقل المفاتيح إلى .env.local، ابحث عن قيم المفاتيح القديمة في قاعدة الكود بالكامل للتأكد من أنها اختفت. ثم تحقق من سجل Git — إذا تم التزام المفتاح في أي وقت، فإنه لا يزال في سجل المستودع حتى لو حذفته. أعد توليد (تدوير) أي مفتاح تم تعريضه في أي وقت، حتى لو لفترة وجيزة.

الوقت لإصلاح: 15–30 دقيقة.

الخطأ 2: جداول Supabase بدون أمان على مستوى الصفوف

كيف يحدث: الذكاء الاصطناعي ينتج استعلامات إنشاء جداول Supabase وعمليات CRUD، لكن لا يفعّل Row-Level Security (RLS). بشكل افتراضي، جداول Supabase مع تعطيل RLS قابلة للوصول بشكل كامل لأي شخص لديه عنوان URL المشروع ومفتاح anon — كلاهما عام (ويجب أن يكون).

لماذا هذا خطير: بدون RLS، المستخدم A يمكنه الاستعلام عن بيانات المستخدم B. استدعاء fetch بسيط من وحدة تحكم المتصفح يمكن أن يسحب كل صف من كل جدول. قاعدة البيانات الخاصة بك فعلياً عامة.

كيفية اكتشافها: انتقل إلى لوحة معلومات Supabase → محرر الجداول. إذا أظهر أي جدول "RLS معطّل"، لديك هذه المشكلة. تحقق أيضاً إذا كان الكود على جانب العميل يستخدم مفتاح service_role بدلاً من مفتاح anon — هذا أسوأ.

الحل: فعّل RLS على كل جدول. ثم أنشئ سياسات تطابق أنماط وصول تطبيقك. السياسة الأكثر شيوعاً: المستخدمون يمكنهم فقط SELECT و INSERT و UPDATE و DELETE الصفوف حيث auth.uid() = user_id. اختبر بتسجيل الدخول كمستخدم واحد ومحاولة الوصول إلى بيانات مستخدم آخر عبر Supabase REST API.

الوقت لإصلاح: 30–60 دقيقة حسب عدد الجداول.

الخطأ 3: لا يوجد تحقق من الإدخال في النماذج أو مسارات API

كيف يحدث: الذكاء الاصطناعي ينتج نماذج تقبل أي إدخال ومسارات API تثق بأي بيانات تأتي. النموذج يحتوي على سمة "مطلوب" في HTML، لكن لا يوجد تحقق على جانب الخادم. شخص ما يتجاوز النموذج بالكامل بإرسال طلب API مباشر مع أي حمل يريده.

لماذا هذا خطير: بدون تحقق على جانب الخادم، المهاجمون يمكنهم حقن نصوص برمجية في قاعدة البيانات (XSS مخزّن)، إرسال حمولات كبيرة تعطل خادمك، أو إرسال بيانات تكسر منطق التطبيق (مثل سعر سالب أو حقل بريد يحتوي على SQL).

كيفية اكتشافها: افتح أي مسار API أو إجراء خادم في قاعدة الكود. إذا كان يستخدم req.body أو بيانات النموذج دون فحص شكل وحجم ونوع كل حقل، لديك هذه المشكلة.

الحل: أضف تحققاً على جانب الخادم لكل نقطة نهاية باستخدام مكتبة التحقق من البيانات. Zod هو المعيار لمشاريع TypeScript:

import { z } from 'zod';

const taskSchema = z.object({
  title: z.string().min(1).max(200),
  description: z.string().max(2000).optional(),
  priority: z.enum(['low', 'medium', 'high']),
});

// في مسار API الخاص بك:
const parsed = taskSchema.safeParse(req.body);
if (!parsed.success) {
  return Response.json({ error: parsed.error }, { status: 400 });
}

لأي حقل يُعرّض كـ HTML (تعليقات وأوصاف وسيرة ذاتية)، قم أيضاً بتنظيف الإخراج بـ DOMPurify قبل عرضه.

الوقت لإصلاح: 30–60 دقيقة.

الخطأ 4: لا توجد حدود معدل على نقاط نهاية API

كيف يحدث: الذكاء الاصطناعي لا يضيف حدود معدل إلا إذا طلبت ذلك. كل نقطة نهاية API يكشفها تطبيقك يمكن أن تُضرب آلاف المرات في الثانية من أي شخص لديه سكريبت.

لماذا هذا خطير: بدون حدود معدل، يمكن لشخص ما اختبار نقطة نهاية تسجيل الدخول بالقوة الغاشمة، أو كشط قاعدة البيانات بضرب نقاط النهاية بشكل متكرر، أو إرهاق الخادم (رفض الخدمة)، أو حرق حصة API إذا استدعت نقاط النهاية خدمات خارجية مثل OpenAI أو Stripe.

كيفية اكتشافها: إذا لم تتحقق أي من مسارات API الخاصة بك من عدد الطلبات التي قام بها عنوان IP أو مستخدم واحد مؤخراً، فليس لديك حدود معدل.

الحل: الطريقة الأبسط لتطبيقات مستضافة على Vercel هي محدد معدل في الذاكرة للتطوير وواحد قائم على Redis للإنتاج. Edge Middleware من Vercel يمكنه التعامل مع حدود المعدل الأساسية. Upstash Redis (المستوى المجاني) مع @upstash/ratelimit يعطيك حدود معدل من المستوى الإنتاجي في كمية صغيرة من الكود.

نقطة بداية معقولة: 60 طلب في الدقيقة للمستخدمين المصرح لهم، 20 في الدقيقة للمستخدمين غير المصرح لهم، و 5 في الدقيقة لنقاط نهاية تسجيل الدخول/التسجيل (لمنع الهجوم بالقوة الغاشمة).

الوقت لإصلاح: 20–45 دقيقة.

الخطأ 5: فحوصات المصادقة المفقودة على الصفحات المحمية و APIs

كيف يحدث: الذكاء الاصطناعي ينتج صفحة لوحة معلومات جميلة ومسارات API تُرجع بيانات المستخدم، لكن لا يضيف middleware للتحقق من أن المستخدم مسجل دخول بالفعل. تعمل الصفحة "بشكل صحيح" لأنك في التطوير أنت دائماً مسجل دخول. في الإنتاج، يمكن لشخص ما الوصول إلى عنوان URL لوحة المعلومات مباشرة دون تسجيل دخول، أو ضرب نقطة نهاية API والحصول على بيانات مرة أخرى.

لماذا هذا خطير: الوصول غير المصرح له إلى الصفحات المحمية يعني أن أي شخص يمكنه رؤية لوحات معلومات المستخدمين أو لوحات التحكم الإدارية أو البيانات الخاصة فقط بتخمين عنوان URL. نقاط النهاية غير المحمية تعني أن أي أداة مثل Postman أو curl يمكنها سحب البيانات بدون بيانات اعتماد.

كيفية اكتشافها: افتح نافذة متصفح في وضع الحماية (غير مسجل دخول) وانتقل مباشرة إلى عناوين URL لوحة المعلومات أو الإعدادات أو الإدارة. إذا كان يمكنك رؤية أي محتوى دون إعادة توجيه إلى صفحة تسجيل الدخول، لديك هذه المشكلة. ثم حاول ضرب مسارات API الخاصة بك مباشرة — إذا أرجعت البيانات دون ملف تعريف جلسة صحيح أو رمز مصادقة، تلك غير محمية أيضاً.

الحل: أضف middleware مصادقة يعمل قبل كل مسار محمي. في Next.js App Router، أنشئ middleware.ts في جذر المشروع:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const session = request.cookies.get('session');
  if (!session) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*', '/api/protected/:path*'],
};

كيّف matcher لتغطية كل مسار يجب أن يتطلب مصادقة. اختبر في وضع الحماية بعد التنفيذ.

الوقت لإصلاح: 15–30 دقيقة.

كيفية منع هذه في المشاريع المستقبلية

النمط واضح: الذكاء الاصطناعي ينتج كود يعمل من الناحية الوظيفية لكن يتخطى الأمان لأنك لم تطلب ذلك. الحل هو أن تطلبه مقدماً.

أضف هذا في نهاية المطالبة الأولية لأي مشروع يتم إنتاجه بـ "vibe-code":

متطلبات الأمان:
- جميع الأسرار في متغيرات البيئة (لا تُشفّر مباشرة أبداً)
- Supabase RLS مفعّل على جميع الجداول مع سياسات لكل مستخدم
- التحقق من الإدخال على جانب الخادم على كل مسار API (استخدم Zod)
- حدود المعدل على جميع نقاط النهاية العامة
- middleware المصادقة على جميع المسارات المحمية
- لا مفتاح service role في الكود على جانب العميل

هذا لن يمسك بكل شيء، لكنه يلغي أكثر خمس ثغرات أماناً شيوعاً في المرة الأولى بدلاً من تتطلب تنظيفاً لاحقاً.

إذا كنت تريد أن تصبح أفضل في كتابة المطالبات التي تنتج كوداً أكثر أماناً من البداية، أداة تحسين المطالبات المجانية يمكنها أن تساعدك على هيكلة التعليمات. وللحصول على شرح أمان كامل، انظر إلى دليلنا خطوة بخطوة: كيفية تأمين تطبيق Vibe-Coded قبل إعطاؤه للعملاء.

الإفصاح: بعض الروابط في هذه المقالة هي روابط تابعة. نوصي فقط بالأدوات التي اختبرناها شخصياً واستخدمناها بانتظام. انظر سياسة الإفصاح الكاملة.