تدقيق أمان ووردبريس: ما يجب التحقق منه قبل النشر

قبل أن يصل أي مكون إضافي تم إنشاؤه بواسطة PAGEnza إلى تثبيت WordPress الخاص بالمستخدم، فإنه يمر بثلاث عمليات فحص أمان آلية. تشرح هذه المشاركة ما تبحث عنه عمليات الفحص هذه — ولماذا كل منها مهم.

لماذا يحتاج الكود الذي تم إنشاؤه بواسطة الذكاء الاصطناعي إلى تدقيق

نماذج اللغة الكبيرة جيدة بشكل مدهش في كتابة مكونات WordPress الإضافية. إنها تعرف أسماء الخطافات (hooks)، وتفهم معايير ترميز WP، وتنتج PHP قابلة للقراءة. لكنها ترتكب أيضًا أخطاء يمكن التنبؤ بها — وهذه الأخطاء هي ثغرات أمنية.

الأكثر شيوعًا التي نراها:

• استخدام $_GET أو $_POST بدون تنقية (sanitization)
• عدم التحقق من nonce عند إرسال النماذج
• استعلامات قاعدة بيانات مباشرة بدون $wpdb->prepare()
• استخدام eval() أو exec() للسلوك الديناميكي
• إخراج بيانات المستخدم بدون esc_html() أو esc_attr()

هذه ليست حالات هامشية غريبة. تظهر بانتظام في مخرجات LLM — حتى من أفضل النماذج.

المرحلة 1: التحقق من صحة المطالبة (Prompt validation)

قبل أن يكتب الذكاء الاصطناعي سطرًا واحدًا، نقوم بتحليل وصف المستخدم. تلتقط هذه الخطوة فئتين من المشاكل:

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

أوصاف غامضة أو غير قابلة للتطبيق — المطالبات القصيرة جدًا أو الغامضة جدًا لإنتاج كود مفيد. "إنشاء مكون إضافي" ينتج قمامة؛ "إنشاء نموذج اتصال يرسل الإرسالات إلى عنوان بريد إلكتروني مع تصفية البريد العشوائي" ينتج شيئًا حقيقيًا.

إذا فشلت المطالبة في هذا الفحص، يرى المستخدم رسالة خطأ محددة توضح السبب — وليس رفضًا عامًا.

المرحلة 2: فحص PHP في حاوية معزولة

بمجرد أن ينتج الذكاء الاصطناعي كود PHP، يتم تنفيذه عبر php -l داخل حاوية Docker معزولة تمامًا عن كل شيء آخر. هذا يلتقط أخطاء بناء الجملة قبل أن يصل المكون الإضافي إلى تثبيت WordPress.

لكننا نذهب أبعد من ذلك: إذا فشل الفحص، فإن النظام لا يرفض الإخراج ببساطة. إنه يرسل الخطأ مرة أخرى إلى الذكاء الاصطناعي مع مطالبة تصحيح — ما نسميه الشفاء (healing). يرى الذكاء الاصطناعي خطأه ويحاول مرة أخرى، حتى ثلاث مرات.

هذا يعني أن المستخدمين لا يرون رسالة "فشل الإنشاء" تقريبًا أبدًا. يرون وقت إنشاء أطول قليلاً — وكودًا يعمل.

المرحلة 3: فحص أمان الكود

هذه هي المرحلة الأكثر أهمية. نقوم بتشغيل تحليل ثابت يتحقق من:

الوظائف الخطرة: eval(), exec(), system(), shell_exec(), passthru() — أي من هذه تمنع إصدار المكون الإضافي.

متجهات حقن SQL: استدعاءات $wpdb->query() خام مع متغيرات مستوفاة، وعدم وجود $wpdb->prepare()، واستخدام مباشر لـ mysql_query().

فحص الأذونات المفقودة: معالجات AJAX التي لا تستدعي current_user_can() قبل القيام بأي إجراء مميز.

التحقق من Nonce المفقود: معالجات النماذج التي لا تستدعي wp_verify_nonce() أو check_ajax_referer().

الإخراج غير المعالج (Unescaped output): echo $_GET[...], echo $user_input بدون وظائف معالجة.

إذا تم العثور على أي من هذه، يتم حظر المكون الإضافي. يرى المستخدم تقريرًا يسرد بالضبط الوظائف التي أدت إلى الحظر ولماذا — وليس مجرد "فشل فحص الأمان“.

كيف يبدو تقرير التدقيق

يأتي كل مكون إضافي تم إنشاؤه مع تقرير تدقيق أمان بلغة واضحة. يسرد:

• أي الفحوصات مرت (أخضر)
• أي الفحوصات أثارت تحذيرات (كهرماني) — مشاكل ليست مانعة ولكنها تستحق الاهتمام
• أي تصحيحات تم تطبيقها تلقائيًا أثناء الشفاء

يتم إنشاء التقرير تلقائيًا وإرفاقه بتنزيل المكون الإضافي. إنه مفيد لكل من ثقتك الخاصة ولإظهار للعملاء أنك أخذت الأمان على محمل الجد.

المرحلة 4: التحقق عند الحفظ

هذا ليس جزءًا من الإنشاء الأولي — ينطبق عندما يقوم المستخدمون بتحرير كود المكون الإضافي يدويًا في محرر PAGEnza.

في كل مرة تحفظ فيها، يتم تشغيل نفس فحص lint + الأمان مرة أخرى. إذا أدخلت ثغرة أمنية حرجة أثناء التحرير، فسيتم حظر الحفظ حتى تقوم بإصلاحها. هذا يمنع السيناريو الشائع حيث يقوم المطور بإجراء تغيير "مؤقت" سريع يبقى في الإنتاج لمدة عامين.

حدود التدقيق الآلي

يكتشف الفحص الآلي فئة معينة من المشاكل بشكل جيد. لا يكتشف كل شيء.

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

بالنسبة للمكونات الإضافية الإنتاجية التي تتعامل مع المدفوعات أو البيانات الحساسة، نوصي بمراجعة يدوية بالإضافة إلى الفحوصات الآلية. يوفر تقرير التدقيق نقطة انطلاق جيدة للمراجع البشري.