حادثة Vercel: لا تحذف المشروع قبل تدوير الأسرار

مستوى القارئ: متوسط

هتكسب من المقال ده قائمة قرار واضحة بعد حادثة Vercel: تدوّر أي سر قابل للقراءة، تراجع OAuth، وتمنع تكرار المشكلة بدل ما تعمل حركة شكلية.

المشكلة باختصار

في 19 أبريل 2026 أعلنت Vercel عن حادثة أمنية تخص وصول غير مصرح به لبعض أنظمتها الداخلية. التحديثات اللاحقة وصلت حتى 24 أبريل 2026، وVercel قالت إن جزءًا محدودًا من العملاء تأثر، وإن بعض متغيرات البيئة غير المعلّمة كـ sensitive اتعاملت كبيانات لازم تتدوّر.

الطريقة الشائعة الغلط هنا إن الفريق يحذف مشروع Vercel أو يعمل redeploy فقط. الطريقة دي بتفشل لأن السر لو اتقرأ مرة، يفضل صالحًا عند Stripe أو Supabase أو قاعدة البيانات حتى لو المشروع اختفى. ركز: حذف المشروع لا يلغي صلاحية المفتاح عند الطرف الثالث.

اللي بيحصل فعلاً مع متغيرات البيئة

مثال بسيط: عندك مشروع Next.js عليه 50 ألف زائر يوميًا. عندك DATABASE_URL، وSTRIPE_SECRET_KEY، وJWT_SECRET داخل Vercel. لو المتغير كان قابلًا للقراءة من لوحة التحكم، فالمشكلة ليست في Vercel فقط. المشكلة إن المفتاح نفسه ممكن يفتح قاعدة البيانات أو بوابة الدفع من خارج Vercel.

حسب توثيق Vercel، المتغيرات الحساسة تصبح غير قابلة للقراءة بعد إنشائها عند تفعيل خيار Sensitive. وحسب صفحة البيئة العامة، التغييرات الجديدة في متغيرات البيئة لا تُطبّق على deployments القديمة تلقائيًا. معنى هذا إنك تحتاج تدوير السر عند المصدر، تحديث Vercel، ثم تعمل deployment جديد.

الافتراض إن عندك مشروع production واحد أو أكثر على Vercel، وفريق من 3 إلى 20 مطور، وبيانات الدخول موزعة بين مزود دفع، قاعدة بيانات، ومزود بريد. لو عندك أكثر من 30 مشروع، نفّذ نفس القائمة على دفعات حسب حساسية المشروع.

قائمة تنفيذية في 30 دقيقة

1. استخرج أسماء المتغيرات الموجودة في production وpreview.
2. ابدأ بالمفاتيح التي تعطي وصولًا ماليًا أو وصولًا لبيانات المستخدمين.
3. دوّر المفتاح من المصدر الأصلي: قاعدة البيانات، Stripe، Resend، Supabase، أو أي مزود آخر.
4. حدّث المتغير في Vercel، وعلّمه Sensitive عندما يكون متاحًا.
5. اعمل deployment جديد، ثم راقب الأخطاء لمدة 15 دقيقة.
6. راجع OAuth apps في Google Workspace وابحث عن التطبيق المذكور في IOC المنشور من Vercel.

# مثال عملي: قائمة أولية من أسماء env في مشروع Vercel
# لا تطبع القيم في التيرمنال ولا تحفظها في ملف logs
vercel env ls production
vercel env ls preview

# بعد تدوير المفتاح من المزود الأصلي، أعد إضافة القيمة الجديدة
vercel env rm DATABASE_URL production
vercel env add DATABASE_URL production

# redeploy حتى يأخذ التطبيق القيم الجديدة
vercel --prod

لو عندك 12 متغيرًا حساسًا، غالبًا هتقسمهم إلى 3 مجموعات: قاعدة البيانات أولًا، مفاتيح الدفع ثانيًا، ثم مفاتيح البريد والتحليلات. رقم عملي: هدفك إن مفاتيح الدرجة العالية تتدوّر خلال أول 60 دقيقة، وباقي المفاتيح خلال 24 ساعة.

الـ trade-off هنا

تدوير كل الأسرار يكسبك تقليل نافذة الخطر، لكنه ممكن يكسر تكاملات قديمة لمدة 5 إلى 20 دقيقة لو الترتيب غلط. أفضل طريقة: أنشئ المفتاح الجديد عند المزود أولًا، حدّث Vercel ثانيًا، اعمل redeploy ثالثًا، وبعد التحقق احذف المفتاح القديم. عكس الترتيب يسبب downtime.

تحويل المتغيرات إلى Sensitive يكسبك منع القراءة من الواجهة لاحقًا. التكلفة إنك لن تستطيع رؤية القيمة القديمة عند debug، ولازم تعتمد على مدير أسرار أو سجل داخلي مضبوط. هذا ثمن مقبول لأي مفتاح production.

متى لا تستخدم هذا الإجراء كما هو

لا تستخدم القائمة بنفس السرعة لو عندك نظام مالي شديد الحساسية بدون نافذة صيانة. في الحالة دي اعمل rotation مزدوج: المفتاح القديم والجديد يعملان معًا مؤقتًا، ثم أوقف القديم بعد التأكد. كذلك لا تطبع قيم الأسرار في CI logs بحجة الجرد. الجرد يكون بالأسماء، وليس بالقيم.

مصادر الخبر والتحقق

• Vercel April 2026 Security Incident: تحديثات الحادثة، التوصيات، وIOC الخاص بتطبيق OAuth.
• Vercel Sensitive Environment Variables: شرح المتغيرات غير القابلة للقراءة بعد إنشائها كـ Sensitive.
• Vercel Environment Variables: ملاحظة أن تغييرات المتغيرات لا تطبق على deployments القديمة إلا بعد نشر جديد.

الخطوة التالية

افتح مشروع Vercel الأكثر حساسية عندك الآن، واكتب جدولًا من 3 أعمدة: اسم المتغير، درجة الخطر، وهل هو Sensitive. ابدأ بتدوير أول 3 أسرار عالية الخطر قبل أي تعديل تجميلي.