امنیت وردپرس با تغییر آدرس ورود، نصب یک افزونه یا اضافه‌کردن چند خط کد به .htaccess تمام نمی‌شود. یک سایت زمانی امنیت قابل‌قبولی دارد که چند لایه کنار هم درست کار کنند: نرم‌افزار به‌روز، دسترسی محدود، بکاپ سالم، فایروال، مانیتورینگ و برنامه مشخص برای زمانی که اتفاقی افتاد.

طبق گزارش وضعیت امنیت وردپرس در سال ۲۰۲۶، در سال ۲۰۲۵ بیش از ۱۱ هزار آسیب‌پذیری جدید در اکوسیستم وردپرس ثبت شده است. ۹۱ درصد آن‌ها به افزونه‌ها و ۹ درصد به قالب‌ها مربوط بوده‌اند؛ سهم هسته وردپرس فقط چند مورد کم‌اولویت بوده است. همین گزارش می‌گوید ۴۶ درصد آسیب‌پذیری‌ها هنگام انتشار عمومی هنوز اصلاح نشده بودند و آسیب‌پذیری‌های پرهدف گاهی ظرف چند ساعت مورد حمله قرار می‌گرفتند.

این آمار به این معنا نیست که وردپرس ذاتاً ناامن است. مسئله اصلی معمولاً از افزونه آسیب‌پذیر، نگهداری ضعیف، رمز تکراری، دسترسی اضافه، هاست نامناسب یا هشداری شروع می‌شود که کسی آن را ندیده است.

به‌روزرسانی مهم مرداد ۱۴۰۵: وردپرس در ۱۷ ژوئیه ۲۰۲۶ نسخه امنیتی 7.0.2 را برای رفع یک آسیب‌پذیری بحرانی و یک مورد با شدت بالا منتشر کرد. اگر هنوز از نسخه 7.0.1 یا پایین‌تر استفاده می‌کنید، سایت را بدون تأخیر به‌روزرسانی کنید. تیم وردپرس به‌دلیل شدت این نقص‌ها، به‌روزرسانی اجباری را برای نسخه‌های آسیب‌پذیر فعال کرده است.

قبل از تغییر تنظیمات امنیتی، فایل‌های وردپرس، فایروال یا سطح دسترسی‌ها، یک بکاپ کامل بگیرید. قانونی که روی Apache درست کار می‌کند، ممکن است روی Nginx کاربردی نداشته باشد یا روی یک هاست دیگر خطای ۵۰۰ ایجاد کند.

 

امنیت وردپرس دقیقاً یعنی چه؟

سایت امن فقط سایتی نیست که هنوز هک نشده باشد. امنیت یعنی:

• اطلاعات کاربران و تنظیمات حساس در اختیار افراد غیرمجاز قرار نگیرد.
• محتوا، سفارش‌ها، فایل‌ها و تنظیمات سایت بدون اجازه تغییر نکنند.
• سایت در زمان حمله یا خرابی قابل بازیابی باشد.
• فعالیت مشکوک قبل از ایجاد خسارت جدی شناسایی شود.
• در صورت نفوذ، مهاجم نتواند آزادانه به تمام بخش‌ها دسترسی پیدا کند.

راهنمای رسمی مقاوم‌سازی وردپرس نیز امنیت را یک فرایند مستمر برای کاهش ریسک، محدودکردن خسارت، بکاپ‌گیری، ثبت لاگ و مانیتورینگ می‌داند؛ نه رسیدن به یک وضعیت خیالی به نام «امنیت صددرصد».

اگر فقط چند دقیقه فرصت دارید، اول این کارها را انجام دهید:

1. وردپرس، افزونه‌ها و قالب را به آخرین نسخه امن ارتقا دهید.
2. افزونه‌ها و قالب‌های بدون استفاده را حذف کنید.
3. برای تمام مدیران ورود دومرحله‌ای فعال کنید.
4. از سایت بکاپ خارج از هاست بگیرید و بازیابی آن را آزمایش کنید.
5. حساب‌های مدیر اضافی و اتصال‌های قدیمی را حذف کنید.
6. هشدار آسیب‌پذیری، ورود مشکوک و تغییر فایل‌ها را فعال کنید.

 

به‌روزرسانی و مدیریت افزونه‌ها

۱. وردپرس، افزونه‌ها، قالب و PHP را به‌روز نگه دارید

بخش بزرگی از حملات وردپرسی روی نقص‌هایی انجام می‌شود که اصلاحیه آن‌ها از قبل منتشر شده، اما مدیر سایت هنوز نسخه جدید را نصب نکرده است.

این موارد باید مرتب بررسی شوند:

• هسته وردپرس
• افزونه‌های فعال و غیرفعال
• قالب فعال و قالب‌های نصب‌شده
• نسخه PHP
• کتابخانه‌های PHP و JavaScript
• کدها و افزونه‌های اختصاصی
• پنل هاست و سرویس‌های متصل به سایت

برای یک سایت ساده، فعال‌بودن آپدیت‌های امنیتی خودکار تصمیم بدی نیست. در فروشگاه‌ها و پروژه‌هایی که کدنویسی اختصاصی دارند، آپدیت باید با بکاپ، تست روی Staging و بررسی سلامت سایت همراه باشد.

این موضوع را با «عقب‌انداختن آپدیت» اشتباه نگیرید. اگر نقصی فعالانه مورد حمله قرار گرفته، چند روز صبرکردن برای تست کامل ممکن است ریسک بزرگ‌تری از خود آپدیت داشته باشد.

بعد از هر به‌روزرسانی مهم، حداقل این بخش‌ها را بررسی کنید:

• ورود و خروج کاربران
• فرم‌ها
• جست‌وجوی سایت
• پنل مدیریت
• ثبت سفارش
• درگاه پرداخت
• ایمیل‌های سیستمی
• Cron Jobها
• اتصال به CRM و سرویس‌های خارجی

۲. هاستی انتخاب کنید که امنیت را جدی می‌گیرد

عبارت «هاست مخصوص وردپرس» به‌تنهایی چیزی را ثابت نمی‌کند. قبل از خرید یا تمدید هاست، درباره این موارد سؤال کنید:

• جداسازی حساب‌های مختلف روی سرور
• نسخه‌های پشتیبانی‌شده PHP و دیتابیس
• فایروال و ModSecurity
• محافظت در برابر حملات DDoS
• اسکن بدافزار در سطح سرور
• محل نگهداری بکاپ
• تعداد نسخه‌های بکاپ
• امکان بازیابی اضطراری
• دسترسی SFTP یا SSH
• ثبت و نگهداری لاگ‌ها
• محیط Staging
• روش برخورد با سایت آلوده

اگر چند سایت مهم دارید، همه را داخل یک حساب هاست و زیر یک کاربر سیستم‌عامل قرار ندهید. آلودگی یک سایت نباید دسترسی نوشتن به فایل‌های تمام سایت‌های دیگر ایجاد کند.

وردپرس هم در مستندات رسمی خود هشدار می‌دهد که روی هاست اشتراکی ضعیف، نفوذ به یک سایت همسایه ممکن است سایت‌های دیگر همان سرور را در معرض خطر قرار دهد.

۳. افزونه‌ها و قالب‌های بلااستفاده را کاملاً حذف کنید

غیرفعال‌کردن یک افزونه به معنای حذف‌شدن کد آن از سرور نیست. فایل‌های افزونه همچنان در wp-content/plugins باقی می‌مانند و بعضی نقص‌ها حتی بدون فعال‌بودن افزونه نیز قابل سوءاستفاده‌اند.

برای هر افزونه این سؤال‌ها را بپرسید:

• آیا واقعاً هنوز به آن نیاز داریم؟
• آخرین نسخه آن روی سایت نصب شده؟
• توسعه‌دهنده هنوز محصول را نگهداری می‌کند؟
• با نسخه فعلی وردپرس و PHP سازگار است؟
• آسیب‌پذیری اصلاح‌نشده دارد؟
• همان قابلیت توسط افزونه دیگری هم ارائه می‌شود؟
• حذف آن چه چیزی را خراب می‌کند؟

فقط براساس تاریخ آخرین آپدیت تصمیم نگیرید. یک افزونه ساده ممکن است چند ماه نیازی به تغییر نداشته باشد، درحالی‌که افزونه‌ای که هفته قبل به‌روزرسانی شده هنوز نقص امنیتی داشته باشد.

برای کم‌کردن افزونه‌های اضافی و انتخاب ابزار مناسب، راهنمای بهترین افزونه‌های وردپرس برای انواع سایت را بخوانید. معمولاً برای هر وظیفه به یک ابزار اصلی نیاز دارید، نه سه افزونه با قابلیت‌های تقریباً یکسان.

۴. از افزونه و قالب نال‌شده استفاده نکنید

نسخه نال فقط یک فایل بدون لایسنس نیست. ممکن است کد آن دست‌کاری شده و شامل این موارد باشد:

• بک‌دور
• حساب مدیر مخفی
• ریدایرکت تبلیغاتی
• کد سرقت اطلاعات
• Webshell
• ارسال‌کننده اسپم
• JavaScript مخرب
• اتصال به سرور ناشناس
• مکانیزم نصب مجدد بدافزار

حتی اگر فایل نال در ابتدا سالم به نظر برسد، معمولاً آپدیت معتبر، پشتیبانی رسمی و امکان بررسی اصالت فایل را از دست می‌دهید.

فایل افزونه و قالب را فقط از مخزن رسمی وردپرس، وب‌سایت سازنده یا مارکت معتبر تهیه کنید. فایل ZIP ارسالی در کانال تلگرام یا فروشگاه ناشناس، منبع قابل‌اعتمادی نیست.

۵. امنیت زنجیره تأمین افزونه‌ها را هم در نظر بگیرید

دریافت افزونه از منبع رسمی ریسک را کم می‌کند، اما تضمین مطلق نیست. حساب توسعه‌دهنده، سرور آپدیت یا مالکیت یک افزونه ممکن است تصاحب شود.

در سال ۲۰۲۴ تعدادی از حساب‌های توسعه‌دهندگان WordPress.org با رمزهای تکراری و افشاشده تصاحب شدند و مهاجم از دسترسی آن‌ها برای انتشار آپدیت آلوده استفاده کرد. پس از این رخداد، وردپرس استفاده از 2FA و رمز جداگانه SVN را برای توسعه‌دهندگان افزونه و قالب اجباری کرد. در آوریل ۲۰۲۶ نیز یک حمله زنجیره تأمین بیش از ۲۰ افزونه یک توسعه‌دهنده را درگیر کرد.

برای سایت‌های حساس:

• قبل از آپدیت‌های بزرگ بکاپ بگیرید.
• تغییر مالکیت یا تیم توسعه افزونه را بررسی کنید.
• Changelog را بخوانید.
• افزونه‌های تجاری را فقط از کانال رسمی آپدیت کنید.
• تغییر غیرعادی فایل‌ها را مانیتور کنید.
• نسخه‌ها و افزونه‌های نصب‌شده را مستند نگه دارید.
• آپدیت‌های مهم را ابتدا روی Staging آزمایش کنید.
• حساب فروشنده، مارکت و سیستم لایسنس را با 2FA محافظت کنید.

۶. منتظر ظاهرشدن آپدیت در پیشخوان نمانید

گاهی افزونه‌ای آسیب‌پذیر است، اما هنوز اصلاحیه‌ای منتشر نشده. گاهی هم توسعه‌دهنده محصول را رها کرده یا افزونه از مخزن حذف شده است.

نام و نسخه افزونه‌های مهم را در دیتابیس‌های امنیتی جست‌وجو کنید:

• WPScan Vulnerability Database
• Patchstack Vulnerability Database
• Wordfence Intelligence

این منابع نشان می‌دهند نقص در چه نسخه‌هایی وجود دارد، چه سطح دسترسی برای حمله لازم است و مشکل در کدام نسخه اصلاح شده است.

اگر آخرین نسخه یک افزونه همچنان آسیب‌پذیر است، گزینه‌های واقعی شما این‌ها هستند:

• غیرفعال‌کردن موقت
• حذف افزونه
• جایگزینی با ابزار دیگر
• بستن Endpoint آسیب‌پذیر
• اعمال قانون موقت WAF
• محدودکردن دسترسی تا زمان انتشار اصلاحیه

فقط به امتیاز CVSS نگاه نکنید. نقصی با امتیاز متوسط که بدون ورود قابل‌استفاده است و روی افزونه‌ای محبوب قرار دارد، ممکن است برای سایت شما فوری‌تر از نقصی با امتیاز بالاتر باشد که دسترسی مدیر می‌خواهد.

 

امنیت ورود و حساب‌های کاربری

۷. برای هر حساب یک رمز طولانی و منحصربه‌فرد بسازید

رمز مناسب باید:

• برای همان حساب ساخته شده باشد.
• در سایت دیگری استفاده نشده باشد.
• طول کافی داشته باشد.
• از نام، شماره موبایل، تاریخ تولد و نام برند ساخته نشده باشد.
• داخل مرورگر یا فایل متنی مشترک بدون محافظت رها نشده باشد.

به‌جای حفظ‌کردن ده‌ها رمز، از Password Manager استفاده کنید. هر حساب باید رمز مستقل داشته باشد:

• وردپرس
• هاست
• ایمیل
• رجیسترار دامنه
• Cloudflare
• فضای بکاپ
• سرویس SMTP
• درگاه پرداخت
• مارکت افزونه و قالب
• مخزن Git

تغییر دوره‌ای رمز سالم بدون دلیل، ارزش زیادی ندارد. رمز را زمانی عوض کنید که احتمال افشا وجود دارد، همکاری شخصی تمام شده، دستگاهی گم شده یا حادثه امنیتی رخ داده است.

۸. ورود دومرحله‌ای یا Passkey را برای مدیران فعال کنید

رمز قوی هم ممکن است از طریق فیشینگ، بدافزار، نشت اطلاعات یا سیستم آلوده سرقت شود. ورود دومرحله‌ای باعث می‌شود داشتن رمز به‌تنهایی برای ورود کافی نباشد.

حداقل برای این حساب‌ها 2FA فعال کنید:

• مدیران وردپرس
• مدیر فروشگاه
• حساب هاست
• ایمیل مدیر سایت
• حساب CDN
• فضای بکاپ
• رجیسترار دامنه
• سرویس‌های مالی

برای ورود دومرحله‌ای، کدهای TOTP و Passkey انتخاب‌های مناسبی هستند. Passkey در برابر بسیاری از حملات فیشینگ مقاوم‌تر است، چون ورود به دامنه و دستگاه کاربر متصل می‌شود. راهنمای رسمی وردپرس نیز 2FA، Passkey و رمز قوی را از دفاع‌های اصلی ورود می‌داند.

کدهای بازیابی را داخل همان گوشی نگه ندارید. یک نسخه امن در Password Manager یا محل جداگانه ذخیره کنید و دسترسی اضطراری را از قبل آزمایش کنید.

۹. تلاش‌های ورود را با Rate Limiting کنترل کنید

وردپرس به‌صورت پیش‌فرض جلوی تعداد زیاد تلاش ورود را به شکل سخت‌گیرانه نمی‌گیرد. ربات‌ها نیز معمولاً از یک IP ثابت استفاده نمی‌کنند؛ بنابراین مسدودکردن دائمی یک IP بعد از سه تلاش، راه‌حل کاملی نیست.

ترکیب مناسب‌تر:

• Rate Limiting
• تأخیر افزایشی پس از خطا
• مسدودسازی موقت رفتار مشکوک
• 2FA
• CAPTCHA یا Cloudflare Turnstile در شرایط لازم
• WAF
• ثبت لاگ ورود
• محدودیت روی /wp-login.php
• محدودیت روی XML-RPC در صورت استفاده

قفل‌کردن سخت IP ممکن است کاربران واقعی پشت اینترنت موبایل یا شبکه اشتراکی را هم مسدود کند. تمرکز را روی رفتار درخواست، حساب کاربری و الگوی حمله بگذارید.

برای پیاده‌سازی این تنظیمات می‌توانید از یک افزونه امنیتی معتبر استفاده کنید. در آموزش پیکربندی افزونه All-In-One Security بخش‌های ورود، فایروال، CAPTCHA، 2FA و بررسی فایل‌ها را توضیح داده‌ام.

۱۰. اصل کمترین سطح دسترسی را اجرا کنید

هر حساب مدیر یک مسیر احتمالی برای تصاحب کامل سایت است. نویسنده، سئوکار، پشتیبان، حسابدار یا مسئول سفارش‌ها معمولاً نیازی به Administrator ندارند.

این موارد را بررسی کنید:

• تعداد مدیران سایت
• حساب همکاران قبلی
• کاربران آزمایشی
• حساب‌های بدون فعالیت
• مدیران با ایمیل ناشناس
• کاربرانی که نقش محدودتری برایشان کافی است
• حساب‌هایی که بدون اطلاع شما ساخته شده‌اند

برای هر فرد حساب جدا بسازید. استفاده چند نفر از یک حساب مشترک، پیگیری تغییرات را تقریباً غیرممکن می‌کند.

پس از پایان همکاری:

1. نقش یا حساب فرد را حذف کنید.
2. نشست‌های فعال او را ببندید.
3. Application Passwordها را حذف کنید.
4. دسترسی Git، هاست، CDN و فضای بکاپ را بررسی کنید.
5. کلیدهایی را که در اختیار او بوده‌اند تغییر دهید.

۱۱. نشست‌ها و Application Passwordها را فراموش نکنید

ممکن است رمز یک کاربر تغییر کرده باشد، اما نشست قبلی او یا اتصال یک نرم‌افزار خارجی همچنان فعال باشد.

داخل پروفایل کاربران مهم این موارد را بررسی کنید:

• نشست‌های فعال
• دستگاه‌های قدیمی
• Application Passwordها
• اتصال اپلیکیشن موبایل
• ابزارهای انتشار محتوا
• سرویس‌های اتوماسیون
• افزونه‌های مدیریت چند سایت

Application Password برای اتصال API و نرم‌افزار خارجی ساخته شده و باید مثل API Key مدیریت شود. برای هر سرویس یک رمز جدا با نام واضح بسازید و پس از پایان استفاده آن را حذف کنید. وردپرس برای فهرست‌کردن و حذف این رمزها API و دستورهای WP-CLI جداگانه دارد.

در زمان احتمال نفوذ:

• همه نشست‌های وردپرس را ببندید.
• Application Passwordها را لغو کنید.
• کلیدهای امنیتی WordPress Salts را تغییر دهید.
• Tokenهای API و Webhook را عوض کنید.
• نشست‌های ایمیل، هاست و CDN را هم بررسی کنید.

۱۲. امنیت ایمیل، دامنه و دستگاه مدیر را جدی بگیرید

اگر مهاجم به ایمیل مدیر دسترسی پیدا کند، ممکن است رمز وردپرس، هاست یا سرویس‌های دیگر را بازیابی کند. اگر حساب رجیسترار یا DNS تصاحب شود، حتی بدون ورود به وردپرس می‌توان ترافیک سایت و ایمیل‌ها را منحرف کرد.

برای ایمیل و دامنه:

• 2FA فعال کنید.
• رمز اختصاصی داشته باشید.
• Registrar Lock را روشن کنید.
• تغییرات DNS را مانیتور کنید.
• کد انتقال دامنه را امن نگه دارید.
• دسترسی افراد قدیمی را حذف کنید.
• رکوردهای DNS ناشناس را بررسی کنید.

سیستم شخصی مدیر سایت نیز بخشی از امنیت وردپرس است. بدافزار روی لپ‌تاپ می‌تواند رمز SFTP، کوکی ورود، کلید API یا اطلاعات پنل را سرقت کند. سیستم‌عامل، مرورگر، افزونه‌های مرورگر و آنتی‌ویروس را به‌روز نگه دارید و از ورود به پنل مدیریت در دستگاه ناشناس پرهیز کنید.

راهنمای رسمی وردپرس برای سایت‌های هک‌شده نیز اسکن دستگاه مدیر را بخشی از بررسی حادثه می‌داند، چون نقطه ورود همیشه خود سایت نیست.

 

امنیت ارتباط، سرور و فایل‌ها

۱۳. HTTPS و SFTP را به‌درستی استفاده کنید

HTTPS ارتباط میان مرورگر و سرور را رمزنگاری می‌کند. بدون HTTPS، رمز ورود، کوکی و اطلاعات فرم‌ها ممکن است در شبکه ناامن قابل رهگیری باشند.

اما HTTPS:

• افزونه آسیب‌پذیر را اصلاح نمی‌کند.
• بدافزار را شناسایی نمی‌کند.
• جلوی رمز سرقت‌شده را نمی‌گیرد.
• جای 2FA و WAF نیست.

گواهی SSL را از طریق هاست، سرور یا CDN فعال کنید و تمام درخواست‌های HTTP را به HTTPS منتقل کنید. Mixed Content، آدرس‌های قدیمی و منابع خارجی ناامن را نیز بررسی کنید.

برای انتقال فایل به‌جای FTP معمولی از SFTP یا SSH استفاده کنید. FTP اطلاعات ورود را به شکل مناسبی رمزنگاری نمی‌کند، درحالی‌که SFTP ارتباط را داخل یک کانال امن قرار می‌دهد.

۱۴. WAF را قبل از رسیدن درخواست به وردپرس قرار دهید

افزونه فایروال داخل وردپرس مفید است، اما درخواست ابتدا به سرور و PHP رسیده و بعد توسط افزونه بررسی می‌شود. WAF لبه شبکه می‌تواند بخشی از ربات‌ها، DDoS و درخواست‌های مخرب را قبل از رسیدن به هاست فیلتر کند.

سرویس‌هایی مثل Cloudflare یا WAF میزبان می‌توانند برای این موارد استفاده شوند:

• Rate Limiting
• مقابله با DDoS
• مدیریت Bot
• فیلتر درخواست‌های مخرب
• محدودکردن صفحه ورود
• محافظت موقت از Endpoint آسیب‌پذیر
• مخفی‌کردن IP اصلی سرور

WAF نباید باعث ایجاد حس امنیت کاذب شود. Broken Access Control، رمز سرقت‌شده، دسترسی داخلی یا افزونه‌ای که درخواست ظاهراً عادی را بدون کنترل مجوز اجرا می‌کند، همیشه با فایروال عمومی قابل تشخیص نیست.

راهنمای امنیت وردپرس Cloudflare نیز WAF را یک لایه دفاعی در کنار آپدیت، کنترل دسترسی، اسکن و بکاپ معرفی می‌کند.

بعد از فعال‌کردن WAF یا اسکن امنیتی، تأثیر آن را روی منابع سرور و سرعت بررسی کنید. برای این کار می‌توانید از راهنمای افزایش سرعت وردپرس و مقاله بهترین ابزارهای تحلیل سرعت سایت استفاده کنید.

۱۵. مالکیت و سطح دسترسی فایل‌ها را درست تنظیم کنید

در بسیاری از هاست‌ها، مقادیر رایج این‌ها هستند:

• پوشه‌ها: 755
• فایل‌ها: 644

اما این اعداد نسخه قطعی برای تمام سرورها نیستند. نوع اجرای PHP، مالک فایل، گروه وب‌سرور و معماری هاست اهمیت دارد.

اصول مهم‌تر:

• فایل و پوشه بدون دلیل روی 777 نباشد.
• افزونه‌ها امکان نوشتن در تمام سایت را نداشته باشند.
• مالکیت فایل‌ها با کاربر صحیح تنظیم شود.
• هر سایت کاربر و فضای جداگانه داشته باشد.
• wp-config.php فقط برای افراد و پردازش‌های ضروری قابل‌خواندن باشد.
• دسترسی نوشتن موقت بعد از پایان کار بسته شود.

تغییر Permission به‌تنهایی جلوی آسیب‌پذیری PHP را نمی‌گیرد. اگر پردازش PHP مجاز باشد فایلی را با دسترسی همان کاربر تغییر دهد، صرفاً دیدن عدد 644 به معنای امن‌بودن نیست.

۱۶. از wp-config.php محافظت و ویرایش فایل را غیرفعال کنید

فایل wp-config.php حاوی اطلاعات دیتابیس، کلیدهای امنیتی و تنظیمات حساس است. این فایل نباید از طریق وب قابل دانلود باشد یا نسخه‌های قدیمی آن با پسوندهایی مثل .bak روی سرور باقی بمانند.

در Apache 2.4 و LiteSpeed می‌توان دسترسی مستقیم را با این قانون محدود کرد:

<Files "wp-config.php">
    Require all denied
</Files>

این کد برای Nginx نیست. در Nginx باید قانون معادل داخل تنظیمات سرور نوشته شود.

ویرایشگر داخلی فایل‌های قالب و افزونه را نیز روی سایت اصلی غیرفعال کنید:

define( 'DISALLOW_FILE_EDIT', true );

این تنظیم جلوی تمام روش‌های آپلود کد را نمی‌گیرد، اما اگر حساب مدیر تصاحب شود، امکان ویرایش مستقیم PHP از داخل پیشخوان را محدود می‌کند.

روی سایت اصلی، خطاهای PHP را به کاربران نشان ندهید:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

اگر این ثابت‌ها از قبل داخل فایل وجود دارند، مقدار همان‌ها را تغییر دهید و تعریف تکراری نسازید.

نمایش خطا ممکن است مسیر کامل فایل‌ها، نام افزونه، Query دیتابیس، Stack Trace یا اطلاعات فنی سرور را افشا کند. مستندات رسمی وردپرس نیز فعال‌بودن display_errors را برای محیط Production مناسب نمی‌داند.

۱۷. اجرای PHP را در Uploads ببندید

پوشه wp-content/uploads برای تصاویر، ویدئوها و فایل‌های رسانه‌ای ساخته شده است. در حالت معمول نباید فایل PHP داخل این پوشه اجرا شود.

در Apache 2.4 یا LiteSpeed می‌توانید یک فایل .htaccess داخل پوشه Uploads بسازید:

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

این تنظیم را ابتدا روی Staging امتحان کنید. افزونه‌ای که برای کار عادی خود به اجرای PHP داخل Uploads نیاز دارد، از نظر معماری نیز باید با دقت بیشتری بررسی شود.

در Nginx قانون معادل باید در کانفیگ سرور اعمال شود. از پشتیبانی هاست یا مدیر سرور بخواهید اجرای PHP را در Uploads، پوشه‌های بکاپ و مسیرهای غیرضروری ببندد.

امنیت آپلود فقط با بررسی پسوند تمام نمی‌شود. فرم‌های آپلود باید:

• فقط پسوندهای لازم را بپذیرند.
• نوع واقعی فایل را بررسی کنند.
• به هدر Content-Type اعتماد نکنند.
• نام فایل را در سمت سرور تولید کنند.
• محدودیت حجم داشته باشند.
• از آپلود ZIP Bomb جلوگیری کنند.
• SVG را غیرفعال یا با Sanitizer معتبر پاک‌سازی کنند.
• دسترسی آپلود را به کاربران مجاز محدود کنند.
• فایل را در مسیر غیرقابل‌اجرا ذخیره کنند.

راهنمای امنیت آپلود فایل OWASP نیز بر Allowlist پسوند، بررسی نوع فایل، تغییر نام، محدودیت حجم و ذخیره خارج از Web Root تأکید دارد.

۱۸. Directory Listing و فایل‌های حساس را ببندید

اگر Directory Listing فعال باشد، ممکن است بازدیدکننده بتواند فهرست فایل‌های پوشه‌ای بدون فایل Index را ببیند.

روی Apache و LiteSpeed معمولاً این دستور آن را غیرفعال می‌کند:

Options -Indexes

این فایل‌ها نباید داخل مسیر عمومی سایت باقی بمانند:

• backup.zip
• database.sql
• فایل‌های .tar.gz
• خروجی افزونه‌های مهاجرت
• فایل .env
• debug.log
• نسخه قدیمی wp-config.php
• فایل‌های .bak و .old
• phpinfo.php
• فایل نصب Duplicator
• پوشه .git
• آرشیو قالب و افزونه
• گزارش‌های حاوی Token یا رمز

یک فایل بکاپ کامل ممکن است دیتابیس، اطلاعات کاربران، رمز دیتابیس، کلید API و تنظیمات پرداخت را یکجا در اختیار مهاجم قرار دهد.

بکاپ را خارج از public_html یا روی فضای ذخیره‌سازی جدا نگه دارید. اگر مجبورید موقتاً فایل بزرگی را داخل هاست قرار دهید، نام تصادفی و محدودیت دسترسی کافی نیست؛ بعد از استفاده آن را حذف کنید.

۱۹. امنیت دیتابیس را به تغییر Prefix محدود نکنید

برای هر سایت دیتابیس و کاربر دیتابیس جدا بسازید. کاربر دیتابیس فقط باید به همان دیتابیس دسترسی داشته باشد.

رمز دیتابیس باید:

• طولانی و تصادفی باشد.
• بین چند سایت مشترک نباشد.
• داخل Git یا فایل ZIP پروژه قرار نگیرد.
• فقط در محل موردنیاز ذخیره شود.
• هنگام احتمال افشا تغییر کند.

دسترسی مستقیم دیتابیس از اینترنت را بدون نیاز فعال نگذارید. ابزارهایی مثل phpMyAdmin و Adminer نیز نباید با آدرس قابل‌حدس و بدون محافظت رها شوند.

تغییر پیشوند wp_ جلوی SQL Injection را نمی‌گیرد. اگر یک افزونه Query ناامن اجرا کند، راه‌حل واقعی اصلاح کد، استفاده از $wpdb->prepare()، اعتبارسنجی ورودی یا حذف افزونه آسیب‌پذیر است.

در پاک‌سازی دیتابیس هم عجله نکنید. حذف جدول یا Option ناشناس بدون بررسی ممکن است سایت را خراب کند. از داده‌ها بکاپ بگیرید و جداول یتیم را با وابستگی افزونه‌ها تطبیق دهید.

۲۰. Security Headerها را متناسب با سایت تنظیم کنید

هدرهای امنیتی به مرورگر می‌گویند منابع صفحه را با چه محدودیت‌هایی اجرا کند. این هدرها آسیب‌پذیری اصلی را اصلاح نمی‌کنند، اما اثر برخی حملات را محدود می‌کنند.

هدرهای مهم:

• Content-Security-Policy
• Strict-Transport-Security
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy
• frame-ancestors در CSP یا X-Frame-Options

CSP را بدون بررسی از اینترنت کپی نکنید. سیاست بیش از حد سخت ممکن است درگاه پرداخت، فونت، ویدئو، آنالیتیکس، CAPTCHA یا اسکریپت‌های ضروری را متوقف کند.

ابتدا CSP را در حالت Report-Only اجرا کنید، گزارش‌ها را ببینید و بعد آن را اجباری کنید. HSTS نیز فقط زمانی فعال شود که تمام دامنه‌ها و زیردامنه‌های موردنظر به‌درستی از HTTPS استفاده می‌کنند.

 

بکاپ، پایش و شناسایی نفوذ

۲۱. بکاپی بسازید که واقعاً قابل بازیابی باشد

وجود فایل ZIP در هاست به معنای داشتن بکاپ مطمئن نیست.

یک سیستم بکاپ مناسب باید:

• فایل‌ها و دیتابیس را پوشش دهد.
• خودکار باشد.
• نسخه‌های زمانی مختلف داشته باشد.
• فقط روی همان سرور ذخیره نشود.
• در برابر حذف یا باج‌افزار محافظت شود.
• دسترسی محدود داشته باشد.
• گزارش موفق یا ناموفق‌بودن بکاپ ارسال کند.
• دوره‌ای بازیابی شود.

فاصله بکاپ به میزان تغییر سایت بستگی دارد. سؤال اصلی این است:

اگر سایت خراب شود، از دست‌رفتن چند ساعت اطلاعات برای کسب‌وکار قابل‌تحمل است؟

برای سایت شرکتی کم‌تغییر، بکاپ روزانه ممکن است کافی باشد. فروشگاهی که هر ساعت سفارش می‌گیرد، شاید به بکاپ دیتابیس چند بار در روز نیاز داشته باشد.

روش عملی 3-2-1:

• حداقل سه نسخه از اطلاعات
• روی دو نوع فضای ذخیره‌سازی
• حداقل یک نسخه خارج از سرور اصلی

هر چند وقت یک‌بار سایت را روی محیط آزمایشی بازیابی کنید. بکاپی که Restore آن آزمایش نشده، در زمان بحران قابل‌اعتماد نیست.

۲۲. لاگ، تغییر فایل و رفتار غیرعادی را مانیتور کنید

اسکن ماهانه کافی نیست. بسیاری از آلودگی‌ها طوری طراحی شده‌اند که مدیر سایت متوجه آن‌ها نشود.

این موارد را مانیتور کنید:

• ورود موفق و ناموفق مدیران
• ایجاد حساب Administrator
• تغییر نقش کاربران
• نصب و حذف افزونه
• تغییر تنظیمات درگاه
• تغییر فایل‌های PHP
• تغییر مکرر .htaccess
• افزایش خطاهای ۴۰۴ و ۵۰۰
• افزایش مصرف CPU
• ارسال غیرعادی ایمیل
• تغییر DNS
• Downtime
• هشدار Search Console
• ریدایرکت کاربران
• صفحات اسپم ایندکس‌شده

برای بررسی فایل‌های هسته با WP-CLI:

wp core verify-checksums

برای افزونه‌های دریافت‌شده از WordPress.org:

wp plugin verify-checksums --all

این دستورها محدودیت دارند. دیتابیس، Uploads، افزونه‌های تجاری و فایل‌های خارج از وردپرس را بررسی نمی‌کنند. برای افزونه‌های اختصاصی و تجاری بهتر است Baseline یا نسخه سالم مرجع داشته باشید.

اسکن داخلی و خارجی را کنار هم استفاده کنید. اسکنر داخلی فایل‌ها را می‌بیند، اما ممکن است روی سرور آلوده اجرا شود. اسکن خارجی رفتار قابل‌مشاهده برای کاربر را بررسی می‌کند، اما فایل مخفی را نمی‌بیند.

۲۳. mu-plugins، Cron، Staging و اتصال‌های مخفی را بررسی کنید

بدافزار همیشه در فهرست معمولی افزونه‌ها دیده نمی‌شود.

پوشه زیر را بررسی کنید:

wp-content/mu-plugins/

فایل‌های Must-Use Plugin خودکار اجرا می‌شوند و مثل افزونه‌های عادی دکمه فعال یا غیرفعال ندارند. اگر خودتان چنین افزونه‌ای نصب نکرده‌اید، وجود فایل ناشناس در این مسیر نیاز به بررسی فوری دارد.

این بخش‌ها نیز ممکن است برای ماندگاری بدافزار استفاده شوند:

• WP-Cron
• Cron سیستم‌عامل
• WooCommerce Action Scheduler
• wp_options
• تنظیمات Header و Footer
• افزونه‌های Code Snippet
• Elementor Data
• Object Cache و Redis
• فایل‌های Cache
• .user.ini
• php.ini
• پوشه‌های سایت‌های دیگر

برای مشاهده رویدادهای WP-Cron:

wp cron event list

در ووکامرس، بخش Scheduled Actions را هم بررسی کنید. فایل مخربی که بعد از حذف دوباره ساخته می‌شود، معمولاً یک مکانیزم بازسازی در Cron، حافظه، دیتابیس یا فایل دیگری دارد.

نسخه‌های Staging، Dev و قدیمی سایت را رها نکنید. این محیط‌ها معمولاً دیرتر آپدیت می‌شوند و گاهی همان اطلاعات، رمزها و APIهای سایت اصلی را دارند.

Staging باید:

• با رمز، IP Allowlist یا VPN محافظت شود.
• از دیتابیس و Secretهای مستقل استفاده کند.
• برای موتورهای جست‌وجو بسته باشد.
• بعد از پایان پروژه حذف شود.
• فایل‌های بکاپ و Export را در مسیر عمومی نگه ندارد.

 

امنیت API، کدنویسی و فروشگاه

۲۴. REST API، Webhook و کد اختصاصی را امن بنویسید

REST API وردپرس به‌خودی‌خود حفره امنیتی نیست. ویرایشگر بلوک، ووکامرس و بسیاری از افزونه‌ها به آن وابسته‌اند. خطر زمانی شکل می‌گیرد که یک Endpoint بدون کنترل مجوز، اعتبارسنجی یا احراز هویت ساخته شود.

در کد اختصاصی:

• ورودی را Validate کنید.
• در صورت نیاز Sanitize کنید.
• خروجی را متناسب با Context، Escape کنید.
• برای عملیات حساس Capability را بررسی کنید.
• از Nonce برای کاهش CSRF استفاده کنید.
• Nonce را جایگزین مجوز دسترسی ندانید.
• Query را با $wpdb->prepare() بسازید.
• آپلود فایل را با Allowlist کنترل کنید.
• روی URLهای دریافتی محدودیت مقصد اعمال کنید.
• داده غیرقابل‌اعتماد را unserialize() نکنید.
• امضای Webhook را بررسی کنید.
• Token را داخل URL و Log قرار ندهید.

نمونه ساده:

if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( esc_html__( 'اجازه دسترسی ندارید.', 'my-plugin' ) );
}

check_admin_referer( 'save_security_settings' );

$value = sanitize_text_field(
    wp_unslash( $_POST['value'] ?? '' )
);

update_option( 'my_security_option', $value );

هنگام نمایش:

echo esc_html( $value );

Nonce فقط نشان می‌دهد درخواست احتمالاً از مسیر موردانتظار آمده است؛ مجوز کاربر را ثابت نمی‌کند. مستندات وردپرس صراحتاً می‌گوید برای کنترل دسترسی باید از توابعی مثل current_user_can() استفاده شود.

اگر افزونه‌ای URL دریافت می‌کند تا تصویر، فید یا فایل دانلود کند، خطر SSRF را در نظر بگیرید. مقصدها باید با Allowlist کنترل شوند و دسترسی به IPهای داخلی، Loopback و سرویس‌های Metadata بسته باشد. برای این موضوع، راهنمای SSRF در OWASP مرجع مناسبی است.

وابستگی‌های پروژه را هم بررسی کنید:

composer audit
npm audit

فایل‌های composer.lock و Lockfileهای JavaScript را نگه دارید، پکیج بلااستفاده را حذف کنید و اسکریپت خارجی را بدون نیاز از CDN ناشناس بارگیری نکنید.

۲۵. امنیت ووکامرس را جداگانه مدیریت کنید

فروشگاه اینترنتی دائماً در حال تغییر است. سفارش، موجودی، کاربر، تخفیف، پرداخت و اطلاعات ارسال ممکن است هر ساعت تغییر کنند؛ بنابراین همان برنامه بکاپ و مانیتورینگ سایت شرکتی برای فروشگاه کافی نیست.

اقدامات مهم ووکامرس:

• بکاپ دیتابیس چند بار در روز، متناسب با تعداد سفارش
• 2FA برای مدیر و مدیر فروشگاه
• حساب جدا برای پشتیبان، انباردار و حسابدار
• بررسی تغییرات تنظیمات درگاه
• حذف API Keyهای قدیمی
• بررسی Webhookها
• Rate Limiting روی ورود و بازیابی رمز
• کنترل حملات Card Testing
• استفاده از درگاه رسمی
• بررسی Scheduled Actions
• محدودکردن افزونه‌های اتصال به CRM و حسابداری
• ثبت فعالیت مدیران
• مانیتورینگ سفارش و بازپرداخت غیرعادی

اطلاعات کارت بانکی مشتری نباید داخل وردپرس ذخیره شود. پرداخت باید در زیرساخت رسمی و امن درگاه انجام شود.

بعد از آپدیت مهم، مسیر واقعی خرید را تست کنید:

1. ثبت‌نام و ورود
2. افزودن محصول به سبد
3. اعمال کد تخفیف
4. انتخاب روش ارسال
5. انتقال به درگاه
6. بازگشت از پرداخت
7. ثبت سفارش
8. ارسال ایمیل‌ها
9. تغییر وضعیت سفارش
10. کاهش موجودی

 

اگر سایت هک شد چه کار کنیم؟

پاک‌کردن اولین فایل مشکوک و نصب یک افزونه امنیتی، پاک‌سازی کامل محسوب نمی‌شود. فایل مخرب ممکن است فقط نشانه نفوذ باشد، نه مسیر اصلی ورود.

۱. حادثه را مهار کنید

• دسترسی‌های مشکوک را ببندید.
• در صورت نیاز سایت را موقتاً محدود کنید.
• قانون موقت WAF اعمال کنید.
• حساب مدیر ناشناس را غیرفعال کنید.
• از ایجاد تغییرات بیشتر جلوگیری کنید.

۲. قبل از پاک‌سازی شواهد را نگه دارید

• از وضعیت آلوده Snapshot بگیرید.
• فایل‌ها و دیتابیس را ذخیره کنید.
• لاگ‌ها را نگه دارید.
• زمان کشف و نشانه‌های مشاهده‌شده را ثبت کنید.
• تغییرات اخیر افزونه و قالب را یادداشت کنید.

حذف فوری همه‌چیز ممکن است مسیر نفوذ را پنهان کند و بررسی علت را دشوارتر سازد.

۳. دامنه نفوذ را مشخص کنید

بررسی کنید حادثه فقط وردپرس را درگیر کرده یا این بخش‌ها هم آسیب دیده‌اند:

• حساب هاست
• ایمیل
• DNS
• رجیسترار
• CDN
• فضای بکاپ
• دستگاه مدیر
• سایت‌های دیگر همان حساب
• Git و سرویس‌های توسعه
• APIهای مالی و تجاری

۴. تمام دسترسی‌های حساس را تغییر دهید

• رمز مدیران وردپرس
• هاست و SSH/SFTP
• دیتابیس
• ایمیل
• رجیسترار دامنه
• CDN
• SMTP
• فضای بکاپ
• API Keyها
• Webhook Secretها
• کلیدهای درگاه
• Application Passwordها
• WordPress Salts

رمزها را بعد از پاک‌سازی نهایی دوباره تغییر دهید؛ چون اگر هنگام تغییر اول، بدافزار هنوز فعال بوده باشد، اطلاعات جدید نیز ممکن است ثبت شده باشند.

۵. فایل‌های سالم را از منبع معتبر جایگزین کنید

برای سایت مهم، جایگزینی فایل‌های هسته، قالب و افزونه با نسخه سالم معمولاً مطمئن‌تر از اصلاح دستی تعداد زیادی فایل آلوده است.

این مسیرها را با نسخه رسمی جایگزین کنید:

• wp-admin
• wp-includes
• افزونه‌ها
• قالب‌ها

پوشه wp-content، Uploads و فایل‌های اختصاصی نیاز به بررسی دقیق‌تری دارند. فایل‌های جدیدی که مهاجم ساخته، با Overwrite ساده حذف نمی‌شوند.

۶. علت نفوذ را پیدا کنید

بررسی کنید مهاجم از کدام مسیر وارد شده:

• افزونه آسیب‌پذیر
• قالب نال
• رمز تکراری
• حساب ایمیل هک‌شده
• Session سرقت‌شده
• سیستم آلوده مدیر
• FTP ناامن
• Webhook بدون امضا
• Application Password قدیمی
• هاست مشترک آلوده
• API Key افشاشده
• کد اختصاصی ناامن

اگر فقط Payload را پاک کنید و مسیر ورود باز بماند، آلودگی برمی‌گردد.

راهنمای رسمی وردپرس برای سایت هک‌شده نیز روی مستندسازی حادثه، اسکن داخلی و خارجی، بررسی سیستم مدیر، تغییر تمام دسترسی‌ها، تهیه Snapshot، جایگزینی فایل‌های سالم و ریشه‌یابی تأکید دارد.

 

اقداماتی که مفیدند، اما نباید اولویت اصلی باشند

تغییر آدرس ورود

تغییر /wp-login.php ممکن است تعداد درخواست‌های ربات‌های ساده را کم کند، اما:

• افزونه آسیب‌پذیر را اصلاح نمی‌کند.
• جلوی Session دزدیده‌شده را نمی‌گیرد.
• جای 2FA و Rate Limiting نیست.
• بعضی جریان‌های ورود و بازیابی رمز را خراب می‌کند.

این کار یک لایه مکمل است، نه ستون اصلی امنیت.

تغییر پیشوند دیتابیس

انتخاب Prefix متفاوت هنگام نصب جدید ایرادی ندارد، اما تغییر wp_ روی سایت فعال ارزش امنیتی محدودی دارد و در صورت اجرای اشتباه ممکن است User Meta، نقش کاربران یا افزونه‌ها را خراب کند.

Prefix جلوی SQL Injection واقعی را نمی‌گیرد.

مخفی‌کردن نسخه وردپرس

حذف شماره نسخه از سورس صفحه مقدار کمی اطلاعات را پنهان می‌کند، اما ابزارهای اسکن از فایل‌های CSS، JavaScript و الگوهای دیگر نسخه احتمالی را حدس می‌زنند.

نسخه به‌روز بسیار مهم‌تر از نسخه مخفی است.

غیرفعال‌کردن XML-RPC

اگر سایت، Jetpack، اپلیکیشن موبایل یا ابزار مدیریت خارجی به XML-RPC نیاز ندارد، محدودکردن یا مسدودکردن آن منطقی است.

اما غیرفعال‌کردن بدون بررسی ممکن است اتصال‌های لازم را قطع کند. در صورت نیاز، Pingback و رفتارهای پرخطر را محدود و درخواست‌ها را Rate Limit کنید.

مسدودکردن دائمی کشورها

Geo-blocking برای بعضی کسب‌وکارهای کاملاً محلی مفید است، ولی مهاجم با VPN و سرور کشورهای دیگر محدودیت را دور می‌زند. مسدودسازی گسترده ممکن است کاربران واقعی، سرویس‌های ابری و ربات‌های معتبر را نیز حذف کند.

قانون را براساس رفتار و Threat Score تنظیم کنید، نه فقط نام کشور.

نصب چند افزونه امنیتی کامل

نصب هم‌زمان Wordfence، AIOS، Solid Security و ابزارهای مشابه معمولاً لازم نیست. این افزونه‌ها ممکن است هم‌زمان صفحه ورود، .htaccess، فایروال، REST API، XML-RPC و سطح دسترسی فایل‌ها را تغییر دهند.

نتیجه احتمالی:

• تداخل تنظیمات
• افت سرعت
• قفل‌شدن مدیر
• خطای درگاه
• افزایش مصرف CPU
• لاگ‌های تکراری
• تشخیص اشتباه درخواست سالم

معماری ساده‌تر انتخاب کنید:

• یک ابزار اصلی برای ورود و فایروال
• یک سیستم بکاپ مستقل
• یک ابزار پایش آسیب‌پذیری
• یک سرویس مانیتورینگ
• WAF سطح شبکه در صورت نیاز

 

برنامه نگهداری امنیت وردپرس

امنیت را نباید یک‌بار تنظیم و بعد فراموش کرد. اگر نگهداری سایت بین چند نفر تقسیم شده، مسئولیت هر بخش را مشخص کنید. مقاله وب‌مستر کیست و چه وظایفی دارد توضیح می‌دهد مدیریت فنی، به‌روزرسانی، مانیتورینگ و امنیت چگونه بخشی از نگهداری مستمر سایت هستند.

بررسی روزانه

• موفق‌بودن بکاپ
• در دسترس‌بودن سایت
• هشدار آسیب‌پذیری بحرانی
• ورود مشکوک مدیر
• هشدار فایروال
• تغییرات مهم فروشگاه
• ارسال غیرعادی ایمیل

بررسی هفتگی

• آپدیت هسته، افزونه و قالب
• کاربران مدیر
• تغییر فایل‌ها
• اسکن بدافزار
• خطاهای سرور
• افزونه‌های بلااستفاده
• Cron Jobهای ناشناس
• وضعیت Staging

بررسی ماهانه

• تست بازیابی بکاپ
• بازبینی سطح دسترسی کاربران
• بررسی Application Passwordها
• کنترل حساب‌های هاست، CDN و دامنه
• بررسی سرعت و منابع سرور
• مرور لاگ‌ها
• حذف فایل‌های بکاپ موقت
• بررسی افزونه‌های رهاشده
• به‌روزرسانی مستندات فنی سایت

 

سؤالات متداول درباره افزایش امنیت وردپرس

بهترین افزونه امنیتی وردپرس کدام است؟

یک پاسخ ثابت برای همه سایت‌ها وجود ندارد. Wordfence، AIOS، Solid Security، Patchstack، MalCare و Sucuri معماری و تمرکز متفاوتی دارند.

انتخاب باید براساس این موارد انجام شود:

• منابع هاست
• نوع سایت
• حجم ترافیک
• نیاز به WAF
• نیاز به اسکن بدافزار
• نیاز به پایش آسیب‌پذیری
• بودجه
• سطح دانش مدیر

برای بیشتر سایت‌ها، نصب یک افزونه امنیتی جامع کافی است.

آیا Cloudflare جلوی هک وردپرس را می‌گیرد؟

Cloudflare بخشی از ربات‌ها، DDoS و درخواست‌های مخرب را کنترل می‌کند، اما به‌تنهایی جلوی رمز سرقت‌شده، افزونه آسیب‌پذیر، کد اختصاصی ناامن یا دسترسی داخلی را نمی‌گیرد.

Cloudflare یک لایه امنیتی است، نه کل سیستم امنیت.

آیا REST API وردپرس خطرناک است؟

خیر. REST API بخشی از معماری جدید وردپرس است. خطر زمانی ایجاد می‌شود که یک افزونه یا کد اختصاصی Endpoint ناامن بسازد، permission_callback درستی نداشته باشد یا اطلاعات حساس را بدون مجوز برگرداند.

غیرفعال‌کردن کامل REST API ممکن است ویرایشگر وردپرس، ووکامرس و افزونه‌های مختلف را خراب کند.

هر چند وقت یک‌بار باید بکاپ بگیریم؟

فاصله بکاپ باید براساس میزان تغییر سایت تعیین شود.

اگر روزی یک محتوا منتشر می‌کنید، بکاپ روزانه ممکن است کافی باشد. اگر فروشگاه در هر ساعت چند سفارش دارد، بکاپ دیتابیس باید کوتاه‌تر باشد.

مهم‌تر از تعداد بکاپ، موفق‌بودن و قابل‌بازیابی‌بودن آن است.

از کجا بفهمیم سایت هک شده؟

نشانه‌های رایج:

• مدیر ناشناس
• فایل PHP جدید
• ریدایرکت کاربران
• صفحات اسپم در گوگل
• تغییر تنظیمات درگاه
• ارسال ایمیل انبوه
• کندی ناگهانی
• Cron Job مشکوک
• تغییر مکرر .htaccess
• هشدار مرورگر یا Search Console
• افزونه ناشناس
• مصرف غیرعادی منابع

بعضی بدافزارها فقط برای کاربران Logout شده، ورودی گوگل، IP خاص یا دستگاه موبایل نمایش داده می‌شوند. سایت را در Incognito، دستگاه و شبکه متفاوت نیز بررسی کنید.

آیا تغییر URL ورود سایت را امن می‌کند؟

خیر. این کار فقط ممکن است نویز ربات‌های ساده را کم کند. امنیت ورود به 2FA، رمز منحصربه‌فرد، Rate Limiting، WAF و مدیریت Session وابسته است.

آیا SSL برای امنیت وردپرس کافی است؟

خیر. SSL اطلاعات در حال انتقال را رمزنگاری می‌کند، اما افزونه آسیب‌پذیر، بدافزار، دسترسی مدیر یا پیکربندی اشتباه را برطرف نمی‌کند.

سایت وردپرسی امن سایتی نیست که تعداد زیادی تنظیم امنیتی روی آن فعال شده باشد. سایت امن، اجزای شناخته‌شده و به‌روز دارد، دسترسی‌ها در آن کنترل می‌شوند، تغییرات قابل ردیابی‌اند و برای بازیابی برنامه مشخصی وجود دارد.

هرچه درآمد، اطلاعات مشتری و اعتبار بیشتری به سایت وابسته باشد، فاصله میان بکاپ‌ها، سرعت نصب اصلاحیه‌ها و دقت مانیتورینگ نیز باید جدی‌تر شود.