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

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

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

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

در این راهنما، ۲۵ روش عملی برای بهینه‌سازی امنیت سایت وردپرسی را بررسی می‌کنم. بعضی اقدامات را می‌توانید همین امروز انجام دهید و بعضی دیگر به دسترسی هاست، CDN یا دانش فنی بیشتری نیاز دارند.

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

 

آیا وردپرس امن است؟

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

یک سایت وردپرسی از چند بخش تشکیل شده است:

• سیستم‌عامل و وب‌سرور

• نسخه PHP و دیتابیس

• هسته وردپرس

• قالب

• افزونه‌ها

• کاربران و سطح دسترسی آن‌ها

• فایل‌ها و اطلاعات سایت

• سیستم مدیر سایت

• سرویس‌های خارجی متصل به وردپرس

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

 

چک‌لیست فوری افزایش امنیت وردپرس

اگر فعلاً زمان اجرای تمام روش‌ها را ندارید، این موارد را در اولویت قرار دهید:

1. از فایل‌ها و دیتابیس بکاپ بگیرید.

2. وردپرس، افزونه‌ها و قالب را به‌روزرسانی کنید.

3. افزونه‌ها و قالب‌های اضافی را حذف کنید.

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

5. رمزهای تکراری را تغییر دهید.

6. کاربران مدیر را بررسی کنید.

7. محدودیت تلاش ورود و فایروال را فعال کنید.

8. بکاپ را خارج از هاست نگه دارید.

9. آسیب‌پذیری افزونه‌ها را مانیتور کنید.

10. مطمئن شوید بکاپ واقعاً بازیابی می‌شود.

 

۱. پیش از هر تغییر، بکاپ کامل بگیرید

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

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

• تمام فایل‌های وردپرس، قالب، افزونه‌ها و پوشه Uploads

• دیتابیس سایت

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

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

فاصله مناسب بکاپ‌گیری

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

• سایت شرکتی کم‌تغییر: روزانه یا چند بار در هفته

• سایت محتوایی فعال: روزانه

• فروشگاه اینترنتی: چند بار در روز

• سایت رزرو، عضویت یا آموزش: متناسب با تعداد تراکنش‌ها

• سایت‌های مهم: بکاپ افزایشی یا لحظه‌ای

فقط به پیام «Backup completed» اعتماد نکنید. هرچند وقت یک‌بار یکی از نسخه‌ها را روی محیط آزمایشی بازیابی کنید تا مطمئن شوید فایل‌ها و دیتابیس سالم هستند.

 

۲. از هاست امن و نسخه‌های پشتیبانی‌شده استفاده کنید

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

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

• نسخه‌های پشتیبانی‌شده PHP

• جداسازی حساب‌های میزبانی از یکدیگر

• فایروال سرور یا ModSecurity

• بکاپ خودکار خارج از سرور اصلی

• امکان اتصال با SFTP یا SSH

• اسکن بدافزار

• گزارش دسترسی‌ها و خطاهای سرور

• محافظت در برابر حملات DDoS

• محیط Staging

• امکان بازیابی اضطراری

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

صرفاً به عبارت «هاست مخصوص وردپرس» در صفحه فروش اعتماد نکنید. درباره محل نگهداری بکاپ‌ها، نوع فایروال، نسخه PHP، اسکن بدافزار و روش بازیابی اطلاعات سؤال کنید.

در راهنمای Hardening وردپرس در cPanel نیز کنترل‌هایی مثل محدودکردن دسترسی فایل‌ها، بستن Directory Browsing و محافظت از فایل‌های حساس بررسی شده‌اند.

 

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

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

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

• هسته وردپرس

• افزونه‌های فعال

• افزونه‌های غیرفعال

• قالب فعال

• قالب‌های نصب‌شده

• نسخه PHP

• کدها و افزونه‌های اختصاصی

• کتابخانه‌های جانبی پروژه

برای بیشتر سایت‌ها، آپدیت‌های امنیتی نباید هفته‌ها عقب بیفتند.

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

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

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

غیرفعال‌کردن یک افزونه قدیمی همیشه کافی نیست. فایل‌های آن همچنان روی سرور باقی می‌مانند و بعضی آسیب‌پذیری‌ها ممکن است بدون فعال‌بودن افزونه نیز قابل سوءاستفاده باشند.

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

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

• آخرین زمان به‌روزرسانی

• سازگاری با نسخه فعلی وردپرس

• سازگاری با نسخه PHP

• تعداد مشکلات حل‌نشده

• سابقه امنیتی توسعه‌دهنده

• کیفیت پشتیبانی

• امکانات اضافه و غیرضروری

• منبع دریافت فایل

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

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

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

حتی اگر فایل نال‌شده در ابتدا سالم به‌نظر برسد، معمولاً این مشکلات را دارد:

• آپدیت معتبر دریافت نمی‌کند.

• امکان بررسی اصالت فایل وجود ندارد.

• پشتیبانی رسمی ندارد.

• ممکن است به سرورهای ناشناس متصل شود.

• احتمال وجود کد مبهم یا رمزگذاری‌شده بیشتر است.

• در صورت ایجاد مشکل، مسئول مشخصی ندارد.

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

پولی‌بودن یک افزونه نیز تضمین امنیت نیست. طبق گزارش Patchstack، محصولات پریمیوم به‌دلیل دسترسی کمتر پژوهشگران به کد آن‌ها، ممکن است کمتر بررسی شوند. در سال ۲۰۲۵ نزدیک به دو هزار آسیب‌پذیری معتبر در محصولات پریمیوم یا فریمیوم گزارش شده است.

۶. آسیب‌پذیری افزونه‌ها را به‌صورت مداوم مانیتور کنید

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

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

• افزونه‌ها و قالب‌های نصب‌شده را شناسایی کند.

• نسخه آن‌ها را با دیتابیس آسیب‌پذیری مقایسه کند.

• شدت آسیب‌پذیری را مشخص کند.

• هنگام انتشار حفره جدید هشدار بدهد.

• وجود نسخه اصلاح‌شده را اعلام کند.

• در صورت نبود اصلاحیه، راهکار موقت پیشنهاد دهد.

برای بررسی دستی می‌توانید از دیتابیس آسیب‌پذیری WPScan استفاده کنید. برای سایت‌های مهم‌تر، بهتر است هشدارها خودکار باشند.

اگر افزونه‌ای آسیب‌پذیر است و اصلاحیه‌ای ندارد، سه انتخاب اصلی دارید:

1. افزونه را موقتاً غیرفعال کنید.

2. آن را با گزینه دیگری جایگزین کنید.

3. از Virtual Patching یا قاعده محافظتی موقت استفاده کنید.

Virtual Patching بدون تغییر فایل افزونه، الگوی سوءاستفاده شناخته‌شده را در فایروال مسدود می‌کند تا فرصت نصب نسخه سالم یا جایگزینی افزونه فراهم شود.

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

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

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

• ایمیل اصلی

• هاست

• کنترل‌پنل

• دیتابیس

• CDN

• سرویس بکاپ

• شبکه‌های اجتماعی

• سایت‌های دیگر

اگر یک سرویس دچار نشت اطلاعات شود، مهاجم معمولاً همان ایمیل و رمز را روی سرویس‌های دیگر امتحان می‌کند. به این حمله Credential Stuffing گفته می‌شود.

از یک Password Manager معتبر استفاده کنید تا برای هر حساب رمز جداگانه بسازید. لازم نیست تمام رمزها را حفظ کنید؛ فقط باید رمز اصلی Password Manager را به‌خوبی محافظت کنید.

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

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

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

• مدیران وردپرس

• مدیر فروشگاه

• حساب هاست

• ایمیل اصلی سایت

• حساب CDN

• فضای بکاپ

• سرویس‌های مالی متصل به سایت

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

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

کدهای بازیابی را در جایی امن و خارج از همان گوشی ذخیره کنید. بهتر است برای مدیران مهم، حداقل دو روش بازیابی مطمئن وجود داشته باشد.

۹. تعداد تلاش‌های ورود را محدود کنید

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

برای کنترل حملات Brute Force از ترکیب این روش‌ها استفاده کنید:

• Rate Limiting

• مسدودسازی موقت رفتارهای مشکوک

• CAPTCHA یا Cloudflare Turnstile

• 2FA

• رمز منحصربه‌فرد

• فایروال

• ثبت لاگ ورودها

• محدودکردن درخواست‌های /wp-login.php

قفل‌کردن دائمی IP بعد از چند تلاش ناموفق همیشه انتخاب خوبی نیست. مهاجمان از IPهای متعدد استفاده می‌کنند و ممکن است کاربران واقعی پشت اینترنت اشتراکی نیز مسدود شوند.

راهنمای رسمی مقابله با حملات Brute Force وردپرس استفاده از 2FA، Passkey، Rate Limiting و WAF لبه شبکه را به‌عنوان دفاع‌های اصلی معرفی می‌کند.

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

۱۰. حساب‌های مدیر اضافی را حذف کنید

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

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

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

• تعداد کاربران مدیر

• حساب‌های مربوط به همکاران قبلی

• کاربران آزمایشی

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

• مدیرانی که می‌توانند نقش محدودتری داشته باشند

• حساب‌هایی با ایمیل ناشناس

• کاربران ساخته‌شده بدون اطلاع شما

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

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

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

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

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

• نشست‌های فعال

• دستگاه‌های قدیمی

• ورودهای ناشناس

• Application Passwordها

• اتصال اپلیکیشن موبایل

• ابزارهای انتشار محتوا

• اسکریپت‌ها و سرویس‌های خارجی

Application Password یک رمز جداگانه برای اتصال ابزارها به REST API یا XML-RPC است. مزیت آن این است که می‌توانید دسترسی یک اتصال را بدون تغییر رمز اصلی کاربر لغو کنید.

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

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

۱۲. ثبت‌نام کاربران و نقش پیش‌فرض را کنترل کنید

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

مسیر این تنظیم در وردپرس:

تنظیمات ← عمومی ← هر کسی می‌تواند نام‌نویسی کند

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

برای فرم ثبت‌نام این کنترل‌ها را در نظر بگیرید:

• CAPTCHA یا Turnstile

• تأیید ایمیل

• محدودیت نرخ درخواست

• جلوگیری از ایمیل‌های موقت

• تأیید دستی در سایت‌های حساس

• بررسی نقش پیش‌فرض

• حذف کاربران اسپم

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

۱۳. HTTPS و SFTP را اجباری کنید

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

بعد از نصب SSL این موارد را بررسی کنید:

• همه آدرس‌های HTTP به HTTPS منتقل شوند.

• سایت Mixed Content نداشته باشد.

• آدرس وردپرس و سایت روی HTTPS تنظیم شده باشد.

• پنل مدیریت فقط با HTTPS باز شود.

• تصاویر، فونت‌ها و فایل‌های JavaScript از HTTPS بارگذاری شوند.

• لینک‌های داخلی قدیمی اصلاح شوند.

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

مستندات رسمی وردپرس صراحتاً استفاده از SFTP را به‌جای FTP معمولی توصیه می‌کند.

۱۴. سیستم و مرورگر مدیر سایت را امن نگه دارید

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

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

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

• مرورگر را به‌روز کنید.

• افزونه‌های مرورگر ناشناس را حذف کنید.

• از نرم‌افزارهای کرک‌شده دوری کنید.

• قفل صفحه و رمز دستگاه را فعال کنید.

• فایل‌های ناشناس را اجرا نکنید.

• روی دستگاه عمومی وارد پیشخوان نشوید.

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

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

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

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

در بسیاری از هاست‌ها این مقادیر نقطه شروع رایجی هستند:

• پوشه‌ها: 755

• فایل‌ها: 644

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

برای فایل wp-config.php ممکن است مقادیر محدودتری مانند 400، 440، 600 یا 640 مناسب باشند. قبل از تغییر این فایل با پشتیبانی هاست هماهنگ کنید.

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

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

۱۶. ویرایشگر فایل قالب و افزونه را غیرفعال کنید

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

برای غیرفعال‌کردن ویرایشگر، این خط را پیش از عبارت پایانی فایل wp-config.php قرار دهید:

define( 'DISALLOW_FILE_EDIT', true );

این تنظیم جلوی تمام روش‌های اجرای کد را نمی‌گیرد، اما یکی از مسیرهای ساده را حذف می‌کند.

در سایت‌های مدیریت‌شده که نصب و آپدیت افزونه فقط از طریق فرایند استقرار انجام می‌شود، می‌توان نصب و به‌روزرسانی از پیشخوان را نیز محدود کرد:

define( 'DISALLOW_FILE_MODS', true );

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

۱۷. فایل wp-config.php و حالت Debug را ایمن کنید

فایل wp-config.php شامل اطلاعات اتصال دیتابیس، کلیدهای امنیتی و تنظیمات اصلی وردپرس است.

در سرور Apache می‌توانید دسترسی مستقیم به آن را از طریق .htaccess محدود کنید:

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

این کد برای Apache 2.4 نوشته شده است. روی Nginx یا LiteSpeed ممکن است روش تنظیم متفاوت باشد.

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

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

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

۱۸. اجرای PHP را در پوشه Uploads مسدود کنید

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

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

در سرور Apache می‌توان فایل .htaccess جداگانه‌ای داخل پوشه Uploads ساخت و اجرای PHP را بست:

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

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

در Nginx باید قانون معادل در تنظیمات سرور اعمال شود. این کار را از طریق پشتیبانی هاست یا مدیر سرور انجام دهید.

پوشه‌های Cache و Backup نیز نباید محل اجرای فایل PHP باشند، مگر اینکه ابزار مورد استفاده واقعاً به آن نیاز داشته باشد.

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

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

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

Options -Indexes

همچنین بررسی کنید این فایل‌ها از طریق وب در دسترس نباشند:

• فایل‌های بکاپ با پسوند ZIP، SQL یا TAR

• فایل‌های لاگ

• نسخه‌های قدیمی wp-config.php

• فایل‌های .env

• خروجی Export دیتابیس

• فایل‌های تست

• نسخه‌های موقت با پسوند .bak یا .old

• فایل‌های نصب و آرشیو افزونه‌ها

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

۲۰. امنیت دیتابیس را جدی بگیرید

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

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

• طولانی و تصادفی باشد.

• فقط در wp-config.php ذخیره شود.

• در فایل‌های دیگر تکرار نشود.

• بین چند سایت مشترک نباشد.

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

تغییر پیشوند جداول از wp_ دفاع اصلی در برابر SQL Injection نیست. اگر افزونه‌ای آسیب‌پذیری SQL Injection داشته باشد، راه‌حل واقعی اصلاح یا حذف همان افزونه، اعتبارسنجی ورودی و استفاده از کوئری‌های امن است.

برای پاک‌کردن جداول یا متادیتای باقی‌مانده نیز بدون بررسی چیزی را حذف نکنید. در راهنمای کار با افزونه Advanced Database Cleaner روش بررسی جداول، داده‌های یتیم و پاک‌سازی کنترل‌شده دیتابیس را توضیح داده‌ام.

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

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

هدرهای قابل بررسی عبارت‌اند از:

• Content-Security-Policy

• X-Content-Type-Options

• Referrer-Policy

• Permissions-Policy

• Strict-Transport-Security

• frame-ancestors در CSP

از افزودن یک Content Security Policy آماده و بسیار سخت‌گیرانه بدون تست خودداری کنید. وردپرس، المنتور، درگاه‌های پرداخت، چت آنلاین، فونت‌ها و اسکریپت‌های خارجی ممکن است با CSP اشتباه از کار بیفتند.

بهتر است CSP ابتدا در حالت Report-Only اجرا شود و پس از بررسی گزارش‌ها به حالت اجرایی برود.

HSTS را نیز زمانی فعال کنید که مطمئن هستید تمام سایت و زیردامنه‌های موردنظر از HTTPS استفاده می‌کنند؛ چون تنظیم اشتباه آن می‌تواند دسترسی کاربران را مختل کند.

۲۲. از فایروال برنامه‌های تحت وب استفاده کنید

فایروال برنامه‌های تحت وب یا WAF درخواست‌های ورودی را بررسی می‌کند و بخشی از ترافیک مخرب را قبل از رسیدن به قسمت‌های حساس سایت مسدود می‌کند.

WAF می‌تواند در چند سطح فعال باشد:

• CDN یا شبکه لبه

• سرور

• سرویس هاست

• افزونه وردپرس

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

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

• Rate Limit روی صفحه ورود

• محدودیت درخواست به XML-RPC

• مقابله با ربات‌ها

• مسدودسازی الگوهای حمله شناخته‌شده

• محدودیت درخواست‌های غیرعادی

• محافظت از مسیرهای حساس

• Challenge برای ترافیک مشکوک

وجود Cloudflare یا یک CDN به معنی امنیت کامل نیست. حمله‌ای که از طریق حساب معتبر، افزونه آسیب‌پذیر یا Broken Access Control انجام شود ممکن است شبیه ترافیک معمولی باشد.

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

۲۳. XML-RPC، Pingback و REST API را بدون بررسی رها نکنید

فایل xmlrpc.php برای بعضی اپلیکیشن‌ها، Jetpack، انتشار از راه دور و اتصال سرویس‌های خارجی استفاده می‌شود. همین مسیر ممکن است برای Brute Force یا سوءاستفاده از Pingback نیز هدف قرار بگیرد.

اگر هیچ سرویس یا افزونه‌ای به XML-RPC نیاز ندارد، می‌توانید آن را غیرفعال کنید. اگر نیاز دارید، بهتر است:

• Rate Limit اعمال کنید.

• درخواست‌های مشکوک را در WAF کنترل کنید.

• Pingback را غیرفعال کنید.

• دسترسی را فقط برای سرویس‌های موردنیاز باز بگذارید.

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

به‌جای بستن کامل API:

• Endpointهای اختصاصی را با permission_callback محافظت کنید.

• اطلاعات حساس را در پاسخ عمومی قرار ندهید.

• دسترسی‌های احراز هویت‌شده را بررسی کنید.

• Application Passwordهای قدیمی را لغو کنید.

• افزونه‌هایی که Endpoint ناامن می‌سازند حذف یا اصلاح کنید.

پنهان‌کردن نام کاربران در REST API ممکن است مقدار کمی اطلاعات را محدود کند، اما جایگزین رمز قوی و 2FA نیست؛ نام نویسنده از مسیرهای دیگری مثل آرشیو نویسنده نیز قابل شناسایی است.

۲۴. لاگ فعالیت، تغییر فایل‌ها، Cron و بدافزار را مانیتور کنید

فایروال قرار نیست تمام حملات را متوقف کند. باید بتوانید بعد از یک اتفاق بفهمید چه چیزی تغییر کرده است.

لاگ فعالیت بهتر است این رویدادها را ثبت کند:

• ورود موفق و ناموفق

• ساخت یا حذف کاربر

• تغییر نقش کاربران

• نصب، حذف یا فعال‌سازی افزونه

• تغییر تنظیمات اصلی

• ویرایش فایل‌ها

• تغییر ایمیل مدیر

• ساخت Application Password

• تغییر درگاه پرداخت

• تغییر تنظیمات ووکامرس

File Integrity Monitoring نیز فایل‌های هسته، قالب و افزونه را با نسخه سالم مقایسه می‌کند. تغییر فایل اصلی وردپرس یا اضافه‌شدن PHP ناشناس باید هشدار ایجاد کند.

WP-Cron را نیز دوره‌ای بررسی کنید. بعضی بدافزارها یک وظیفه زمان‌بندی‌شده می‌سازند تا بعد از پاک‌سازی فایل‌ها، دوباره آلودگی را برگردانند.

موارد مشکوک شامل این‌هاست:

• Cron با نام ناشناس

• اجرای بسیار پرتکرار

• Callback مربوط به افزونه حذف‌شده

• درخواست به دامنه ناشناس

• ساخت فایل در پوشه Uploads

• کد مبهم و Base64 طولانی

• کاربر مدیر بدون سابقه مشخص

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

۲۵. برای زمان هک‌شدن سایت برنامه مشخص داشته باشید

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

اگر سایت هک شد، این مراحل را انجام دهید:

1. دسترسی‌های مشکوک را محدود کنید.

2. سایت را بدون برنامه کامل حذف نکنید.

3. از وضعیت فعلی یک نسخه جداگانه برای بررسی نگه دارید.

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

5. کاربران مدیر و Application Passwordها را بررسی کنید.

6. مسیر اولیه نفوذ را پیدا کنید.

7. افزونه یا قالب آسیب‌پذیر را حذف یا اصلاح کنید.

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

9. دیتابیس، Cron Jobها و پوشه Uploads را بررسی کنید.

10. رمز وردپرس، هاست، دیتابیس و ایمیل را تغییر دهید.

11. در صورت احتمال سرقت نشست‌ها، Salt Keyهای وردپرس را تغییر دهید.

12. بکاپ سالم را فقط بعد از بستن مسیر نفوذ بازیابی کنید.

13. سایت را دوباره اسکن و مانیتور کنید.

تغییر Salt Keyها کاربران را از حساب خارج می‌کند و کوکی‌های فعلی را بی‌اعتبار می‌سازد. لازم نیست این کلیدها را بی‌دلیل و طبق برنامه ثابت تغییر دهید؛ این کار بیشتر هنگام نفوذ، سرقت احتمالی کوکی یا نیاز به خروج اجباری همه کاربران کاربرد دارد.

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

راهنمای امنیت وردپرس Sucuri نیز امنیت سایت را در سه بخش پیشگیری، شناسایی و واکنش بررسی می‌کند.

---

روش‌هایی که بیش از حد بزرگ شده‌اند

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

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

تغییر /wp-login.php ممکن است تعداد ربات‌ها و لاگ‌های ناموفق را کاهش دهد، اما یک کنترل امنیتی قدرتمند نیست. آدرس جدید در بسیاری از سایت‌ها از مسیرهای دیگر قابل پیدا کردن است.

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

• 2FA

• Rate Limiting

• WAF

• رمز منحصربه‌فرد

• مانیتورینگ ورود

راهنمای امنیت Wordfence نیز تغییر آدرس ورود را جایگزین کنترل‌های واقعی امنیتی نمی‌داند.

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

تغییر wp_ ممکن است بعضی اسکریپت‌های بسیار ابتدایی را مختل کند، اما SQL Injection را برطرف نمی‌کند.

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

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

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

آپدیت‌کردن سایت بسیار مهم‌تر از مخفی‌کردن شماره نسخه است.

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

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

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

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

نصب هم‌زمان Wordfence، AIOS، Solid Security و ابزارهای مشابه معمولاً لازم نیست.

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

• صفحه ورود

• .htaccess

• REST API

• XML-RPC

• فایروال

• سطح دسترسی فایل‌ها

• CAPTCHA

• لاگ‌ها

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

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

• یک ابزار اصلی برای فایروال و ورود

• یک سیستم بکاپ مستقل

• یک ابزار پایش آسیب‌پذیری

• یک سیستم مانیتورینگ سایت

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

 

نکات مهم امنیت ووکامرس

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

برای ووکامرس این اقدامات را جدی‌تر بگیرید:

• بکاپ دیتابیس چند بار در روز

• 2FA برای مدیر و مدیر فروشگاه

• حساب جداگانه برای پشتیبان و حسابدار

• ثبت تغییرات تنظیمات درگاه

• محدودکردن دسترسی مالی

• بررسی مدیران جدید

• محافظت از صفحه ورود و حساب مشتری

• کنترل سفارش‌ها و پرداخت‌های غیرعادی

• استفاده از درگاه رسمی

• آزمایش خرید بعد از آپدیت

• بررسی Webhookهای ووکامرس

• حذف API Keyهای قدیمی

• محدودکردن دسترسی افزونه‌های اتصال به انبار و CRM

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

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

1. ثبت‌نام

2. ورود

3. افزودن محصول به سبد

4. اعمال کد تخفیف

5. انتخاب روش ارسال

6. انتقال به درگاه

7. برگشت از پرداخت

8. ثبت سفارش

9. ارسال ایمیل‌ها

10. تغییر وضعیت سفارش

 

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

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

بررسی روزانه

• هشدارهای آسیب‌پذیری

• موفق‌بودن بکاپ

• در دسترس‌بودن سایت

• ورودهای مشکوک

• تغییرات مهم فروشگاه

• هشدارهای فایروال

بررسی هفتگی

• آپدیت وردپرس، افزونه و قالب

• کاربران مدیر

• تغییر فایل‌ها

• اسکن بدافزار

• خطاهای سرور

• افزونه‌های بلااستفاده

• Cron Jobهای ناشناس

بررسی ماهانه

• آزمایش بازیابی بکاپ

• بازبینی سطح دسترسی کاربران

• حذف حساب‌های قدیمی

• بررسی Application Passwordها

• بررسی API Keyها و Webhookها

• کنترل نسخه PHP

• بررسی افزونه‌های رهاشده

بررسی دوره‌ای

• تست کامل فرایند ورود

• بازبینی تنظیمات WAF

• بررسی امنیت سیستم مدیران

• کنترل دسترسی همکاران قبلی

• تست خرید ووکامرس

• تمرین فرایند بازیابی سایت

• بررسی سرعت و مصرف منابع افزونه امنیتی

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

 

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

آیا وردپرس به‌راحتی هک می‌شود؟

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

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

آیا نصب افزونه امنیتی کافی است؟

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

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

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

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

• نوع هاست

• منابع سرور

• نوع سایت

• میزان ترافیک

• نیاز به WAF

• نیاز به اسکن بدافزار

• نیاز به پایش آسیب‌پذیری

• بودجه

• سطح دانش مدیر

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

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

آیا باید XML-RPC را ببندیم؟

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

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

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

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

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

فاصله بکاپ به میزان تغییر سایت بستگی دارد. سؤال اصلی این است: «در صورت بروز مشکل، از دست‌رفتن چند ساعت یا چند روز اطلاعات برای من قابل قبول است؟»

برای فروشگاه فعال، بکاپ هفتگی معمولاً کافی نیست.

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

نشانه‌های احتمالی عبارت‌اند از:

• کاربر مدیر ناشناس

• تغییر فایل‌ها

• ریدایرکت کاربران

• نمایش تبلیغات ناخواسته

• صفحات اسپم در گوگل

• تغییر تنظیمات درگاه

• ارسال ایمیل انبوه

• کندی غیرعادی

• فایل PHP ناشناس

• Cron Job مشکوک

• تغییر مکرر .htaccess

• هشدار مرورگر یا سرچ کنسول

بعضی آلودگی‌ها نشانه ظاهری ندارند؛ به همین دلیل لاگ، اسکن و مانیتورینگ ضروری‌اند.

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

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

 

جمع‌بندی

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

• وردپرس و افزونه‌ها به‌روز باشند.

• افزونه‌های اضافی و نال‌شده حذف شوند.

• مدیران از 2FA استفاده کنند.

• دسترسی کاربران محدود باشد.

• فایل‌ها و دیتابیس درست محافظت شوند.

• WAF و Rate Limiting فعال باشند.

• آسیب‌پذیری‌ها سریع شناسایی شوند.

• بکاپ خارج از هاست و قابل بازیابی باشد.

• لاگ‌ها و تغییر فایل‌ها بررسی شوند.

• برای زمان نفوذ برنامه مشخصی وجود داشته باشد.

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

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