# قائمة التحقق الأمنية التي ننفّذها قبل كل إطلاق
> الفحوصات المحددة التي تكشف أغلب حالات اختراق المواقع الواقعية، ولماذا لا علاقة لمعظمها بهجمات بارعة.
**URL:** https://www.regenbyte.com/ar/blog/website-security-checklist-before-launch  
**Published:** 2026-06-18  
**Updated:** 2026-07-22  
**Author:** RegenByte  
**Category:** cybersecurity  
**Reading time:** 9 minutes
معظم المواقع لا تُخترق بتقنيات مبتكرة، بل عبر اعتمادية قديمة، أو واجهة إدارية تُركت مكشوفة، أو رفع ملفات لم يتحقق يومًا مما يستقبله، أو بيانات دخول أُعيد استخدامها في مكان آخر. الفحوصات غير اللامعة هي التي تكشف أغلب الحوادث الحقيقية، ولهذا ننفّذها بالطريقة نفسها في كل مرة.

هذه هي القائمة التي نمر عليها قبل أن يصبح الموقع مباشرًا. وهي ليست شاملة، واجتيازها لا يجعل الموقع آمنًا؛ لا شيء يفعل ذلك. لكنها تغلق الأبواب التي تُوجد مفتوحة في أغلب الأحيان.

## الاعتماديات وسلسلة التوريد

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

- دقّقوا كل اعتمادية بحثًا عن تنبيهات معروفة قبل الإطلاق لا بعده
- أزيلوا الحزم التي لم تعد تُستخدم، فالشيفرة غير المستخدمة تبقى مساحة هجوم
- تحققوا من أن الإضافات ما زالت مصانة؛ الإضافة المهجورة لن تحصل على تصحيح
- ثبّتوا الإصدارات حتى لا يجلب النشر شيئًا جديدًا بصمت
- فعّلوا تنبيهات آلية بالإشعارات الأمنية لتعرفوا بالمشكلات دون فحص يدوي

## المصادقة وإدارة الجلسات

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

- افرضوا سياسة كلمات مرور حقيقية وتحققوا من بيانات الدخول مقابل قوائم التسريبات المعروفة
- حدّدوا معدل المحاولات وأوقفوا الحساب بعد محاولات فاشلة متكررة
- تأكدوا من أن رموز إعادة تعيين كلمة المرور تُستخدم مرة واحدة ومحدودة زمنيًا وغير قابلة للتخمين
- أعيدوا توليد معرّف الجلسة عند تسجيل الدخول وعند تغيّر الصلاحية
- اضبطوا Secure وHttpOnly وSameSite على ملفات تعريف ارتباط الجلسة
- وفّروا المصادقة متعددة العوامل للحسابات الإدارية

## التحكم في الصلاحيات

المصادقة تسأل: من أنت. أما التحكم في الصلاحيات فيسأل: ما الذي يُسمح لك بلمسه، وهو الأكثر تعطّلًا بين الاثنين. وقد ظل ضعف التحكم في الوصول في صدارة قائمة OWASP العشرة في المراجعات الأخيرة، ونادرًا ما يظهر في الاستخدام العادي لأن المستخدمين العاديين لا يحاولون.

> **Note:** الاختبار الذي يكشف معظم هذه الحالات: سجّلوا الدخول بمستخدم منخفض الصلاحية، ثم اطلبوا موردًا يخص حسابًا آخر بتغيير معرّف في الرابط أو في جسم الطلب. إن أعاد بيانات، فلديكم مشكلة في التحقق من الصلاحية على مستوى الكائن.

- تحققوا من الصلاحية على الخادم في كل طلب، لا في الواجهة فقط
- تحققوا من ملكية الكائن، لا من مجرد كون المستخدم مسجّلًا
- امنعوا افتراضيًا وامنحوا الصلاحية صراحةً
- اختبروا كل دور مقابل النقاط المخصصة لأدوار أخرى

## معالجة المدخلات ورفع الملفات

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

- تحققوا على الخادم مقابل قائمة سماح؛ التحقق في المتصفح تسهيل لا وسيلة تحكم
- استخدموا الاستعلامات المُعامَلة في كل مكان، فدمج النصوص داخل SQL ما زال الخطأ الكلاسيكي
- رمّزوا المخرجات حسب السياق الذي تصل إليه لمنع البرمجة عبر المواقع
- تحققوا من أنواع الملفات المرفوعة بالمحتوى لا بالامتداد
- خزّنوا الملفات المرفوعة خارج جذر الويب، أو قدّموها من نطاق لا يستطيع تنفيذ الشيفرة
- حدّدوا سقفًا لأحجام الملفات ولمعدلات الرفع

## الإعدادات والأسطح المكشوفة

حصة كبيرة من نتائج أي تقييم نموذجي هي مسائل إعدادات لا عيوب في الشيفرة: أشياء كانت مقبولة في بيئة التطوير ولم تُغيَّر للإنتاج.

- أوقفوا أوضاع التنقيح وصفحات الأخطاء التفصيلية في الإنتاج
- أزيلوا الحسابات الافتراضية والمحتوى التجريبي
- تأكدوا من أن مجلدات .git والنسخ الاحتياطية وملفات البيئة وتفريغات قواعد البيانات غير قابلة للوصول عبر الويب
- قيّدوا الواجهات الإدارية عبر الشبكة أو بمصادقة إضافية حيثما أمكن
- اضبطوا الترويسات الأمنية: Content-Security-Policy وStrict-Transport-Security وX-Content-Type-Options وReferrer-Policy
- تأكدوا من صحة إعداد TLS ومن أن HTTP يعيد التوجيه إلى HTTPS

## السجلات والنسخ الاحتياطي والاسترجاع

الأسئلة بعد أي حادث واحدة دائمًا: متى بدأ هذا، وما الذي وصلوا إليه، وهل نستطيع العودة إلى حالة سليمة معروفة؟ ولا يمكنكم الإجابة عنها إلا إن استعددتم مسبقًا.

- سجّلوا أحداث المصادقة وتغيّرات الصلاحيات والإجراءات الإدارية
- احتفظوا بالسجلات في مكان لا يستطيع مهاجم على خادم الويب حذفه ببساطة
- نفّذوا نسخًا احتياطيًا مجدولًا واحتفظوا بنسخة واحدة على الأقل خارج الموقع
- نفّذوا استرجاعًا تجريبيًا فعليًا، فالنسخة غير المختبَرة أمنية لا وسيلة تحكم
- دوّنوا بمن تتصلون وما الذي تفعلونه أولًا، قبل أن تحتاجوا إلى ذلك

## ما لا تفعله هذه القائمة

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

تعاملوا معها كخط أساس تجتازونه قبل الإطلاق، ثم واصلوا اجتيازه وفق جدول. وإن أردتم نظرة أعمق على تطبيق محدد، فذلك ما وُجد له تقييم الثغرات أو اختبار الاختراق.