امنیت ساختار پوشه‌های وردپرس: غیرفعال کردن دسترسی به پوشه "wp-includes"

برای افزایش امنیت ساختار پوشه‌های وردپرس، بهترین روش برای محدود کردن دسترسی مستقیم به پوشه «wp-includes» این است که به جای مسدود کردن کامل پوشه، اجرای فایل‌های PHP در این پوشه و نمایش فهرست محتویات آن را غیرفعال کنیم. زیرا پوشه wp-includes شامل فایل‌های ضروری جاوااسکریپت، CSS و برخی فایل‌های استاتیک است که هسته وردپرس برای عملکرد صحیح به آنها نیاز دارد؛ بستن کامل این پوشه می‌تواند به طراحی سایت، ویرایشگر یا عملکرد افزونه‌ها آسیب بزند. رویکرد صحیح این است که اگر از آپاچی استفاده می‌کنید، با قوانین .htaccess و اگر از Nginx بهره می‌برید، با قوانین location در تنظیمات سرور، اجرای مستقیم PHP را مسدود کنید و سپس با پاسخ‌های 403/404 و تست‌های دقیق صفحات، صحت عملکرد سایت را بررسی نمایید.

یکی از اشتباهات رایج در امنیت وردپرس، اکتفا به رمز عبور قوی یا افزونه‌های امنیتی است. در حالی که مهاجمان معمولاً پوشه‌های حاوی فایل‌های هسته، افزونه‌های قدیمی، مجوزهای نادرست فایل‌ها و نمایش دایرکتوری‌های باز را اسکن می‌کنند. پوشه wp-includes هم یکی از اهداف این اسکن‌هاست. در این راهنما، با قدم‌هایی کاربردی و قابل اجرا در محیط‌های میزبانی واقعی، نحوه محدودسازی دسترسی به wp-includes، قوانین قابل توجه که ممکن است سایت را دچار مشکل کنند، نمونه‌های پیکربندی برای آپاچی و Nginx، روش‌های تست و فهرست چک‌لیست نگهداری را خواهید یافت. همچنین برای اجرای وردپرس روی زیرساختی امن‌تر، می‌توانید گزینه‌های هاستینگ وردپرس و برای محافظت لایه‌ای کلی‌تر، گواهی‌نامه SSL را بررسی کنید.

پوشه wp-includes چیست و چرا باید محافظت شود؟

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

بازدیدکننده معمولی نیازی ندارد آدرس site.com/wp-includes/ را باز کند. اما ممکن است در کد منبع صفحه، برخی از دارایی‌های استاتیک در زیرپوشه wp-includes مشاهده شود؛ برای مثال فایل‌های اسکریپت پیش‌فرض وردپرس، اسکریپت‌های ایموجی یا اجزای ویرایشگر از این پوشه بارگذاری می‌شوند. بنابراین در هنگام اعمال تدابیر امنیتی، هدف‌گذاری باید دقیق باشد: اجرای فایل‌های PHP را مسدود کنیم بدون اینکه دسترسی به فایل‌های استاتیک قطع شود.

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

غیرفعال کردن دسترسی به wp-includes چه مزایایی دارد؟

مسدود کردن اجرای مستقیم PHP در پوشه wp-includes به تنهایی جلوی همه حملات را نمی‌گیرد اما به طور قابل توجهی سطح حمله را کاهش می‌دهد. به ویژه سایت‌هایی که به بدافزار آلوده شده‌اند، مهاجمان تلاش می‌کنند فایل‌های مخرب PHP را در دایرکتوری‌های در دسترس آپلود یا فایل‌های موجود را اجرا کنند. ممنوع کردن اجرای مستقیم PHP در این پوشه یک سد امنیتی اضافی ایجاد می‌کند.

این اقدام مزایای زیر را به همراه دارد:

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

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

اشتباهات رایج هنگام غیرفعال کردن wp-includes

مسدود کردن کامل پوشه

یکی از رایج‌ترین اشتباهات، مسدود کردن همه درخواست‌های HTTP به پوشه wp-includes با کد 403 است. این روش ابتدا منطقی به نظر می‌رسد اما از آنجا که وردپرس برخی فایل‌های استاتیک را از این پوشه بارگذاری می‌کند، مشکلات غیرمنتظره‌ای ایجاد می‌کند؛ مثلاً ویرایشگر بلوکی باز نمی‌شود، برخی فایل‌های جاوااسکریپت لود نمی‌شوند یا در ظاهر سایت تغییرات کوچک ولی حیاتی رخ می‌دهد.

اعمال قانون بدون تست در محیط زنده

یک اشتباه دیگر، اعمال مستقیم قوانین در فایل‌های .htaccess یا پیکربندی Nginx بدون تست است. حتی یک اشتباه ساده در سینتکس ممکن است باعث خطای 500 شود. به خصوص در سایت‌های پر ترافیک، بهتر است ابتدا نسخه پشتیبان بگیرید، در محیط staging تست کنید و سپس به صورت کنترل‌شده در محیط اصلی اجرا نمایید. اگر از زیرساخت Hostragons استفاده می‌کنید، می‌توانید از امکانات پشتیبان‌گیری هاستینگ وب برای بکاپ‌گیری بهره ببرید.

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

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

چک‌لیست پیش از اجرای محدودسازی دسترسی به wp-includes

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

• نسخه پشتیبان از تنظیمات فعلی .htaccess یا پیکربندی Nginx تهیه کنید.
• هسته وردپرس، قالب‌ها و افزونه‌ها را به‌روزرسانی نمایید.
• اطمینان حاصل کنید که نسخه PHP شما نسخه‌ای پشتیبانی‌شده و امن است.
• مجوزهای فایل را بررسی کنید: پوشه‌ها معمولاً 755 و فایل‌ها 644 باشند.
• مجوزهای نوشتن روی فایل‌های حیاتی مانند wp-config.php و .htaccess را محدود کنید.
• اگر از کش، CDN یا افزونه امنیتی استفاده می‌کنید، پس از تغییرات کش را پاک کنید.
• برای تست، فهرستی از صفحات مهم مانند پنل مدیریت، صفحه اصلی، صفحه نوشته، فرم تماس و صفحه پرداخت تهیه کنید.

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

غیرفعال کردن اجرای PHP در wp-includes با .htaccess در سرور آپاچی

برای هاست‌های اشتراکی مبتنی بر آپاچی، رایج‌ترین روش استفاده از فایل .htaccess است. با اضافه کردن قوانین مناسب به این فایل در ریشه وردپرس، می‌توان اجرای فایل‌های PHP در پوشه wp-includes را محدود کرد. قبل از شروع، نسخه‌ای از فایل را دانلود یا در مدیریت هاست نسخه پشتیبان تهیه کنید.

قانون پیشنهادی .htaccess

روش زیر تمرکز بر مسدودسازی اجرای مستقیم PHP در این پوشه دارد و اجازه اجرای فایل‌های استاتیک را می‌دهد:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

منطق این قانون ساده است: اگر URL با wp-includes شروع شده و با پسوند .php پایان یابد، درخواست مسدود می‌شود. بنابراین فایل‌های PHP داخل این پوشه از مرورگر قابل فراخوانی نیستند. در مقابل، دسترسی به فایل‌هایی مانند .js، .css، .png و .svg همچنان برقرار است که تعادل امنیتی بهتری برای ظاهر و پنل وردپرس ایجاد می‌کند.

غیرفعال کردن فهرست دایرکتوری

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

Options -Indexes

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

تست پس از اعمال تغییرات

بعد از افزودن قوانین، موارد زیر را تست کنید:

• آدرس siteadresiniz.com/wp-includes/ را باز کنید؛ نباید فهرست فایل‌ها نمایش داده شود.
• فایل PHP شناخته‌شده‌ای در wp-includes را مستقیماً فراخوانی کنید؛ باید پاسخ 403 یا 404 دریافت کنید.
• صفحه اصلی، نوشته‌ها و پنل مدیریت را بررسی کنید.
• در ابزارهای توسعه مرورگر در تب‌های Console و Network به دنبال خطاهای 403 یا 404 بگردید.
• اگر کش یا CDN فعال دارید، کش را پاک کنید.

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

بستن اجرای PHP در wp-includes در سرور Nginx

در سرورهای Nginx، فایل .htaccess کاربرد ندارد. باید قانون مسدودسازی را در فایل پیکربندی سایت (معمولاً داخل بلوک server) اضافه کنید. دسترسی SSH و امکان ویرایش فایل‌های پیکربندی لازم است و اگر در این زمینه اطمینان ندارید، بهتر است از تیم پشتیبانی هاست کمک بگیرید.

قانون location پیشنهادی برای Nginx

قانون پایه به شکل زیر است:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

این قانون درخواست‌های اجرای فایل‌های PHP در پوشه wp-includes را مسدود می‌کند. پس از ویرایش فایل پیکربندی، باید آن را تست کنید:

nginx -t

اگر تست موفق بود، سرویس Nginx را مجدداً بارگذاری کنید:

systemctl reload nginx

دستور reload نسبت به restart کنترل‌شده‌تر است و اتصالات فعال را قطع نمی‌کند. البته در سایت‌های حساس بهتر است تغییرات در ساعات کم ترافیک انجام شود.

نکات مهم در استفاده از Nginx

• اطمینان یابید قانون را در بلوک server مربوط به سایت درست اضافه کرده‌اید؛ ممکن است چند سایت روی یک سرور باشد.
• اگر از CDN یا پروکسی معکوس استفاده می‌کنید، پس از پاک‌سازی کش CDN تست‌ها را انجام دهید.
• بررسی کنید PHP-FPM فقط فایل‌های لازم را پردازش می‌کند.
• گزارش‌های access.log و error.log را بررسی کنید؛ خطاهای ناشی از قوانین نادرست سریع مشخص می‌شوند.

سلسله‌مراتب قوانین location در Nginx می‌تواند منجر به نتایج غیرمنتظره شود؛ پس مطمئن شوید با قوانین مرتبط با پیوندهای وردپرس و پردازش PHP تداخل ندارد.

مقایسه روش‌ها

جدول زیر روش‌های اصلی محدودسازی دسترسی به پوشه wp-includes را خلاصه می‌کند:

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

تنظیمات مجوز فایل‌ها و مالکیت

محدودسازی دسترسی به wp-includes اگر مجوزهای فایل صحیح نباشند ناقص می‌ماند. معمولاً مجوزهای 755 برای پوشه‌ها و 644 برای فایل‌ها پذیرفته شده است. این مجوزها به وب‌سرور اجازه خواندن می‌دهند و از مجوز نوشتن اضافی جلوگیری می‌کنند. ممکن است در محیط‌های میزبانی خاص، ساختار کاربران و گروه‌ها متفاوت باشد، پس توصیه‌های پنل هاست را هم در نظر بگیرید.

استفاده از مجوز 777 خطرناک است چون هر کسی اجازه نوشتن دارد و امکان آپلود فایل مخرب را افزایش می‌دهد. حتی در پوشه‌های قابل نوشتن مثل wp-content/uploads هم باید اجرای PHP محدود شود. پوشه wp-includes معمولاً نباید توسط کاربر قابل نوشتن باشد مگر در زمان به‌روزرسانی خودکار وردپرس.

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

• پوشه wp-includes: معمولاً 755
• فایل‌های PHP داخل wp-includes: معمولاً 644
• فایل wp-config.php: بهتر است 600 یا مجوز محدودتر متناسب با هاست
• فایل .htaccess: معمولاً 644، بدون مجوز نوشتن اضافی پس از ویرایش

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

آیا افزونه‌های امنیتی این کار را انجام می‌دهند؟

افزونه‌هایی مانند Wordfence و iThemes Security ممکن است برخی قاعده‌های سخت‌افزاری را به صورت خودکار پیشنهاد دهند. این افزونه‌ها در محافظت در برابر حملات brute force، رصد تغییر فایل، اسکن بدافزار و امنیت ورود مفید هستند. اما باید بررسی کنید که آیا برای محدودسازی دسترسی به wp-includes کاری انجام می‌دهند یا خیر.

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

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

• آیا افزونه قانون .htaccess یا Nginx اضافه کرده است؟
• از تداخل قوانین مشابه جلوگیری کنید.
• بعد از به‌روزرسانی افزونه، تنظیمات امنیتی تغییر نکرده باشد.
• برای ارزیابی عملکرد، مصرف کش و منابع سرور را مانیتور کنید.

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

تست محافظت wp-includes: سناریوی عملی

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

• ۱. صفحه اصلی را در یک پنجره ناشناس مرورگر باز کنید و به دنبال مشکلات ظاهری باشید.
• ۲. یک نوشته، صفحه دسته‌بندی و صفحه نتایج جستجو را بازدید کنید.
• ۳. وارد پنل مدیریت وردپرس شوید و ویرایشگر بلوکی و کتابخانه رسانه را باز کنید.
• ۴. در ابزار توسعه مرورگر، قسمت Console را برای خطا بررسی کنید.
• ۵. در تب Network اطمینان حاصل کنید فایل‌های استاتیک داخل wp-includes بدون مشکل بارگذاری می‌شوند.
• ۶. آدرس مستقیم یک فایل PHP داخل wp-includes را باز کنید و باید پاسخ 403 یا 404 دریافت نمایید.
• ۷. لاگ‌های خطای سرور را برای خطاهای جدید یا تکراری بررسی کنید.

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

اقدامات امنیتی تکمیلی در ساختار پوشه‌های وردپرس

محافظت از wp-includes نقطه شروع خوبی است اما امنیت وردپرس باید جامع باشد. اقدامات زیر می‌توانند سطح حمله را بیشتر کاهش دهند:

• به جای مخفی کردن نسخه وردپرس، هسته را همیشه به‌روز نگه دارید.
• قالب‌ها و افزونه‌های غیرضروری را حذف کنید.
• نام کاربری مدیر را غیرقابل حدس انتخاب کنید.
• احراز هویت دو مرحله‌ای فعال کنید.
• اگر از XML-RPC استفاده نمی‌کنید، دسترسی به آن را محدود نمایید.
• برای wp-login.php محدودیت نرخ درخواست یا تأیید هویت اضافه کنید.
• پشتیبان‌گیری روزانه خودکار با تست بازگردانی داشته باشید.
• کل سایت را با HTTPS اجرا کنید؛ بدون SSL داده‌های ورود در خطر است.

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

چه زمانی باید از متخصص کمک بگیرید؟

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

• اگر روی سرور چند وردپرس میزبانی می‌کنید.
• اگر Nginx، Varnish، CDN و WAF به صورت همزمان فعال است.
• اگر پس از تغییرات خطاهای 403، 404 یا 500 افزایش یافته است.
• اگر سایت قبلاً به بدافزار آلوده شده باشد.
• اگر سایت سیستم پرداخت، عضویت یا پردازش داده‌های شخصی دارد.

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

جمع‌بندی

در امنیت ساختار پوشه‌های وردپرس، غیرفعال کردن دسترسی به پوشه wp-includes به شکل صحیح به معنی مسدود کردن کل پوشه نیست بلکه محدود کردن دسترسی مستقیم به فایل‌های PHP و غیرفعال کردن نمایش فهرست محتویات است. این کار با قوانین .htaccess در آپاچی و location در Nginx به سادگی قابل انجام است. حتماً قبل از هر تغییر نسخه پشتیبان بگیرید و پس از آن تست‌های پنل مدیریت و ظاهر سایت را انجام دهید.

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

پرسش‌های پرتکرار

آیا مسدود کردن کامل پوشه wp-includes امن است؟

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

اگر بعد از افزودن قانون .htaccess خطای ۵۰۰ گرفتم چه کنم؟

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

آیا .htaccess در سرور Nginx کار می‌کند؟

خیر. .htaccess فقط در محیط‌های آپاچی و LiteSpeed کاربرد دارد. در Nginx باید محدودیت‌ها در داخل بلوک server با قوانین location تعریف شود و پس از آن با دستور nginx -t تنظیمات تست شود.

آیا این اقدام امنیتی سایت وردپرسی را کاملاً امن می‌کند؟

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

اگر افزونه امنیتی دارم، باز هم باید قانون wp-includes را اضافه کنم؟

بستگی دارد افزونه چه قوانینی اضافه می‌کند. برخی افزونه‌ها قوانین .htaccess را اضافه می‌کنند و برخی فقط در سطح برنامه محافظت دارند. محدودسازی دسترسی در سطح سرور معمولاً راهکار قوی‌تری است و بهتر است بدون تداخل با افزونه‌ها اجرا شود.