تأمين ووردبريس: قائمة فحص عملية لسنة 2026

معظم المواقع اللي بتتخترق مش بسبب هاكر عبقري، لكن بسبب إضافة قديمة، أو باسورد مكرر، أو حساب أدمن لموظف ساب الشغل من سنتين. الخبر الحلو إن تأمين ووردبريس في الأغلب عادات بسيطة، والقائمة دي هتمشيك عليها واحدة واحدة.

تقوية الأمان (Security Hardening) تتلخص في خمس عادات: حدّث كل شيء، احذف ما لا تستخدمه، أغلق باب تسجيل الدخول وتعديل الملفات، امنع تشغيل PHP في مجلد الرفع، واحتفظ بنسخ احتياطية خارج السيرفر جرّبت استعادتها فعلًا.

ابدأ بمراجعة لا تغيّر شيئًا

قبل أي تعديل، اعرف أين تقف. إذا كانت واجهة قاعدة البيانات بأمر واحد من الطرفية، وهي الأساس الذي يعتمد عليه وكلاء…">سطر أوامر ووردبريس (WP-CLI) متاحة على السيرفر، فهذه الأوامر للقراءة فقط وتكشف الكثير:

# Are core files exactly what WordPress.org shipped?
wp core verify-checksums

# Same check for plugins from the WordPress.org directory
wp plugin verify-checksums --all

# Who can change everything?
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# What is out of date?
wp plugin list --update=available
wp theme list --update=available

أي اختلاف في التحقق من بصمة الملفات (Checksum Verification)، أو مدير لا تعرفه، أو إضافة متأخرة سنوات عن آخر إصدار، يذهب مباشرة إلى رأس قائمة مهامك.

قائمة تأمين ووردبريس

1. شغّل wp-config.php لصالحك

هذه الثوابت تقيّد بعض الإجراءات في لوحة التحكم وتضبط سلوك الاتصال:

// Nobody edits PHP from the dashboard. Deploy changes instead.
define( 'DISALLOW_FILE_EDIT', true );

// Always use HTTPS for the admin area.
define( 'FORCE_SSL_ADMIN', true );

// Allow automatic minor core updates (security releases).
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

إذا كنت تنشر الإضافات عبر Git أو خط نشر آلي، فالثابت DISALLOW_FILE_MODS يمنع التثبيت والتحديث من اللوحة أيضًا. لا تفعّله إلا إذا كان هناك شيء آخر يتولى تحديث الإضافات.

غيّر مفاتيح التشفير (Salts) كلما شككت في تسرّب. انتبه إلى أن هذا الأمر يُخرج جميع المستخدمين:

wp config shuffle-salts

2. امنع تشغيل PHP في مجلد الرفع

مجلد الرفع يجب أن يحتوي على الوسائط فقط. على سيرفر Apache، أنشئ ملف .htaccess داخل wp-content/uploads:

<FilesMatch ".(?:php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

وعلى Nginx، أضف هذا داخل كتلة server:

location ~* /wp-content/uploads/.*.(?:php[0-9]?|phtml|phar)$ {
    deny all;
}

3. أغلق باب تسجيل الدخول

• فعّل المصادقة الثنائية (Two-Factor Authentication) لكل حساب يستطيع النشر أو إدارة الإضافات.
• امنح كل شخص أقل دور يكفيه. المحرر نادرًا ما يحتاج أن يكون مديرًا.
• حدّد عدد محاولات الدخول من جدار حماية التطبيق (WAF) أو بإضافة مُصانة جيدًا.
• إذا لم يكن هناك ما يستخدم XML-RPC، فاحظر xmlrpc.php من السيرفر. انتبه: Jetpack وبعض التكاملات القديمة ما زالت تعتمد عليه.

4. اضبط صلاحيات الملفات

القاعدة الشائعة: 755 للمجلدات و644 للملفات، مع جعل wp-config.php مقروءًا فقط للحساب الذي يعمل به PHP (640 أو 600 حسب الاستضافة). لا تستخدم 777 أبدًا، حتى لو نصحك بها منتدى لحل مشكلة رفع.

5. أضف ترويسات الأمان

ترويسات الأمان (Security Headers) لا تكلّفك شيئًا وتمنع هجمات شائعة في المتصفح. ابدأ بهذه:

• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• قاعدة frame-ancestors أو X-Frame-Options
• HSTS، لكن فقط بعد انتقال الموقع بالكامل إلى HTTPS

سياسة أمان المحتوى (Content Security Policy) هي الأقوى بينها، لكنها تحتاج اختبارًا دقيقًا.

في Elementor: منشئات الصفحات مثل Elementor وإضافات JetEngine تعتمد على سكربتات مضمّنة (Inline Scripts) كثيرة. لو طبّقت CSP صارمة مباشرة ستتعطل المحررات والقوائم والنوافذ المنبثقة. ابدأ بوضع Content-Security-Policy-Report-Only لمراقبة ما سيُحظر قبل التطبيق الفعلي.

إذا كان الموقع مخترقًا بالفعل

1. خذ نسخة كاملة أولًا من الملفات وقاعدة البيانات، فستحتاجها للتحقيق.
2. اعرض صفحة صيانة أو أوقف الزيارات أثناء العمل.
3. أعد تثبيت النواة وكل إضافة وقالب من مصادر نظيفة. لا تحاول “إصلاح” النسخ المصابة.
4. ابحث عن ملفات PHP غريبة، خصوصًا في مجلد الرفع، وراجع مجلد mu-plugins وملف .htaccess.
5. راجع المهام المجدولة بالأمر wp cron event list، لأن البرمجيات الخبيثة تحب جدولة عودتها.
6. احذف المديرين المجهولين، ثم غيّر كل كلمات المرور وغيّر مفاتيح التشفير.
7. حدّث كل شيء ثم ابحث عن نقطة الدخول. إذا بقيت الثغرة مفتوحة فسيُخترق الموقع مرة أخرى.
8. اطلب مراجعة من Google Search Console إذا كان الموقع قد عُلِّم كخطير.

حافظ على هذا المستوى

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

ولو بتدير أكتر من كام موقع لعملاء، اعمل الفحص ده بشكل آلي بدل ما تعتمد على ذاكرتك. وخلي النسخ الاحتياطية على خدمة تخزين خارجية زي Google Drive أو Backblaze، مش على نفس السيرفر.

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

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

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

س: هل أحظر xmlrpc.php في كل المواقع؟
ج: احظره فقط إذا لم يكن هناك ما يعتمد عليه. Jetpack وتطبيقات النشر القديمة ما زالت تحتاجه، فتأكد قبل الحظر.

س: ما أول شيء أفعله عند اكتشاف اختراق؟
ج: خذ نسخة كاملة من الملفات وقاعدة البيانات قبل أي تعديل، ثم أوقف الزيارات وابدأ بإعادة التثبيت من مصادر نظيفة.

س: ما الصلاحيات الصحيحة لملف wp-config.php؟
ج: 640 أو 600 حسب إعداد الاستضافة، بحيث يقرؤه فقط الحساب الذي يعمل به PHP.

الخلاصة

تأمين ووردبريس مش سحر، هو شوية عادات ثابتة: حدّث، احذف اللي مش محتاجه، اقفل باب الدخول، امنع PHP في الـ uploads، وجرّب ترجّع نسخة احتياطية مرة على الأقل. ابدأ النهارده بأوامر WP-CLI اللي فوق، وشوف أول بند في القايمة محتاج شغل.

مرجع المقال (بالإنجليزية): WordPress security hardening: a practical checklist for 2026
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.