إضافةٌ محادثةٍ بسيطةٌ على صفحة الدفع قد تُخرجك الآن من أبسط مستوى امتثالٍ لمعيار PCI — قاعدة SAQ A لعام 2026 التي يفوّتها التجار الصغار
منذ 1 أبريل 2025، صار أقصر تقييمٍ ذاتيٍّ ضمن معيار PCI DSS — استبيان SAQ A، المخصَّص للتجار الذين لا يلمسون بيانات البطاقة أبداً لأن صفحة الدفع مُفوَّضةٌ بالكامل — يحمل شرط أهليةٍ ثانياً: على التاجر أن يؤكّد أن الصفحة تصدّ هجمات السكريبت. أغلب الأعمال التي تُضمِّن نموذج دفعٍ من مزوّد خدمةٍ تفترض أن هذا الشرط مُحقَّقٌ تلقائياً. والشيء الذي يُفقِد الأهلية فعلياً نادراً ما يكون نموذج الدفع نفسه — بل إضافة المحادثة، أو سكريبت التحليلات، أو بكسل التسويق الموجود على الصفحة نفسها، والذي لم يُدرجه أحدٌ يوماً في قائمة امتثال.
عملٌ تجاريٌّ صغيرٌ انتقل منذ سنوات إلى نموذج دفعٍ مُضمَّنٍ من مزوّد خدمة، خصيصاً ليتجنّب أثقل مستوى امتثال. يملأ الاستبيان الذاتي القصير مرة كل سنة، يضع العلامات، ويمضي قُدُماً. في 2026، يمكن لهذا الإعداد نفسه أن يتوقّف بهدوءٍ عن استيفاء الأهلية — والصفحة التي فشلت لا تزال، في العادة، تحمل نموذج الدفع نفسه الذي حملته دائماً. ما تغيّر يقع في مكانٍ آخر من الصفحة.
أضاف معيار PCI DSS الإصدار 4.0.1 شرط أهليةٍ جديداً إلى استبيان SAQ A — أقصر استبيانات التقييم الذاتي، المخصَّص للتجار الذين فوَّضوا صفحة الدفع بالكامل إلى مزوّدٍ ملتزمٍ بمعيار PCI، عبر إعادة توجيهٍ أو نموذجٍ مُضمَّنٍ (iframe). الشرط نفّذ في 1 أبريل 2025، وأحدث قدراً من الالتباس كافياً لتصدر مجلس معايير أمان PCI توضيحاً مخصَّصاً، هو FAQ 1588، ليشرح بدقّةٍ ما يتطلّبه هذا الشرط وكيفية استيفائه [1].
تتناول هذه القطعة ما يقوله هذا الشرط فعلياً، والطريقتين اللتين يسمح بهما المجلس للتاجر لاستيفائه، ولماذا تكون السكريبتات التي يضيفها عملٌ صغيرٌ دون تفكير — لا نموذج الدفع نفسه — هي عادةً ما يُسقِط الأهلية، وما يترتّب على تاجرٍ لم يعد مؤهّلاً للاستبيان القصير.
لنبدأ بما يخدمه استبيان SAQ A، لأن الشرط الجديد لا معنى له إلا على هذه الخلفية. SAQ A هو أقصر استبيانات التقييم الذاتي ضمن PCI DSS — جزءٌ بسيطٌ من طول المستوى الأعلى التالي — وبُني خصيصاً للتجار الإلكترونيين الذين لا يخزّنون أو يعالجون أو ينقلون بيانات البطاقة على أنظمتهم الخاصة أبداً لأن صفحة الدفع بكاملها تأتي من مزوّدٍ خارجيٍّ ملتزمٍ بـPCI، تُسلَّم إمّا كإعادة توجيهٍ إلى صفحةٍ يستضيفها المزوّد أو كنموذجٍ مُضمَّنٍ (iframe) داخل صفحة التاجر نفسها [2][5]. لسنوات، كانت هذه الحقيقة البنيوية وحدها كافية: إن كان رقم البطاقة لا يلمس شيفرة التاجر نفسها قطّ، انطبق SAQ A، ونهاية النقاش.
أضاف PCI DSS 4.0.1 بنداً جديداً محدَّداً إلى هذا اختبار الأهلية. صياغة SAQ A الحالية تتطلّب من التاجر أن يكون قد «أكّد أن موقعه ليس عرضةً لهجماتٍ من سكريبتاتٍ يمكن أن تؤثّر على أنظمته التجارية الإلكترونية» — شرطٌ تصفه مدونة مجلس معايير أمان PCI نفسها بأنه نفّذ في 1 أبريل 2025 [1]. تلك الجملة الواحدة هي سبب وجود FAQ 1588: لم يكن التجار والمقيّمون متأكّدين مما تعنيه كلمة «أكّد» عملياً، فحدَّد المجلس طريقتين واضحتين.
الطريقة الأولى ذاتية التطبيق: يستطيع التاجر استيفاء الشرط باستخدام تقنياتٍ مشابهةٍ — دون أن تقتصر عليها — لمتطلّبي PCI DSS رقم 6.4.3 و11.6.1. يطلب المتطلّب 6.4.3 جرد كلّ سكريبتٍ يعمل على صفحة الدفع، وسبباً موثّقاً لوجود كلٍّ منها، وطريقةً لتأكيد سلامة كلّ سكريبت. ويطلب المتطلّب 11.6.1 آلية كشف تغييرٍ وتلاعبٍ تُقيِّم سكريبتات صفحة الدفع وترويساتها بوتيرةٍ منتظمة، وتُنبِّه عند أي تغييرٍ غير مُصرَّحٍ به [1][4]. والملف الصريح يوضّح أن هذه التقنيات يمكن أن ينشرها التاجر مباشرةً أو طرفٌ ثالثٌ يعمل باسمه [1].
الطريقة الثانية لا تتطلّب من التاجر بناء أي شيء: الحصول على تأكيدٍ خطّيٍّ من مزوّد خدمة الدفع الملتزم بـPCI والذي يقدّم النموذج المُضمَّن، بأن حلّه، إذ طُبِّق بالضبط وفق تعليمات المزوّد نفسه، يحمي الصفحة فعلاً من هجمات السكريبت [1][2]. لكنّ هذا التأكيد يغطّي فقط ما تفعله شيفرة المزوّد نفسها — لا يقول شيئاً عن أي شيءٍ آخر يُحمَّل على الصفحة نفسها، وهو بالضبط حيث يُضبَط أغلب التجار الصغار متلبّسين.
هذا ما يجعل الشرط يوقع بأعمالٍ لا علاقة لها بكيفية عمل نموذج الدفع نفسه. إضافة محادثةٍ مباشرة، أو وسم تحليلات موقعٍ، أو حاوية مدير وسوم، أو بكسل إعادة استهدافٍ موجودٌ على صفحة الدفع نفسها هو بالضبط نوع السكريبت غير المفحوص الذي تستهدفه القاعدة — وهو أيضاً بالضبط نوع الشيء الذي تضيفه أداة تسويقٍ، أو إضافة دعمٍ، أو مقتطف وكالةٍ إلى صفحةٍ من دون أن يتحقّق أحدٌ مما إذا كان يلمس نطاق PCI [1][3]. يمكن لتاجرٍ أن يملك نموذج iframe ملتزماً تماماً من مزوّدٍ ملتزمٍ تماماً، ويفشل مع ذلك في استيفاء الشرط، لأن الشرط يتعلّق بكل ما يعمل على الصفحة، لا فقط بالجزء الذي يتعامل مع رقم البطاقة.
نتيجة خروج التاجر من أهلية SAQ A هي عبء امتثالٍ أكبر بكثير، لا تحذيرٌ فقط. التاجر الذي لا يستطيع استيفاء أيٍّ من الطريقتين يتعيّن عليه الانتقال إلى SAQ A-EP — استبيانٌ مُصمَّمٌ للتجار الذين تشارك سكريبتات صفحتهم الخاصة في معالجة بيانات الدفع، بعدد متطلّباتٍ يبلغ تقريباً ستّة أضعاف، بالإضافة إلى التزامٍ جديدٍ لم يحمله SAQ A يوماً: فحوصات ثغراتٍ خارجيةٍ فصليةٍ من جهة فحصٍ معتمَدةٍ من PCI [2][3][5]. لا شيء من هذا يُطبَّق عبر جهةٍ تنظيميةٍ حكومية — إنه يسري عبر علاقة التاجر ببنكه المُقبِل أو مزوّد خدمة الدفع، العلاقة نفسها التي تحدِّد رسوم قبول البطاقات، وتُقرِّر، في حال خرقٍ فعلي، مَن يتحمَّل مسؤولية خسائر الاحتيال. ومسار التطبيق هذا واحدٌ بالضبط لتاجرٍ في الولايات المتحدة ولتاجرٍ في مصر أو أي مكانٍ آخر في المنطقة يقبل البطاقات عبر الإنترنت — إنه معيارٌ عالميٌّ لشبكات البطاقات، لا قانونٌ وطني، فلا يوجد استثناءٌ لسوقٍ أصغر يمكن الاعتماد عليه.
طريق تأكيد مزوّد الخدمة يغطّي بالضبط ما يفعله نموذجه المُضمَّن — لا أكثر. يوضّح FAQ 1588 صراحةً أن الشرط ينطبق على كامل صفحة الدفع التي يراها العميل، وأن إضافة محادثةٍ، أو وسم تحليلات، أو بكسل تسويقٍ أضافه التاجر بشكلٍ مستقلٍّ يقع كلياً خارج ما يستطيع أي تأكيدٍ من المزوّد أن يضمنه [1]. نموذج iframe ملتزمٌ من مزوّدٍ ملتزمٍ لا يغطّي سكريبتاتٍ لم يلمسها المزوّد قطّ.
تأكيد المزوّد هو أحد طريقين صالحين، لا منحةً تلقائية — ولا يوجد إلا إذا طلبه التاجر فعلياً خطّياً وتحقّق من أن النموذج المُضمَّن طُبِّق بالضبط وفق تعليمات المزوّد [1][2]. والطريق ذاتي التطبيق (الجرد، التخويل، سلامة البيانات، كشف التلاعب) هو مسؤولية التاجر نفسه بوضوحٍ تحت المتطلّبين 6.4.3 و11.6.1 بصرف النظر عن مَن يستضيف النموذج [4]. افتراض أن المزوّد تولّى الأمر فعلاً، من دون التأكّد من الطريق المُنطبِق فعلياً، هو نفسه الثغرة.
هذا يحلّ مشكلة النطاق، لكنه عادةً بكلفةٍ حقيقية: إضافة المحادثة التي تُنقِذ بيعةً متوقّفة، والتحليلات التي تُظهر أين ينهار الدفع فعلياً. القاعدة لا تحظر هذه السكريبتات — تتطلّب أن تكون محصورةً ومُبرَّرةً ومرصودةً كأي شيفرةٍ أخرى لها وصولٌ إلى صفحةٍ حساسة. التطهير الشامل يستبدل مخاطرة امتثالٍ بكلفة رؤيةٍ ودعمٍ لم يطلب أحدٌ دفعها.
تعامل مع قائمة سكريبتات صفحة الدفع كجردٍ مُحدَّثٍ، لا لغزاً: اعرف كلّ سكريبتٍ يُحمَّل عليها، ووثِّق سبب وجود كلٍّ منه، وأضِف فحص كشف تغييرٍ يُنبِّهك على أي جديدٍ أو مُعدَّل. ثم احصل على تأكيد مزوّد الخدمة الخطّي للنموذج المُضمَّن نفسه، مطابقاً بالضبط للتطبيق الذي يحدِّده المزوّد. هذا المزيج هو ما يستوفي الشرط فعلياً — لا افتراض أن نموذجاً مُستضافاً يعني أن الصفحة كلّها مسؤولية طرفٍ آخر.
- 1هل تستطيع اليوم تقديم قائمةٍ حاليةٍ بكل سكريبتٍ يُحمَّل على صفحة الدفع لديك — بما فيها ما أضافته أداة تسويقٍ، أو إضافة محادثة، أو مقتطف وكالة، لا شيفرة مطوّرك فقط؟
- 2هل زوّدك مزوّد خدمة الدفع بأي شيءٍ خطّيٍّ يؤكّد أن نموذجه المُضمَّن يحمي صفحتك من هجمات السكريبت — أم أنك تفترض ذلك لأنه مزوّدٌ كبيرٌ ومعروف؟
- 3هل لديك أي آلية تُنبِّهك إن تغيّر سكريبتٌ على صفحة الدفع لديك بشكلٍ غير متوقَّع — من تحديثٍ، أو اختراقٍ، أو أداةٍ جديدةٍ أضافها أحدٌ؟
- 4لو طلب بنكك المُقبِل منك إثبات أهلية SAQ A غداً، هل تعرف فعلاً أي استبيان تقييمٍ ذاتيٍّ يستوفيه موقعك حالياً؟
- 5هل ستعرف إن أضاف تصميمٌ جديد، أو أداة تسويقٍ جديدة، أو مقتطف تتبّعٍ من وكالةٍ، سكريبتاً جديداً إلى صفحة الدفع لديك خلال الأشهر الأخيرة؟
- [1]مجلس معايير أمان PCI — «FAQ يوضّح معايير أهلية SAQ A الجديدة للتجار الإلكترونيين» (FAQ 1588): شرط SAQ A r1، النافذ منذ 1 أبريل 2025، الذي يتطلّب من التجار تأكيد أن موقعهم يصدّ هجمات السكريبت ضدّ الأنظمة التجارية الإلكترونية؛ يحدِّد طريقي الامتثال — ضوابط ذاتية التطبيق مشابهة للمتطلّبين 6.4.3/11.6.1، أو تأكيدٌ خطّيٌّ من مزوّد خدمةٍ ملتزمٍ بـPCI.
- [2]Akamai — «PCI DSS v4.0.1: التغييرات التي تحتاج معرفتها لاستيفاء أهلية SAQ A»: يشرح شرط أهلية حماية السكريبت، وطريقي الذاتي والتأكيد من المزوّد، ونتيجة الخروج من SAQ A إلى SAQ A-EP للتجار ذوي نماذج الدفع المُضمَّنة.
- [3]HUMAN Security — «تحديث PCI DSS 4: تفصيل التغييرات على SAQ A في FAQ 1588»: يفصّل كيف يمكن لسكريبتات طرفٍ ثالثٍ غير متعلّقةٍ على صفحة الدفع — تحليلات، محادثة، وسوم تسويقٍ — أن تُسقِط أهلية SAQ A حتى حين يكون نموذج الدفع نفسه مُفوَّضاً بالكامل وملتزماً.
- [4]OneUptime — «PCI DSS 4.0.1: سكريبتات صفحة الدفع وكشف التغيير» (سبتمبر 2026): يستعرض المتطلّبين 6.4.3 (جرد السكريبتات وتخويلها وسلامتها) و11.6.1 (كشف التغيير والتلاعب على صفحات الدفع) كالطريق ذاتي التطبيق لأهلية SAQ A المتعلّقة بهجمات السكريبت.
- [5]مجلس معايير أمان PCI — FAQ رسمي، «لماذا يُستخدَم SAQ A-EP للنشر المباشر بينما يُستخدَم SAQ A للنموذج المُضمَّن أو إعادة التوجيه»: شرح المجلس نفسه للخط البنيوي بين SAQ A (إعادة توجيهٍ أو نموذجٍ مُضمَّنٍ مُفوَّضٍ بالكامل) وSAQ A-EP (مشاركة صفحة التاجر نفسها في معالجة بيانات الدفع)، وسبب الاختلاف الكبير بين الاستبيانين في الطول والنطاق.
نراجع ونبني صفحات الدفع وفق قاعدة نطاق السكريبت الفعلية لعام 2026 — لا فقط نموذج دفعٍ يبدو مُستضافاً.
تبني فلوكا وتراجع صفحات الدفع وفق معايير أهلية PCI DSS 4.0.1 الفعلية: جرد كل سكريبتٍ على صفحة الدفع، إضافة كشف تغييرٍ، وتوثيق تأكيد المزوّد الذي يحتاجه مستوى استبيانك فعلاً. إن لم تكن تعرف أي استبيانٍ يستوفيه موقعك حالياً، سنساعدك على معرفة ذلك قبل أن يسألك بنكك المُقبِل.
احجز استشارة مجانية 15 دقيقة