Security Misconfiguration

سوء الإعدادات الأمنية Security Misconfiguration

API8:2023 — أشمل بند بالقائمة: أي إعداد افتراضي غير آمن، رسالة خطأ مفصّلة جدًا، أو مسار اختباري نُسي في الإنتاج.

لا تنتج هذه الثغرة من خطأ برمجي بل من إعدادات: CORS يسمح بـ '*' في الإنتاج، رسائل خطأ تكشف Stack Trace كامل أو اسم قاعدة البيانات، رؤوس أمان غائبة (CSP، HSTS)، صلاحيات مفرطة على قاعدة البيانات، أو تفعيل GraphQL Introspection في الإنتاج. غالبًا سببها نسيان تغيير إعداد افتراضي مخصص للتطوير عند النشر.

الصياغة

قارن كل إعداد بيئة إنتاج مقابل قائمة تحقق أمنية قبل كل نشر

📄 مثال

// سيئ — إعدادات بيئة التطوير تسربت للإنتاج
app.use(cors({ origin: '*' }));
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.message, stack: err.stack }); // يسرّب تفاصيل داخلية
});

// جيد
app.use(cors({ origin: process.env.ALLOWED_ORIGIN }));
app.use((err, req, res, next) => {
  logger.error(err); // التفاصيل تُسجَّل داخليًا فقط
  res.status(500).json({ error: 'حدث خطأ غير متوقع' }); // رسالة عامة للعميل
});

أهم النقاط

النقطة	الوظيفة
الأمثلة الشائعة	CORS wildcard، رؤوس أمان مفقودة، Debug mode مفعّل بالإنتاج، صلاحيات قاعدة بيانات مفرطة
الحل	فصل إعدادات البيئات (dev/staging/prod) + مراجعة أمنية آلية قبل كل نشر

💡 نصائح عملية

شغّل فحص رؤوس HTTP (مثل curl -I) على بيئة الإنتاج دوريًا للتأكد من عدم انزلاق إعداد تطوير إليها

⚠️ أخطاء شائعة

استخدام نفس ملف .env أو نفس أسرار قاعدة البيانات بين بيئة التطوير والإنتاج

🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار API-SECURITY الكامل بالعربي.