أمن المواقع والتطبيقات: 12 إجراءً أساسياً قبل الإطلاق
قائمة عملية لتأمين مواقع الشركات والمتاجر الإلكترونية وأنظمة الويب قبل الإطلاق، مبنية على OWASP Top 10:2025. اثنا عشر إجراءً من الصلاحيات وحماية تسجيل الدخول إلى النسخ الاحتياطي والسجلات، مشروحة لأصحاب الشركات والمديرين.
معظم المشكلات الأمنية في مواقع الشركات وأنظمة الويب ليست اختراقات خارقة، بل ثغرات عادية: صفحة إدارة يفتحها أي شخص إذا خمّن رابطها، ونموذج دخول يسمح بعدد لا نهائي من محاولات كلمة المرور، ومكتبة قديمة بها ثغرة معروفة، ونسخة احتياطية لم تُجرَّب يوماً. وفي مصر ارتفعت المخاطر في 2026، لأن لائحة قانون حماية البيانات الشخصية تُلزم الشركات بالإخطار عن خرق البيانات الشخصية خلال 72 ساعة.
الإجابة المختصرة: قبل الإطلاق راجع اثني عشر إجراءً: HTTPS، والتحقق من الصلاحيات على السيرفر، وحماية تسجيل الدخول، وتأمين الجلسات، والتحقق من المدخلات، وترويسات الأمان، والإعدادات والأسرار، وتحديث المكتبات، والرفع الآمن للملفات، والسجلات والتنبيهات، والنسخ الاحتياطي المُجرَّب، وحدود الاستخدام. والقائمة مربوطة بـ OWASP Top 10:2025، وهي القائمة الأوسع انتشاراً لأخطر مخاطر تطبيقات الويب.
الخلاصة السريعة
- ضعف التحكم في الصلاحيات هو الأول في OWASP Top 10:2025؛ كل طلب يجب فحصه على السيرفر لا مجرد إخفائه من الواجهة.
- احمِ تسجيل الدخول بتجزئة كلمات المرور مع الملح وتحديد المحاولات والتحقق الثنائي للمديرين.
- أبعد رموز الجلسة عن متناول السكربتات بكوكيز HttpOnly وSecure وSameSite.
- إخفاقات سلسلة توريد البرمجيات أصبحت ضمن القائمة: تابع وحدّث كل مكتبة تعتمد عليها.
- السجلات والتنبيهات والنسخ الاحتياطي المُجرَّب تحدد إن كان الاختراق يوماً سيئاً أم كارثة.
قائمة OWASP Top 10:2025 في جدول
تنشر مؤسسة OWASP قائمة Top 10 كمعيار توعوي، وتضم نسخة 2025:
| الرمز | الخطر | المعنى البسيط |
|---|---|---|
| A01:2025 | Broken Access Control | المستخدم يرى أو يغيّر ما لا يحق له |
| A02:2025 | Security Misconfiguration | إعدادات افتراضية غير آمنة ولوحات إدارة مكشوفة ورسائل خطأ مفصلة |
| A03:2025 | Software Supply Chain Failures | مكتبات أو أدوات بناء بها ثغرات أو مخترقة |
| A04:2025 | Cryptographic Failures | تشفير ضعيف أو غائب للبيانات الحساسة |
| A05:2025 | Injection | مدخلات غير موثوقة تُنفذ كأوامر أو استعلامات |
| A06:2025 | Insecure Design | غياب التفكير الأمني في التصميم نفسه |
| A07:2025 | Authentication Failures | ضعف تسجيل الدخول وكلمات المرور والجلسات |
| A08:2025 | Software or Data Integrity Failures | الثقة في تحديثات أو بيانات دون تحقق |
| A09:2025 | Security Logging and Alerting Failures | الهجمات تمر دون أن يلاحظها أحد |
| A10:2025 | Mishandling of Exceptional Conditions | أخطاء تسرب بيانات أو تترك النظام غير آمن |
الإجراءات 1 إلى 4: الاتصال والصلاحيات وتسجيل الدخول
1. HTTPS في كل مكان
كل صفحة وAPI ولوحة إدارة يجب أن تعمل عبر HTTPS بـشهادة SSL صالحة، مع تحويل HTTP إلى HTTPS وتفعيل HSTS ليرفض المتصفح الاتصال غير الآمن. هذا يحمي بيانات الدخول والبيانات الشخصية أثناء انتقالها، حتى على واي فاي الكافيهات ومساحات العمل المشتركة.
2. فحص الصلاحيات على السيرفر (A01)
إخفاء الزر ليس أماناً. كل طلب يُفحص على السيرفر: هل المستخدم مسجل دخوله، وهل دوره يسمح بهذا الإجراء، وهل هذا السجل يخصه؟ الثغرة الكلاسيكية أن يغيّر المستخدم رقم الطلب في الرابط فيرى طلب عميل آخر. اختبرها صراحة، خاصة في بوابات العملاء وأنظمة العيادات وشؤون العاملين.
3. تسجيل دخول قوي (A07)
- احفظ كلمات المرور كتجزئة مع ملح بخوارزمية بطيئة مثل bcrypt، راجع التشفير مع الملح.
- طبّق تحديد معدل الطلبات على الدخول واستعادة كلمة المرور ورموز OTP.
- اشترط التحقق الثنائي لحسابات المديرين والحسابات المالية.
- استخدم رسائل خطأ عامة ("البريد أو كلمة المرور غير صحيحة") حتى لا يكتشف المهاجم الحسابات الموجودة.
4. تأمين الجلسات والرموز
رموز الجلسة أو التجديد مكانها كوكيز HttpOnly مع Secure وSameSite حيث لا تقرؤها السكربتات. وإذا استخدمت رموز JWT فاجعلها قصيرة العمر، وجدّد رموز التجديد دورياً واحفظها مجزأة على السيرفر، وألغها عند الخروج وتغيير كلمة المرور.
الإجراءات 5 إلى 8: المدخلات والإعدادات والمكتبات
5. التحقق من المدخلات والاستعلامات المُعلَّمة (A05)
تحقق من كل مدخل على السيرفر وفق مخطط، مثلاً بمكتبة Zod: النوع والطول والصيغة والقيم المسموحة. وابنِ استعلامات قاعدة البيانات بمعاملات أو ORM موثوق، لا بتركيب النصوص. وعالج المخرجات في الصفحات لمنع حقن السكربتات.
6. ترويسات الأمان وسياسة CORS صارمة (A02)
أدوات مثل Helmet تضبط ترويسات HTTP الحامية، ومنها سياسة أمان المحتوى التي تحدد مصادر السكربتات وتمنع تضمين صفحاتك في مواقع أخرى. واضبط سياسة CORS لتسمح لنطاقاتك فقط باستدعاء واجهاتك.
7. الإعدادات الآمنة والأسرار (A02، A10)
- احفظ كلمات المرور ومفاتيح API وأسرار بوابات الدفع في متغيرات البيئة أو مخزن أسرار، لا في مستودع الكود.
- احذف الحسابات الافتراضية والصفحات التجريبية وأوضاع التصحيح.
- اعرض للمستخدم صفحة خطأ عامة، وأرسل التفاصيل الفنية للسجلات فقط.
- تأكد أن النظام يفشل بأمان: إذا تعطل إشعار الدفع فلا يُعلَّم الطلب كمدفوع.
8. اعرف مكتباتك وحدّثها (A03)
الأنظمة الحديثة تعتمد على مئات الحزم مفتوحة المصدر. احفظ ملفات القفل، وافحص الحزم قبل كل إصدار، واحذف غير المستخدم، وجدول التحديثات. وفي مواقع ووردبريس ينطبق ذلك على الإضافات والقوالب.
الإجراءات 9 إلى 12: الرفع والسجلات والنسخ الاحتياطي وإساءة الاستخدام
9. رفع الملفات بأمان
رفع السير الذاتية وصور المنتجات والروشتات طريق هجوم شائع. افحص نوع الملف من محتواه لا امتداده، وحدد الحجم، وأعد تسمية الملفات، واحفظها خارج مجلد الويب العام ما أمكن، وأعد ترميز الصور بمكتبة مثل Sharp لإزالة المحتوى المخفي والبيانات الوصفية.
10. السجلات والتنبيهات (A09)
سجّل الأحداث الأمنية: الدخول والمحاولات الفاشلة وتغيير الصلاحيات والتصدير وإجراءات المديرين، بصيغة منظمة مثل التي تنتجها Pino. ولا تسجل كلمات المرور أو أرقام البطاقات كاملة أو بيانات شخصية زائدة. وضع تنبيهات لقفزات الدخول الفاشل أو التصدير غير المعتاد. فبدون سجلات لن تعرف ماذا حدث في الاختراق ولا من يجب إخطاره.
11. نسخ احتياطي جرّبت استرجاعه فعلاً
انسخ قاعدة البيانات والملفات المرفوعة تلقائياً، واحفظ النسخ في مكان منفصل ومشفرة، وجرّب استرجاعاً كاملاً قبل الإطلاق وبانتظام بعده. فبرامج الفدية والحذف الخاطئ يُعالجان بالنسخ الاحتياطي لا بالاعتذار.
12. حدود ضد إساءة الاستخدام والبوتات
نماذج التواصل والتسجيل وطلبات OTP والبحث تحتاج حدوداً لمعدل الطلبات وحماية من البوتات عند الحاجة، وإلا أرسل سكربت واحد آلاف الرسائل النصية على حسابك أو ملأ CRM بعملاء وهميين.
نقاط إضافية للمتاجر والمدفوعات
- استخدم صفحة الدفع المستضافة لدى البوابة أو حقولها الآمنة حتى لا تمر بيانات البطاقة على سيرفرك، وبوابات مصرية مثل Paymob وفوري توفر خيارات ربط لذلك.
- تحقق من توقيع البوابة على إشعارات الدفع قبل تحديث الطلب.
- أعد حساب الأسعار والإجماليات على السيرفر ولا تثق في مبالغ قادمة من المتصفح.
- احمِ لوحة الإدارة بالتحقق الثنائي، وبقائمة عناوين IP مسموحة إن أمكن.
لماذا يهم ذلك في قانون حماية البيانات المصري؟
القانون 151 لسنة 2020 ولائحته التنفيذية، الصادرة في نوفمبر 2025 بمهلة تنتهي في 1 نوفمبر 2026، يشترطان تدابير أمنية مناسبة للبيانات الشخصية. وحسب تحليل مكتب التميمي (2025)، يجب إخطار مركز حماية البيانات الشخصية خلال 72 ساعة من العلم بالخرق، وإبلاغ الأشخاص المتأثرين خلال ثلاثة أيام عمل من هذا الإخطار. والسجلات الجيدة والصلاحيات المضبوطة تجعل هذا الجدول الزمني ممكناً. ويشرح دليل الإخطار بتسريب البيانات خلال 72 ساعة خطة الاستجابة.
قائمة الاعتماد قبل الإطلاق
| البند | من يؤكد |
|---|---|
| HTTPS وHSTS على كل النطاقات | المبرمج / الاستضافة |
| اختبار فحص الدور والملكية في كل عملية حساسة | المبرمج والمختبِر |
| تجزئة كلمات المرور وحدود الدخول والتحقق الثنائي للمديرين | المبرمج |
| كوكيز HttpOnly وSecure وSameSite | المبرمج |
| التحقق من المدخلات والاستعلامات المُعلَّمة | مراجعة الكود |
| ترويسات الأمان وCORS | المبرمج مع فحص بأداة |
| لا أسرار في الكود، والتصحيح مغلق، والحسابات الافتراضية محذوفة | المبرمج / DevOps |
| فحص المكتبات نظيف أو المخاطر مقبولة كتابةً | القائد التقني |
| اختبار قيود رفع الملفات | المختبِر |
| السجلات والتنبيهات الأمنية تعمل | DevOps |
| تجربة استرجاع النسخة الاحتياطية | DevOps وصاحب النظام |
| حدود على النماذج وOTP وواجهات API | المبرمج |
وللتحقق الأعمق يوفر معيار OWASP للتحقق من أمن التطبيقات (ASVS) متطلبات تفصيلية، واختبار الاختراق المستقل يستحق تكلفته للأنظمة التي تحفظ مدفوعات أو بيانات صحية أو أعداداً كبيرة من العملاء.
كيف تساعدك Nilex
تبني Nilex هذه الضوابط في أنظمتها من البداية: ترويسات Helmet، وتحديد المحاولات على الدخول والنماذج، وكوكيز HttpOnly مع تدوير رموز التجديد، وتجزئة كلمات المرور مع الملح، والتحقق من كل طلب، وسجلات منظمة. وإذا كان لديك موقع أو نظام قائم، نستطيع مراجعته وفق هذه القائمة وإصلاح الثغرات. تواصل معنا عبر صفحة التواصل.
الأسئلة الشائعة
ما هي قائمة OWASP Top 10؟
وثيقة توعوية من مؤسسة OWASP تضم أخطر المخاطر الأمنية في تطبيقات الويب. النسخة الحالية OWASP Top 10:2025، ويتصدرها ضعف التحكم في الصلاحيات ثم أخطاء الإعدادات الأمنية.
هل شهادة SSL تكفي لتأمين موقعي؟
لا. HTTPS يحمي البيانات أثناء انتقالها، لكنه لا يمنع ضعف الصلاحيات أو كلمات المرور الضعيفة أو الإضافات المصابة أو هجمات الحقن. هو الإجراء الأول لا الوحيد.
كل كم يُفحص أمن الموقع؟
قبل الإطلاق، وبعد كل تغيير كبير، وبجدول منتظم مع مراجعة تحديثات المكتبات شهرياً. والأنظمة التي تتعامل مع مدفوعات أو بيانات صحية تستفيد من اختبار اختراق مستقل دوري.
هل تتعرض مواقع الشركات الصغيرة للاختراق فعلاً؟
نعم. البوتات الآلية تفحص الإنترنت بحثاً عن ثغرات معروفة وكلمات مرور افتراضية وإضافات قديمة بغض النظر عن حجم الشركة، والمواقع الصغيرة غالباً أهداف أسهل.
ماذا أفعل أولاً إذا اشتبهت في اختراق؟
احتوِ الحادث، واحفظ السجلات، وأشرك فريقك التقني ومسؤول حماية البيانات، وقيّم هل تأثرت بيانات شخصية، لأن مهلة الإخطار خلال 72 ساعة في اللائحة المصرية قد تنطبق.
تطلق موقعاً أو متجراً أو نظاماً جديداً، أو لست مطمئناً لنظام قائم؟ اطلب مراجعة أمنية وفق هذه الإجراءات الاثني عشر عبر صفحة التواصل.
