في معظم مشاريعنا، تكمن المخاطر الحقيقية في الفجوة بين هذين المعيارين. إليك ثلاثة أنماط ما زلنا نراها باستمرار في تطبيقات اجتازت فحص الامتثال دون أي ملاحظات.
1. تحقق في جانب العميل يتنكر في هيئة ضابط في جانب الخادم
أدوات الفحص الآلي بارعة في اكتشاف الترويسات المفقودة والمكتبات القديمة، لكنها أسوأ بكثير في ملاحظة أن السعر أو الكمية أو رمز الخصم لا يُتحقق منه إلا عبر JavaScript في المتصفح. كثيرًا ما نعترض طلب الدفع، ونعدّل حقل السعر مباشرة، ونشاهد الطلب يمر دون تغيير.
2. خلل التفويض على مستوى الكائنات في واجهات API «متوافقة»
يهتم PCI DSS بكيفية نقل بيانات البطاقات وتخزينها — ولا يكشف تلقائيًا نقطة نهاية تُعيد سجل طلبات عميل آخر لأن معرّف الكائن قابل للتخمين ولا أحد يتحقق من الملكية في الخادم. هذه باستمرار النتيجة الأكثر شيوعًا في مشاريعنا للويب وواجهات API، سواء كانت متوافقة أم لا.
3. أخطاء إعداد أدوات الدفع الخارجية
إسناد استقبال بيانات البطاقات إلى أداة دفع مستضافة ممارسة جيدة، وغالبًا ما يقلّص نطاق PCI من الأساس. لكننا ما زلنا نجد أدوات مضمّنة بقواعد CSP متساهلة، أو صفحات دفع تحمّل نصوصًا برمجية خارجية قادرة على تعديل الصفحة حول إطار الدفع — فتعيد فتح خطر سرقة البيانات الذي وُجدت الأداة لإغلاقه.
«متوافق» تخبرك أن الضابط موجود على الورق. أما اختبار الاختراق فيخبرك إن كان يصمد أمام من يحاول فعلًا.
لا شيء من هذه النتائج غريب. إنها من النوع الذي لا يستطيع فحص الامتثال اكتشافه بطبيعته، لأن أداة الفحص لا تفهم منطق أعمالك — فهي تتحقق فقط من البصمات المعروفة والإعدادات المفقودة. وهذه هي الفجوة التي صُمم الاختبار اليدوي لسدّها.