مکانیزم اشتراکگذاری منابع بینمبدأیی یا همان CORS، یک لایه امنیتی حیاتی در مرورگرهای وب است که دسترسی به منابع یک دامنه دیگر را کنترل میکند. ابزار «جستجوگر CORS» به توسعهدهندگان فرانتاند، بکاند، پلتفرمهای API و متخصصان عملیات کمک میکند تا بدون نیاز به ارسال درخواستهای واقعی، رفتار مرورگر را در مواجهه با سرصفحههای پاسخ یک سرور شبیهسازی و تحلیل کنند. این ابزار مشخص میکند که آیا کد مرورگر قادر به خواندن یک پاسخ خاص خواهد بود یا خیر.
نحوه عملکرد و پردازش اطلاعات
این ابزار به صورت کاملاً محلی عمل میکند. هدرها و جزئیات درخواست شما در مرورگر شما باقی می مانند و هیچ چیزی در BroBroGo آپلود یا ذخیره نشده است. ابزار هیچگونه تماسی با سرورهای خارجی برقرار نمیکند، آدرسهای URL را نمیخواند، کوکی تنظیم نمیکند، وضعیت DNS یا TLS را بررسی نکرده و پیکربندی سرور را تغییر نمیدهد.
تحلیل انجامشده صرفاً بر اساس قوانین استاندارد CORS مرورگرها و ورودیهای واردشده توسط کاربر انجام میشود. یک نتیجه موفقیتآمیز در این ابزار، تضمینکننده کارکرد قطعی درخواست در محیط واقعی نیست؛ چرا که مواردی مانند تغییر مسیرها (Redirects)، پاسخهای ذخیرهشده در حافظه پنهان (Cache)، تغییر قوانین سرور، افزونههای مرورگر یا رفتار واقعی سرور پس از درخواست پیشپرواز (Preflight) میتوانند نتیجه نهایی را در مرورگر کاربر تغییر دهند.
ورودیهای ابزار و اعتبارسنجی آنها
برای بررسی خط مشی CORS، کاربر باید اطلاعات زیر را در بخش ورودی تنظیم کند:
- پاسخ به بررسی: کاربر باید بین دو گزینه «پاسخ واقعی» یا «پاسخ قبل از پرواز» یکی را انتخاب کند.
- هدرهای پاسخ HTTP: این بخش محل چسباندن سرصفحههای پاسخ سرور است. حداکثر طول مجاز برای این ورودی 200,000 کاراکتر است. در صورت خالی بودن، خطای «قبل از بررسی، سرصفحههای پاسخ HTTP را جایگذاری کنید.» نمایش داده میشود. اگر طول ورودی فراتر از حد مجاز باشد، خطای «این پاسخ به طور غیرعادی بزرگ است. آن را زیر کاراکترهای
‹max›نگه دارید.» صادر میشود. همچنین در صورت وجود خطای ساختاری در هدرها، خطاهای «خط‹line›یک عنوان HTTP یا خط وضعیت معتبر نیست.» یا «خط‹line›حاوی نام هدر HTTP نامعتبر است.» به کاربر نشان داده میشود. - درخواست مبدا: این ورودی شامل طرح (Scheme)، میزبان (Host) و پورت اختیاری مبدأ درخواستکننده است (مانند
https://app.example.com). این مقدار باید یک مبدأ خالص یاnullباشد و نباید شامل مسیر (Path)، پارامترهای پرسوجو (Query) یا اطلاعات کاربری باشد. در غیر این صورت، خطای «یک مبدا را فقط با یک طرح، میزبان و پورت اختیاری، مانند https://app.example.com وارد کنید.» نمایش داده میشود. - روش درخواستی: متد HTTP مورد نظر برای درخواست (مانند GET یا POST). در صورت نامعتبر بودن توکن متد، خطای «یک نشانه روش HTTP معتبر وارد کنید.» و در صورت استفاده از متدهای ممنوعه توسط مرورگر، خطای «مرورگرها روش
‹method›را در درخواست های fetch مجاز نمی دانند.» نمایش داده میشود. - درخواست نام سرصفحه: نام سرصفحههایی که در هدر
Access-Control-Request-Headersارسال میشوند و باید با کاما یا خط جدید از هم جدا شوند. در صورت نامعتبر بودن نام هدر، خطای «"‹header›" یک نام هدر درخواست HTTP معتبر نیست.» نمایش داده میشود. - شامل مدارک: یک دکمه دوحالته (Toggle) برای مشخص کردن اینکه آیا درخواست حاوی کوکیها یا اطلاعات احراز هویت HTTP (Credentials) است یا خیر.
در صورت وجود هرگونه اشکال در فرم، پیام «ورودی هایلایت شده را اصلاح کنید و دوباره امتحان کنید.» نمایش داده میشود.
تحلیل تصمیمات مرورگر و دلایل آن
پس از بررسی ورودیها، ابزار یکی از وضعیتهای زیر را به عنوان «تصمیم مرورگر» اعلام میکند:
- توسط پاسخ چسبانده شده CORS مجاز است.
- توسط پاسخ چسبانده شده CORS مسدود شده است.
- هدرها عبور می کنند، اما وضعیت قبل از پرواز مشخص نیست. (این حالت زمانی رخ میدهد که در بررسی پاسخ پیشپرواز، خط وضعیت HTTP در هدرهای چسباندهشده وجود نداشته باشد).
دلایل اتخاذ این تصمیمات بر اساس قوانین استاندارد به شرح زیر تحلیل و نمایش داده میشوند:
بررسی مبدأ (Origin)
- اگر هدر وجود نداشته باشد: «Access-Control-Allow-Origin وجود ندارد.»
- اگر تطابق دقیق برقرار باشد: «Access-Control-Allow-Origin دقیقاً با
‹origin›مطابقت دارد.» - اگر از علامت عام استفاده شده باشد: «Access-Control-Allow-Origin به هر منبعی برای این درخواست اجازه می دهد.»
- در صورت عدم تطابق: «Access-Control-Allow-Origin
‹actual›است، نه‹expected›.» - در صورت نامعتبر بودن مقدار هدر (مانند وجود چند مبدأ یا جداسازی با کاما): «Access-Control-Allow-Origin دارای یک مقدار نامعتبر است:
‹value›.»
بررسی اعتبارنامهها (Credentials)
- اگر درخواست حاوی اعتبارنامه باشد و هدر تایید وجود داشته باشد: «Access-Control-Allow-Credentials دقیقا درست است.»
- اگر درخواست حاوی اعتبارنامه باشد اما هدر تایید وجود نداشته یا مقدار آن
trueنباشد: «یک درخواست دارای اعتبار نیاز به Access-Control-Allow-Credentials دارد: درست است.» - اگر درخواست بدون اعتبارنامه باشد: «اعتبارنامه ها گنجانده نشده است، بنابراین Access-Control-Allow-Credentials بر این تصمیم تأثیر نمی گذارد.»
- قاعده مهم: در درخواستهای حاوی اعتبارنامه، استفاده از علامت عام
*در هدرAccess-Control-Allow-Originمجاز نیست و در صورت استفاده، دلیل «Access-Control-Allow-Origin نمی تواند * زمانی که اعتبارنامه گنجانده شده است.» نمایش داده میشود. همچنین در این حالت، علامتهای عام در متدها و هدرها کارایی خود را از دست میدهند.
بررسی وضعیت پیشپرواز (Preflight Status)
- اگر وضعیت موفق باشد: «وضعیت قبل از پرواز
‹status›موفقیت آمیز است.» - اگر وضعیت غیر از کد 2xx باشد: «وضعیت قبل از پرواز
‹status›یک وضعیت 2xx موفق نیست.» - اگر خط وضعیت وجود نداشته باشد: «هیچ خط وضعیت HTTP چسبانده نشده است، بنابراین وضعیت پیش از پرواز 2xx مورد نیاز قابل بررسی نیست.»
بررسی متدها و هدرهای درخواستی
- اگر متد تایید شود: «پیش از پرواز به
‹method›اجازه می دهد.» - اگر متد در لیست ایمن (Safelisted) باشد: «
‹method›یک روش ایمن شده با CORS است و نیازی به نمایش در Access-Control-Allow-Methods ندارد.» - اگر متد تایید نشود: «Access-Control-Allow-Methods اجازه
‹method›را نمی دهد.» - اگر هدرها تایید شوند: «پیش از پرواز اجازه نامهای هدر درخواستی را میدهد:
‹headers›.» - اگر هدرها نیازی به تایید نداشته باشند: «هیچ نام هدر درخواستی نیازی به تأیید قبل از پرواز ندارد.»
- اگر علامت عام هدرها را پوشش دهد (در درخواستهای بدون اعتبارنامه): «Access-Control-Allow-Headers: * این نامها را برای درخواست بدون اعتبار پوشش میدهد:
‹headers›.» - اگر هدرها تایید نشوند: «Access-Control-Allow-Headers اجازه نمی دهد:
‹headers›.» - استثنای هدر Authorization: هدر
Authorizationباید همواره به صورت صریح درAccess-Control-Allow-Headersذکر شود و علامت عام*حتی در درخواستهای بدون اعتبارنامه نیز آن را پوشش نمیدهد. در صورت عدم ذکر صریح، دلیل «Authorization باید به صراحت فهرست شود. Access-Control-Allow-Headers: * آن را پوشش نمی دهد.» نمایش داده میشود.
سوالات متداول (FAQ)
آیا باید پاسخ واقعی را بچسبانم یا پاسخ قبل از پرواز را؟
از پاسخ واقعی برای بررسی اینکه آیا کد مرورگر قادر به خواندن یک پاسخ است یا خیر استفاده کنید. از پاسخ Preflight برای پاسخ OPTIONS استفاده کنید که روش بعدی و نامهای هدر درخواستی آن را تأیید میکند.
چرا یک علامت عام ممکن است با اعتبارنامه شکست بخورد؟
وقتی کوکیها یا احراز هویت HTTP گنجانده میشوند، مبدا مجاز باید دقیقاً با مبدا درخواستکننده مطابقت داشته باشد. حروف عام برای متدهای مجاز و هدرها نیز معنای عام خود را از دست می دهند.
آیا نتیجه گذرا ثابت می کند که درخواست زنده کار می کند؟
نه. این نتیجه فقط پاسخ چسبانده شده و جزئیات درخواست وارد شده در اینجا را پوشش می دهد. تغییر مسیرها، پاسخهای ذخیره شده در حافظه پنهان، تغییر قوانین سرور، برنامههای افزودنی مرورگر و پاسخ واقعی پس از پرواز پیش از پرواز همچنان میتوانند نتیجه را تغییر دهند.