أمان المتجر الإلكتروني أبعد من HTTPS: ما الذي يحمي متجرك فعلاً؟

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

وفي مصر ترتفع المخاطر: الدفع الإلكتروني ينمو، وبيانات العملاء لها قيمة، ومن 1 نوفمبر 2026 تصبح اللائحة التنفيذية لقانون حماية البيانات الشخصية واجبة التطبيق بالكامل، ومنها إخطار الجهة المختصة بتسريب البيانات خلال 72 ساعة. والثقة مسألة مبيعات أيضاً: في أبحاث Baymard Institute عن صفحات الدفع، قال 19% ممن تركوا الشراء إنهم لم يثقوا في الموقع ببيانات بطاقتهم (Baymard Institute).

في هذا الدليل: التهديدات التي تصيب المتاجر فعلاً، والضوابط التي توقفها، وقائمة مراجعة قبل الإطلاق وكل شهر بعده.

الخلاصة السريعة

• أبقِ بيانات البطاقات بعيداً عن سيرفراتك باستخدام صفحة الدفع المستضافة أو المدمجة من بوابة الدفع، واحمِ صفحة الدفع من السكريبتات المحقونة.
• لا تعتبر الطلب مدفوعاً إلا بعد التحقق من إشعار البوابة الموقّع ومن المبلغ.
• احمِ لوحة التحكم بكلمات مرور قوية وتحقق بخطوتين وصلاحيات حسب الدور وسجل تدقيق.
• خزّن كلمات مرور العملاء بتشفير مع Salting، وحدد عدد محاولات الدخول، واستخدم كوكيز جلسات آمنة HttpOnly.
• حدّث المكتبات والسيرفرات، وراقب السجلات، واختبر النسخ الاحتياطية، وجهّز خطة لتسريب البيانات تلتزم بمهلة الـ72 ساعة.

ماذا تفعل HTTPS وماذا لا تفعل

شهادة SSL/TLS تشفّر البيانات أثناء انتقالها وتثبت هوية الدومين، وهي حد أدنى تطلبه المتصفحات ومحركات البحث وبوابات الدفع. لكنها لا تحمي:

• البيانات المخزنة في قاعدة البيانات أو النسخ الاحتياطية.
• لوحة التحكم من كلمات المرور الضعيفة أو المسروقة.
• الكود من الحقن أو ثغرات الصلاحيات أو المكتبات المصابة.
• صفحة الدفع من سكريبت خبيث جاء عبر إضافة أو طرف ثالث مخترق.
• نشاطك من موظف يصدّر قائمة العملاء.

التهديدات التي تصيب المتاجر فعلاً

التهديد	كيف يبدو	الضابط الأساسي
الاستيلاء على حساب الأدمن	تسريب كلمة مرور مكررة لموظف، والمهاجم يغير الأسعار أو يصدّر العملاء	تحقق بخطوتين، كلمات مرور قوية، أقل صلاحيات، سجل تدقيق
تجربة كلمات مرور مسربة على حسابات العملاء	بوتات تجرب أزواج بريد وكلمة مرور مسربة للوصول للحسابات والعناوين	تحديد المحاولات، القفل المؤقت، تشفير مع Salting، OTP للإجراءات الحساسة
تزوير إشعار الدفع	طلب "نجاح" مزيف يجعل طلباً غير مدفوع يُشحن	التحقق من توقيع الإشعار والمبلغ على السيرفر
حقن سكريبت في صفحة الدفع	سكريبت طرف ثالث مخترق ينسخ بيانات البطاقة أثناء كتابتها	صفحة دفع مستضافة أو مدمجة، التحكم في السكريبتات، Content Security Policy
ثغرات الصلاحيات	تغيير رقم الطلب في الرابط يعرض طلب عميل آخر	التحقق من الملكية على السيرفر في كل طلب
إضافات ومكتبات مصابة	مكوّن قديم به ثغرة معروفة يتم استغلاله	قائمة بالمكونات، تحديثات، متابعة التنبيهات الأمنية
طلبات وهمية وبوتات	سكريبتات تغرق صفحة الدفع بطلبات وهمية أو تجرب بطاقات مسروقة	Rate Limiting، حماية من البوتات، تأكيد الطلبات
تسريب من الداخل	موظف يصدّر قائمة العملاء كاملة قبل أن يترك العمل	صلاحيات حسب الدور، صلاحيات التصدير، التسجيل

استخدم OWASP Top 10 كقائمة مراجعة

قائمة OWASP Top 10 هي أشهر مرجع لمخاطر تطبيقات الويب. نسخة 2025 تضم: ثغرات التحكم في الوصول، وسوء الإعدادات الأمنية، وإخفاقات سلسلة توريد البرمجيات، وإخفاقات التشفير، والحقن، والتصميم غير الآمن، وإخفاقات المصادقة، وإخفاقات سلامة البرمجيات والبيانات، وإخفاقات التسجيل والتنبيه الأمني، وسوء التعامل مع الحالات الاستثنائية (OWASP Top 10:2025). اسأل المبرمج أو الشركة كيف يعالج متجرك كل بند؛ الإجابات الواضحة علامة جيدة.

أمان الدفع: أبعد بيانات البطاقات عن سيرفراتك

استخدم صفحة دفع مستضافة أو مدمجة

مع صفحة الدفع المستضافة (تحويل) أو النموذج المدمج (iframe) من مزود ملتزم بمعيار PCI DSS، يُكتب رقم البطاقة مباشرة في أنظمة البوابة. ووفق PCI DSS، يمكن للمتاجر التي تفوّض إدخال البطاقات بهذا الشكل استخدام أقصر استبيان تقييم ذاتي وهو SAQ A. وفي فبراير 2025 أوضح مجلس معايير أمان صناعة بطاقات الدفع شرطاً إضافياً: أن يؤكد التاجر أن موقعه محمي من هجمات السكريبتات التي قد تؤثر على أنظمة متجره، سواء بضوابطه الخاصة أو بتأكيد من مزود الدفع (PCI SSC، 2025).

تحقق من كل عملية دفع على السيرفر

• لا تثق في تحويل متصفح العميل كدليل على الدفع.
• تحقق من توقيع إشعار البوابة (مثل HMAC) بمفتاحك السري.
• راجع المبلغ والعملة ورقم الطلب مقابل سجلاتك.
• عالج الإشعارات بحيث لا يؤدي تكرارها لشحن أو استرداد مزدوج.

اضبط عمليات الاسترداد

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

حسابات العملاء والجلسات

• تخزين كلمات المرور: خوارزمية Hashing بطيئة مع Salting، ولا تخزين كنص صريح أو بخوارزميات سريعة بسيطة أبداً.
• حماية الدخول: حدد عدد محاولات الدخول واستعادة كلمة المرور، وأضف OTP لتغيير الرقم أو العنوان.
• الجلسات: احفظ رموز الجلسة في كوكيز آمنة HttpOnly لا تقرأها السكريبتات، وأنهِ الجلسة بعد فترة خمول.
• التحقق من الملكية: كل طلب لعرض طلب أو عنوان أو فاتورة يجب أن يتأكد على السيرفر أنه يخص العميل المسجل.

لوحة التحكم وصلاحيات الموظفين

أغلب الحوادث الخطيرة في المتاجر تأتي من لوحة التحكم لا من الواجهة.

1. التحقق بخطوتين إلزامي لكل حساب أدمن.
2. أدوار واضحة: خدمة العملاء ترى الطلبات دون التصدير، والتسويق يعدل المحتوى دون الأسعار، والاسترداد الكبير للمالك أو المالية فقط.
3. سجّل الدخول وتغييرات الأسعار والاسترداد والتصدير بالمستخدم والوقت والـIP.
4. ألغِ صلاحيات الموظف في نفس يوم تركه العمل.
5. قيّد الدخول للوحة التحكم بعناوين IP أو VPN في المتاجر عالية القيمة.

تقوية التطبيق نفسه

• ترويسات الأمان: Content Security Policy وHSTS وحماية الإطارات ونوع المحتوى؛ أدوات مثل Helmet تضبطها في تطبيقات Node.js.
• التحقق من المدخلات: تحقق من كل مدخل على السيرفر بمخطط صارم، واستخدم استعلامات بمعاملات لمنع الحقن.
• سكريبتات الأطراف الثالثة: احتفظ بقائمة لكل سكريبت في صفحات الدفع، واحذف غير الضروري منها، ومنه أدوات الشات والتتبع الزائدة.
• المكتبات: قائمة محدثة، وتحديثات منتظمة، ومتابعة التنبيهات الأمنية لإطار العمل والمكتبات.
• التعامل مع الأخطاء: رسائل عامة للعميل وتفاصيل في السجلات الخاصة، وتأكد أن أي فشل (مثل انقطاع البوابة) يترك الطلب في حالة آمنة.

السيرفرات والنسخ الاحتياطي والمراقبة

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

الأمان وقانون حماية البيانات المصري

القانون 151 لسنة 2020 ولائحته التنفيذية الصادرة في نوفمبر 2025، بمهلة التزام حتى 1 نوفمبر 2026، يلزمان المؤسسات بحماية البيانات الشخصية وإخطار الجهة المختصة بأي تسريب خلال 72 ساعة، وفق التحليلات القانونية المنشورة (CMS، 2026). للمتجر هذا يعني: أن تعرف أي بيانات تحتفظ بها، وتجمع فقط ما تحتاجه، وتقيد الوصول إليها، وتكتب خطة استجابة: من يحقق، ومن يقرر، ومن يُخطر، وكيف يُبلَّغ العملاء.

قائمة مراجعة الأمان: قبل الإطلاق وكل شهر

البند	قبل الإطلاق	شهرياً
HTTPS في كل الصفحات مع HSTS	نعم	التأكد من تجديد الشهادة
صفحة دفع مستضافة أو مدمجة وإشعارات موثقة	نعم	مراجعة سكريبتات صفحة الدفع
تحقق بخطوتين وأدوار للأدمن	نعم	مراجعة المستخدمين وحذف من ترك العمل
تشفير كلمات المرور وتحديد محاولات الدخول	نعم	مراجعة تنبيهات الدخول الفاشل
ترويسات الأمان والتحقق من المدخلات	نعم	إعادة الاختبار بعد الإصدارات الكبيرة
تحديث المكتبات والسيرفرات	محدثة	تطبيق التحديثات
النسخ الاحتياطي	تلقائي ومختبر	اختبار استرجاع
خطة الاستجابة للحوادث	مكتوبة	تحديث جهات الاتصال

كيف تساعدك Nilex

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

الأسئلة الشائعة

هل شهادة SSL كافية لحماية متجري الإلكتروني؟

لا. الشهادة تشفّر البيانات أثناء النقل لكنها لا تحمي لوحة التحكم ولا قاعدة البيانات ولا الكود ولا سكريبتات صفحة الدفع. تحتاج أيضاً دفعاً آمناً وصلاحيات وتحديثات ومراقبة ونسخاً احتياطية.

هل أحتاج الالتزام بـPCI DSS إذا استخدمت باي موب أو بوابة أخرى؟

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

كيف يمكن خداع المتجر لشحن طلبات غير مدفوعة؟

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

ماذا أفعل إذا تسربت بيانات عملاء متجري؟

احتوِ الحادث، واحفظ السجلات، وحدد البيانات المتأثرة، واتبع خطة الاستجابة. ووفق لائحة قانون حماية البيانات يجب إخطار الجهة المختصة خلال 72 ساعة، فاطلب استشارة قانونية فوراً.

هل إضافات المتجر خطر أمني؟

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

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