امنیت REST API وردپرس؛ راهنمای ساخت endpoint امن

امنیت REST API وردپرس؛ راهنمای ساخت endpoint امن

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

REST API وردپرس چگونه کار می‌کند؟

REST API راهی برای تبادل داده میان وردپرس و برنامه‌های دیگر فراهم می‌کند. هر endpoint با یک مسیر و روش HTTP مشخص می‌شود؛ برای نمونه، یک مسیر ممکن است داده‌ای را با درخواست GET برگرداند و مسیر دیگری با POST اطلاعاتی دریافت کند. پاسخ معمولاً در قالب JSON ارائه می‌شود. وردپرس نیز برای بخشی از قابلیت‌های داخلی خود، از جمله ارتباطات ویرایشگر و نمایش محتوا، از REST API استفاده می‌کند.

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

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

ابتدا نوع داده و سطح دسترسی را مشخص کنید

پیش از نوشتن کد، فهرست کنید endpoint به چه داده‌ای دسترسی دارد و چه تغییری می‌تواند انجام دهد. تفاوت میان «خواندن فهرست عمومی دسته‌ها» و «ویرایش نقش کاربران» بنیادی است. برای هر مسیر این پرسش‌ها را پاسخ دهید: چه کسی باید آن را فراخوانی کند؟ آیا داده برای عموم قابل مشاهده است؟ آیا درخواست باعث تغییر پایگاه داده یا تنظیمات می‌شود؟ آیا پاسخ شامل اطلاعاتی است که نباید در اختیار همه قرار گیرد؟

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

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

permission_callback را برای هر مسیر تعریف کنید

هنگام ثبت مسیر سفارشی با register_rest_route()، برای آن permission_callback تعریف کنید. این تابع مسئول تصمیم‌گیری دربارهٔ اجازهٔ دسترسی است و باید بر اساس نوع عملیات و کاربر فعلی نتیجه بدهد. بازگرداندن true یعنی درخواست مجاز است؛ این کار برای مسیر عمومیِ واقعاً عمومی می‌تواند عمدی باشد، اما نباید به راه‌حل پیش‌فرض برای مسیرهای خصوصی تبدیل شود.

پیشنهادات

افزونه پشتیبانی از طریق واتساپ WordPress WhatsApp Support

افزونه WordPress WhatsApp Support یک افزونه قدرتمند...

آموزش راه‌اندازی Object Cache در وردپرس با Redis و Memcached

Object Cache در وردپرس با نگه‌داشتن کوئری‌های...

افزونه Asset CleanUp Pro – کم کردن حجم و افزایش سرعت لود سایت

افزونه Asset CleanUp Pro به عنوان یک...

استفاده از هوش مصنوعی در وردپرس – چرا و چگونه؟ (بخش دوم)

هوش مصنوعی در وردپرس به مجموعه‌ای از...

WP-Cron وردپرس چیست؟ آموزش رفع مشکلات و تنظیم کرون واقعی

آموزش WP-Cron وردپرس؛ از نحوه کار زمان‌بندی...

نمونهٔ زیر یک مسیر آزمایشی را ثبت می‌کند که فقط کاربر دارای قابلیت مدیریت گزینه‌های سایت می‌تواند به آن درخواست POST بفرستد. مقدار ورودی پاک‌سازی و از نظر خالی‌نبودن بررسی می‌شود. این مثال داده‌ای را ذخیره نمی‌کند و برای استفادهٔ واقعی باید دسترسی و رفتار endpoint را با نیاز پروژه هماهنگ کنید.

add_action( 'rest_api_init', function () {
    register_rest_route( 'example/v1', '/message', array(
        'methods'  => 'POST',
        'permission_callback' => function () {
            return current_user_can( 'manage_options' );
        },
        'args'     => array(
            'title' => array(
                'required'          => true,
                'sanitize_callback' => 'sanitize_text_field',
                'validate_callback' => function ( $value ) {
                    return is_string( $value )
                        && trim( $value ) !== '';
                },
            ),
        ),
        'callback' => function ( WP_REST_Request $request ) {
            return new WP_REST_Response(
                array( 'title' => $request->get_param( 'title' ) ),
                200
            );
        },
    ) );
} );

این کنترل مجوز به معنای امن‌بودن خودکار تمام بخش‌های مسیر نیست. اگر endpoint به یک منبع خاص دسترسی دارد، بررسی کنید کاربر اجازهٔ دسترسی به همان منبع را داشته باشد. همچنین در کد واقعی خطاها و پاسخ‌های مناسب را مدیریت کنید و از بازگرداندن داده‌های اضافی، مسیرهای داخلی یا جزئیات فنی غیرضروری خودداری کنید.

احراز هویت، nonce و درخواست‌های عمومی

در درخواست‌های فرستاده‌شده از بخش مدیریت وردپرس، احراز هویت مبتنی بر کوکی معمولاً همراه با nonce مخصوص REST API به کار می‌رود. nonce در این کاربرد به وردپرس کمک می‌کند درخواست‌های انجام‌شده از سوی مرورگرِ کاربر واردشده را از برخی درخواست‌های ناخواستهٔ بین‌سایتی تشخیص دهد. بااین‌حال، nonce جایگزین کنترل مجوز نیست و به‌تنهایی اثبات نمی‌کند کاربر اجازهٔ انجام عملیات موردنظر را دارد.

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

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

ورودی را اعتبارسنجی و پاک‌سازی کنید

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

اعتبارسنجی می‌پرسد آیا مقدار با قواعد کسب‌وکار سازگار است؛ پاک‌سازی آن را به شکل مناسب برای استفاده تبدیل می‌کند. این دو مفهوم جای یکدیگر را نمی‌گیرند. تابعی مانند sanitize_text_field() ممکن است برای متن ساده مفید باشد، اما برای همهٔ انواع داده مناسب نیست. برای ایمیل، URL، عدد یا محتوای غنی باید روش متناسب انتخاب کنید و همچنان بررسی کنید مقدار نهایی در محدودهٔ مورد انتظار قرار دارد.

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

پاسخ API را متناسب با زمینهٔ مصرف ایمن کنید

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

دادهٔ JSON را به‌عنوان HTML ایمن فرض نکنید. اگر برنامهٔ مصرف‌کننده مقدار دریافتی را در صفحه نمایش می‌دهد، باید آن را متناسب با زمینهٔ نمایش Escape کند. متن داخل HTML، ویژگی HTML و کد JavaScript قواعد متفاوتی دارند. همچنین از قراردادن دادهٔ غیرقابل‌اعتماد در HTML با روش‌هایی که مرورگر آن را به‌عنوان نشانه‌گذاری اجرا می‌کند، اجتناب کنید. پاک‌سازی ورودی به‌تنهایی جای Escape خروجی را نمی‌گیرد، زیرا یک مقدار ممکن است در زمینه‌های مختلف استفاده شود.

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

روش HTTP و اثر عملیات را جدی بگیرید

روش درخواست باید با رفتار endpoint سازگار باشد. معمولاً GET برای خواندن داده و POST برای ارسال داده یا انجام عملیاتی که تغییر ایجاد می‌کند مناسب است؛ برای به‌روزرسانی یا حذف نیز می‌توان از روش‌های مرتبط استفاده کرد، به شرط آنکه قرارداد مسیر روشن باشد. عملیاتی را که وضعیت سایت را تغییر می‌دهد در یک مسیر GET قرار ندهید: ابزارهای واسط، پیش‌بارگذاری مرورگر یا سامانه‌های کش ممکن است درخواست GET را با فرض بی‌اثر بودن تکرار کنند.

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

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

آزمون و عیب‌یابی endpoint

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

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

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

چک‌لیست پیش از انتشار

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

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

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