دروس السلسلة: WordPress REST API · Elementor 4 و Atomic Editor · تحسين أداء ووردبريس 2026

لماذا الحديث عن الأمن في ووردبريس عام 2026 مختلف

عند الحديث عن أمن المواقع المبنيّة على ووردبريس، ينساق الكثيرون نحو نصائح كلاسيكيّة: حدّث الإضافات، اختر كلمة مرور قويّة، ثبّت إضافة أمان. هذه النصائح صحيحة لكنّها لم تعد كافية في 2026. الهجمات الحديثة تستهدف ثغرات يوم الصفر (Zero-Day) في الإضافات الشهيرة، وتستخدم شبكات بوتات ذكاء اصطناعي قادرة على تخمين كلمات المرور بأنماط واقعيّة، وتعتمد على هجمات سلسلة التوريد (Supply Chain) عبر إضافات معطّلة المالك.

هذا الدرس يقدّم نهجًا متقدّمًا للتصلّب (Hardening) يتجاوز التوصيات السطحيّة. سنبني طبقات متعدّدة من الحماية: على مستوى الخادم، ملفّات النظام، قاعدة البيانات، إضافات الحماية، والمراقبة المستمرّة. نتوجّه إلى مدير الموقع المسؤول عن مشاريع تجاريّة فعليّة لا يقبل بأي تعطّل، سواء كان يدير متجرًا إلكترونيًا في الرياض، أو بوّابة تعليميّة في الدوحة، أو موقع شركة استشارات في تونس.

الخطوة 1: تأمين wp-config.php كخطّ الدفاع الأول

ملف wp-config.php يحتوي على بيانات اتّصال قاعدة البيانات ومفاتيح التشفير. أي تسريب لمحتواه يساوي خسارة كاملة للموقع. ابدأ بنقله مستوى واحدًا أعلى من الجذر العام، أي خارج مجلد public_html. ووردبريس يبحث تلقائيًا عن الملف في المستوى الأعلى إذا لم يجده في المجلد الجذر.

أضف الثوابت التالية إلى الملف فوق سطر « That’s all, stop editing »:

define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);
define('FORCE_SSL_ADMIN', true);
define('AUTOMATIC_UPDATER_DISABLED', false);
define('WP_AUTO_UPDATE_CORE', 'minor');
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

الثابت الأول يمنع تعديل ملفّات القوالب والإضافات من لوحة التحكّم. الثاني يمنع تثبيت إضافات جديدة من واجهة المسؤول. هذا يقلّل سطح الهجوم بشكل كبير إذا تمكّن مهاجم من سرقة بيانات حساب مسؤول. علامة النجاح: محاولة تعديل قالب من المظهر > محرّر القالب تعرض رسالة « تم تعطيل تعديل الملف ».

أعد توليد مفاتيح Salt من https://api.wordpress.org/secret-key/1.1/salt/ وانسخ النتيجة لاستبدال المفاتيح الحاليّة. هذا يبطل كل جلسات المستخدمين الحاليّة، بما فيها أي مهاجم قد يكون متّصلاً.

الخطوة 2: ضبط أذونات الملفات على الخادم

أذونات الملفّات هي الحاجز الذي يفصل بين كود قابل للتنفيذ وكود قابل للقراءة فقط. القاعدة الذهبيّة في ووردبريس: مجلّدات 755، ملفّات 644، و wp-config.php بأذونات 600 لمنع أي قراءة من مستخدمين آخرين على الخادم المشترك.

على خادم Linux مع وصول SSH، نفّذ الأوامر التالية من جذر الموقع:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
chown -R www-data:www-data .

الأمر الأخير يضمن أن صاحب الملفّات هو مستخدم خادم الويب فقط. علامة النجاح: تنفيذ ls -la على الجذر يعرض -rw------- لـ wp-config.php و -rw-r--r-- لباقي الملفّات.

على استضافة مشتركة لا توفّر وصول SSH (مثل بعض حزم Hostinger أو Bluehost الأساسيّة)، استخدم مدير الملفات في cPanel: انقر بزر اليمين على wp-config.php، اختر « Change Permissions »، وأدخل 600.

الخطوة 3: حماية لوحة wp-admin وصفحة wp-login

أكثر من 90٪ من محاولات الاختراق تستهدف /wp-login.php. الحلّ الأمثل: تغيير عنوان صفحة الدخول. الإضافة المجانيّة WPS Hide Login تتيح ذلك دون لمس ملفّات الـ core. ثبّتها، فعّلها، ثم في الإعدادات > WPS Hide Login اختر عنوانًا غير قابل للتخمين مثل /portail-2026-secure.

أضف طبقة ثانية عبر حماية HTTP Basic Auth على ملف wp-login.php من جانب الخادم. أضف إلى ملف .htaccess في الجذر:

<Files wp-login.php>
  AuthType Basic
  AuthName "Restricted Area"
  AuthUserFile /home/USER/.htpasswd
  Require valid-user
</Files>

أنشئ ملف .htpasswd بالأمر: htpasswd -c /home/USER/.htpasswd merass، وأدخل كلمة مرور مختلفة عن كلمة مرور ووردبريس. النتيجة: المهاجم يحتاج لتمرير حاجزين قبل الوصول لشاشة الدخول الفعليّة. علامة النجاح: زيارة /wp-login.php تعرض نافذة طلب اسم مستخدم وكلمة مرور للمتصفّح قبل صفحة ووردبريس.

الخطوة 4: تفعيل المصادقة الثنائيّة (2FA) للجميع

كلمة مرور قويّة وحدها لم تعد كافية. هجمات Credential Stuffing تستخدم كلمات مرور مسرّبة من مواقع أخرى. الحلّ هو 2FA إلزامي على كل حساب بصلاحيّة « Editor » فما فوق.

منذ أبريل 2026، أصبح Solid Security يُعرف باسم Kadence Security (الإصدار الحالي 10.0.1). يقدّم 2FA مدمجًا يدعم Google Authenticator، Authy، رموز البريد الإلكتروني، ورموز النسخ الاحتياطي. ثبّت الإضافة، انتقل إلى Security > Settings > Two-Factor، وفعّل « Required for User Groups » مع تحديد Administrators و Editors.

من نسخة 10.0.0، يولّد Kadence Security رمز QR محليًّا (يتطلّب امتداد GD في PHP) بدلاً من خدمة خارجيّة، ما يحسّن الخصوصيّة. علامة النجاح: المسؤول يدخل بكلمة مرور، يُطلب منه رمز TOTP من تطبيق المصادقة، ثم يصل للوحة. أي محاولة بكلمة مرور صحيحة لكن بدون TOTP تفشل فورًا.

الخطوة 5: نشر جدار حماية تطبيقي (WAF)

جدار الحماية التطبيقي يمنع طلبات HTTP الخبيثة قبل وصولها إلى ووردبريس. الخيار الأكثر انتشارًا هو Wordfence (الإصدار الحالي 8.2.2 في مايو 2026)، يتضمّن قواعد جدار حماية محدّثة في الوقت الحقيقي، فحص الأكواد الخبيثة، ومراقبة محاولات الدخول.

بعد التثبيت، نفّذ معالج البداية، ثم انتقل إلى Wordfence > Firewall > All Firewall Options. حدّد « Web Application Firewall Status » على « Enabled and Protecting ». للحصول على حماية أقوى، فعّل وضع « Extended Protection » الذي يحمّل القواعد قبل WordPress core نفسه. هذا يمنع الهجمات حتى لو كانت ثغرة في core نفسه.

للأداء العالي، استخدم Cloudflare كطبقة WAF خارجيّة. الباقة المجانيّة تكفي لمعظم المواقع المتوسّطة، وتقدّم حماية DDoS وفلترة على مستوى edge قبل أن يصل أي طلب إلى خادمك. علامة النجاح: لوحة Wordfence تُظهر « Blocked Attacks » بأرقام إيجابيّة (الإضافة تحمي فعليًا) دون « Failed Logins » مزدوجة.

الخطوة 6: التصلّب عبر قواعد .htaccess

إضافة طبقة دفاع على مستوى Apache توقف هجمات قبل تنفيذ PHP. أضف هذه القواعد إلى .htaccess في الجذر:

# منع تنفيذ PHP في مجلد الرفع
<Directory wp-content/uploads>
  <Files *.php>
    deny from all
  </Files>
</Directory>

# منع الوصول لـ xmlrpc.php
<Files xmlrpc.php>
  Order allow,deny
  Deny from all
</Files>

# منع تصفّح المجلدات
Options -Indexes

# منع الوصول لملفّات حسّاسة
<FilesMatch "(\.htaccess|\.htpasswd|wp-config\.php|readme\.html|license\.txt)">
  Order allow,deny
  Deny from all
</FilesMatch>

المنع الأول يبطل أحد أكثر متجهات الهجوم شيوعًا: مهاجم يرفع ملفًا .jpg.php كصورة منتج، ثم يحاول تنفيذه. حظر xmlrpc.php يبطل هجوم تضخيم Brute Force الكلاسيكي عبر system.multicall. علامة النجاح: محاولة فتح https://example.com/readme.html تعيد 403 Forbidden.

الخطوة 7: حماية قاعدة البيانات

غيّر بادئة الجداول الافتراضيّة wp_ إلى شيء عشوائي قبل التثبيت. على موقع موجود مسبقًا، استخدم Kadence Security > Advanced > Database Prefix لتنفيذ التغيير بأمان. لا تقم بالتغيير يدويًا في phpMyAdmin: ستحتاج لتحديث 20+ مرجعًا داخل الجداول نفسها.

حدّد مستخدم قاعدة بيانات منفصلًا لا يملك صلاحيّات GRANT أو DROP. في phpMyAdmin، أنشئ مستخدمًا جديدًا، امنحه فقط SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX على قاعدة بيانات الموقع. هذا يحدّ من الضرر إذا تمكّن مهاجم من استخراج بيانات الاتّصال من wp-config.

فعّل النسخ الاحتياطي الآلي خارج الخادم. الإضافة UpdraftPlus المجانيّة تنسخ احتياطيًا إلى Google Drive أو Dropbox أو Amazon S3. اضبط النسخ اليومي لقاعدة البيانات والأسبوعي للملفّات. علامة النجاح: استرجاع تجريبي من نسخة احتياطيّة على موقع staging يعيد كل البيانات والملفّات الحاليّة.

الخطوة 8: مراقبة الفحص الأمني الدوري

الحماية بدون مراقبة عمياء. شغّل فحصًا أسبوعيًا على ثلاثة مستويات:

فحص الأكواد الخبيثة: عبر Wordfence Scanner أو خدمة Sucuri المجانيّة على sitecheck.sucuri.net. يبحث عن backdoors، roots، إعادة توجيه خبيثة.
فحص الثغرات في الإضافات: Kadence Security يدمج Patchstack الذي يقارن إضافاتك بقاعدة بيانات ثغرات مستحدثة، وينبّهك خلال ساعات من اكتشاف ثغرة جديدة.
فحص سمعة IP: تأكّد أنّ IP خادمك ليس في قوائم سوداء عبر mxtoolbox.com/blacklists.aspx. إذا ظهر، اتّصل بمزوّد الاستضافة فورًا.

اضبط تنبيهات بريد فوريّة لأي تغيير في الملفّات الحسّاسة (wp-config، .htaccess، ملفّات core). علامة النجاح: تلقّيك بريدًا خلال دقائق من أي تعديل غير مصرّح به، بما فيه التحديثات التلقائيّة.

الخطوة 9: خطة استجابة للحوادث

إن وقع الاختراق رغم كل الحماية، اتّبع هذا التسلسل: (1) ضع الموقع في وضع الصيانة عبر إضافة WP Maintenance Mode. (2) غيّر كل كلمات المرور: ووردبريس، قاعدة البيانات، cPanel، FTP. (3) جدّد مفاتيح Salt في wp-config. (4) شغّل فحصًا كاملًا بـ Wordfence Premium للعثور على الأكواد الخبيثة. (5) قارن ملفّات core مع نسخة نظيفة من ووردبريس 6.9.4 الرسميّة عبر wp core verify-checksums في WP-CLI.

إذا لم تجد الأكواد الخبيثة في ساعتين، استعد نسخة احتياطيّة من قبل تاريخ الاختراق. لا تحاول « تنظيف » موقع مخترق بشكل سطحي؛ المهاجم يترك دائمًا backdoors متعدّدة. علامة النجاح بعد الحادثة: زيارة sitecheck.sucuri.net تعرض « Site is Clean » ولا تظهر إعادة توجيهات لمواقع مشبوهة.

الخلاصة وأولويّات التنفيذ

بناء أمن ووردبريس قويّ هو نهج طبقات وليس إعداد لمرّة واحدة. ابدأ بالأساسيّات: 2FA إلزامي، Kadence Security مفعّل، Cloudflare أمام الخادم، نسخ احتياطيّة آليّة خارج الخادم. ثم انتقل إلى التصلّب على مستوى الخادم: أذونات الملفّات، wp-config محمي، .htaccess صارم. أخيرًا، أنشئ روتين مراقبة أسبوعي. سنة من تطبيق هذه الممارسات يجعل موقعك ضمن أعلى 5٪ من مواقع ووردبريس أمانًا، ويقلّل احتماليّة الاختراق إلى ما يقارب الصفر العملي.

تأمين ووردبريس 2026: تصلّب متقدّم وحماية متعدّدة الطبقات للإنتاج