REST API وردپرس رابطی برای تعامل برنامه‌ها با داده‌ها و عملیات سایت از طریق درخواست HTTP است. پاسخ‌ها معمولاً JSON هستند. این رابط به معنی دسترسی آزاد به تمام دیتابیس یا امکان ویرایش نوشته‌ها توسط هر بازدیدکننده نیست؛ هر عملیات باید سیاست دسترسی خودش را داشته باشد.
REST API وردپرس کجا استفاده می‌شود؟
ویرایشگر بلوکی و بخش‌هایی از مدیریت، افزونه‌ها یا برنامهٔ بیرونی می‌توانند از این رابط استفاده کنند. برای مثال، خواندن نوشتهٔ عمومی با ذخیرهٔ تغییر در همان نوشته دو عملیات متفاوت است. مسدودکردن هر دو با یک قاعده می‌تواند انتشار محتوا را از کار بیندازد.
پیش از هر محدودیت، فهرست مصرف‌کننده‌ها را تهیه کنید: ویرایشگر، فرم‌ها، فروشگاه، جستجوی زنده و اتصال‌های بیرونی. وجود یا نبود هر مورد به سایت شما وابسته است. از نام یک افزونه نمی‌توان نتیجه گرفت که هیچ درخواست عمومی لازم ندارد.
دادهٔ عمومی، هویت و مجوز سه موضوع جدا هستند
نوشتهٔ منتشرشده می‌تواند از مسیر عمومی خوانده شود. محتوای خصوصی و عملیات مدیریتی به کنترل دسترسی نیاز دارند. ورود موفق فقط هویت را مشخص می‌کند؛ مجوز انجام عملیات باید با نقش و قابلیت حساب بررسی شود.
در مسیر سفارشی، برنامه‌نویس باید permission_callback متناسب با عملیات داشته باشد. بررسی نقش کلی یا اعتماد به شناسه‌ای که کاربر فرستاده کافی نیست. برای نمونه، اجازهٔ دیدن یک رکورد نباید خودکار اجازهٔ ویرایش رکورد کاربر دیگر را ایجاد کند.
آیا غیرفعال‌کردن کامل مناسب است؟
راهنمای رسمی وردپرس غیرفعال‌کردن REST را توصیه نمی‌کند، چون قابلیت‌های پنل به آن وابسته‌اند. مخفی‌کردن مسیرها نیز تضمین جلوگیری از DDoS یا همهٔ حملات ورود نیست. ابتدا مشخص کنید کدام داده یا عملیات واقعاً نباید عمومی باشد.
اگر یک مسیر سفارشی اطلاعات اضافی می‌دهد، اصلاح همان پاسخ و مجوز آن معمولاً تصمیم دقیق‌تری از مسدودکردن همهٔ مسیرهاست. اگر هدف محدودکردن فشار ترافیک است، اندازه‌گیری درخواست‌ها و کنترل نرخ در لایهٔ مناسب موضوع جداگانه‌ای است.
الزام احراز هویت چه محدودیتی دارد؟
در سایت دارای نیاز مشخص، توسعه‌دهنده می‌تواند با فیلتر rest_authentication_errors برای درخواست ناشناس خطا برگرداند. این کار «حذف API» نیست. نتیجهٔ بررسی‌های احراز هویت قبلی نباید نادیده گرفته شود و درخواست‌های معتبر باید مسیر درست خود را ادامه دهند.
کدهای کوتاهی که همیشه WP_Error برمی‌گردانند می‌توانند حتی درخواست مجاز ویرایشگر را ببندند. به همین دلیل، پیش از نصب کد عمومی یا افزونهٔ محدودسازی، رفتار آن را در محیط آزمایشی با وابستگی‌های واقعی ارزیابی کنید. تنظیم همهٔ نقش‌ها روی منع دسترسی، انتخاب پیش‌فرض مناسبی نیست.
آزمون بعد از محدودسازی
- با حساب مجاز، نوشته‌ای را ویرایش و ذخیره کنید.
- با کاربر فاقد مجوز، عملیات محدودشده را بررسی کنید.
- بدون ورود، فرم‌ها و قابلیت‌های عمومی وابسته را آزمایش کنید.
- اتصال بیرونی مجاز را با روش احراز هویت خودش کنترل کنید.
- پاسخ خطا را از نظر افشای اطلاعات اضافی بررسی کنید.
طبق مستند احراز هویت، درخواست مبتنی بر کوکی به nonce مناسب نیاز دارد؛ رمز کاربردی نیز روش دیگری برای اتصال مجاز روی HTTPS است. nonce جای بررسی قابلیت حساب را نمی‌گیرد. نتیجهٔ مطلوب، دسترسی درست هر مصرف‌کننده است؛ باز یا بسته‌بودن ظاهری مسیر به‌تنهایی معیار امنیت نیست.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
