مدقق CORS

فهم سياسة مشاركة الموارد بين أصول مختلفة (CORS)

تعد سياسة مشاركة الموارد بين أصول مختلفة (CORS) آلية أمان أساسية تنفذها متصفحات الويب للتحكم في كيفية وصول تطبيقات الويب إلى الموارد المضافة على أصول مغايرة للأصل الذي نشأ منه التطبيق. عندما يحاول كود برمجيات المتصفح قراءة استجابة من خادم آخر، فإنه يتحقق من رؤوس استجابة HTTP للتأكد من أن الخادم يمنح الإذن صراحة لهذا الأصل بالوصول.

تساعد أداة "مدقق CORS" مطوري الواجهات الأمامية، ومطوري الواجهات الخلفية، ومطوري منصات واجهات برمجة التطبيقات (API)، ومطوري العمليات في التحقق مما إذا كان متصفح الويب سيسمح بطلب محدد عابر للأصول بناءً على رؤوس الاستجابة المقدمة وتفاصيل الطلب. تقوم الأداة بتحليل هذه البيانات محلياً دون الاتصال بالخادم، أو قراءة عناوين URL، أو تعيين ملفات تعريف الارتباط، أو التحقق من DNS/TLS، أو تعديل تكوينات الخادم.

مدخلات الأداة وقواعد التحقق

تتطلب الأداة تحديد مجموعة من المدخلات لمحاكاة قرار المتصفح بدقة:

• رد للتحقق: يتيح الاختيار بين "الاستجابة الفعلية" أو "استجابة الاختبار المبدئي".
• رؤوس استجابة HTTP: حقل نصي للصق رؤوس استجابة HTTP، ويجب تضمين سطر الحالة عند التحقق من استجابة الاختبار المبدئي. الحد الأقصى لطول هذا الحقل هو 200,000 حرف.
  • إذا كان الحقل فارغاً، تظهر رسالة الخطأ: "الصق رؤوس استجابة HTTP قبل التحقق.".
  • إذا تجاوز المدخل الحد الأقصى، تظهر رسالة الخطأ: "هذه الاستجابة كبيرة بشكل غير عادي. احتفظ بها تحت أحرف ‹max›.".
  • إذا كان هناك سطر غير صالح، تظهر رسالة الخطأ: "السطر ‹line› ليس رأس HTTP أو سطر حالة صالحًا.".
  • إذا كان اسم الرأس غير صالح، تظهر رسالة الخطأ: "يحتوي السطر ‹line› على اسم رأس HTTP غير صالح.".
• أصل الطلب: حقل نصي مخصص لإدخال المخطط، والمضيف، والمنفذ الاختياري للأصل (مثل https://app.example.com). يجب أن يكون أصلاً نقياً أو null دون مسار URL أو استعلام أو بيانات اعتماد.
  • إذا كان الأصل غير صالح، تظهر رسالة الخطأ: "أدخل أصلًا يحتوي فقط على مخطط ومضيف ومنفذ اختياري، مثل https://app.example.com.".
• الطريقة المطلوبة: حقل نصي لإدخال أسلوب HTTP.
  • إذا كانت الطريقة غير صالحة، تظهر رسالة الخطأ: "أدخل رمزًا مميزًا صالحًا لأسلوب HTTP.".
  • إذا كانت الطريقة محظورة في المتصفحات، تظهر رسالة الخطأ: "لا تسمح المتصفحات باستخدام أسلوب ‹method› في طلبات fetch.".
• أسماء العناوين المطلوبة: حقل نصي لإدخال أسماء الرؤوس المطلوبة من Access-Control-Request-Headers مفصولة بفواصل أو أسطر (مثل Content-Type، Authorization).
  • إذا كان الرأس غير صالح، تظهر رسالة الخطأ: ""‹header›" ليس اسمًا صالحًا لرأس طلب HTTP.".
• تضمين بيانات الاعتماد: مفتاح تبديل لتحديد ما إذا كان الطلب يتضمن ملفات تعريف الارتباط أو مصادقة HTTP.

في حال وجود أي مشكلة عامة في المدخلات، تظهر رسالة الخطأ: "قم بإصلاح الإدخال المميز وحاول مرة أخرى.".

مخرجات الأداة وقرارات المتصفح

بناءً على البيانات المدخلة، تعرض الأداة "قرار المتصفح" وحقول التحكم في الوصول التي تم تحليلها، بالإضافة إلى الأسباب التفصيلية للقرار. الحالات المحتملة لقرار المتصفح تشمل:

• "الصق ردًا للتحقق من سياسة CORS الخاصة به." (الحالة الأولية).
• "أدخل الرد وتفاصيل الطلب، ثم تحقق من سياسة CORS." (عند عدم وجود مدخلات).
• "مسموح به من خلال استجابة CORS التي تم لصقها.".
• "تم الحظر بواسطة استجابة CORS التي تم لصقها.".
• "تمر الرؤوس، لكن حالة الاختبار المبدئي غير معروفة.".

الأسباب التفصيلية المرتبطة بالأصل وبيانات الاعتماد

تتحقق الأداة من مطابقة الأصل وبيانات الاعتماد وتصدر الأسباب التالية حسب الحالة:

• "Access-Control-Allow-Origin يتطابق تمامًا مع ‹origin›.".
• "يسمح Access-Control-Allow-Origin بأي أصل لهذا الطلب.".
• "Access-Control-Allow-Origin مفقود.".
• "لا يمكن أن يكون Access-Control-Allow-Origin * عند تضمين بيانات الاعتماد.".
• "Access-Control-Allow-Origin هو ‹actual›، وليس ‹expected›.".
• "يحتوي Access-Control-Allow-Origin على قيمة غير صالحة: ‹value›.".
• "Access-Control-Allow-Credentials صحيح تمامًا.".
• "يحتاج طلب الاعتماد إلى Access-Control-Allow-Credentials: صحيح.".
• "لم يتم تضمين بيانات الاعتماد، لذلك لا يؤثر Access-Control-Allow-Credentials على هذا القرار.".

الأسباب التفصيلية المرتبطة بالاختبار المبدئي والأساليب والرؤوس

عند فحص استجابات الاختبار المبدئي (Preflight Requests)، يتم تقييم حالة الاستجابة والأساليب والرؤوس المطلوبة وفقاً للأسباب التالية:

• "حالة الاختبار المبدئي ‹status› ناجحة.".
• "حالة الاختبار المبدئي ‹status› ليست حالة 2xx ناجحة.".
• "لم يتم لصق أي سطر حالة HTTP، لذلك لا يمكن التحقق من حالة الاختبار المبدئي 2xx المطلوبة.".
• "يسمح الاختبار المبدئي بـ ‹method›.".
• "‹method› هي طريقة مدرجة في القائمة الآمنة لـ CORS ولا تحتاج إلى الظهور في Access-Control-Allow-Methods.".
• "Access-Control-Allow-Methods لا يسمح بـ ‹method›.".
• "لا توجد أسماء رؤوس مطلوبة تحتاج إلى موافقة الاختبار المبدئي.".
• "يسمح الاختبار المبدئي بأسماء الرؤوس المطلوبة: ‹headers›.".
• "Access-Control-Allow-Headers: يغطي * هذه الأسماء لطلب بدون بيانات اعتماد: ‹headers›.".
• "Access-Control-Allow-Headers لا يسمح بما يلي: ‹headers›.".
• "يجب إدراج Authorization بشكل صريح؛ Access-Control-Allow-Headers: * لا يغطيها.".

القواعد البرمجية والحالات الاستثنائية

تخضع عملية التحقق لعدة قواعد صارمة تحاكي سلوك المتصفح الفعلي:

1. بيانات الاعتماد وأحرف البدل: عند تضمين بيانات الاعتماد، لا يمكن استخدام حرف البدل * في الرأس Access-Control-Allow-Origin. كما تفقد أحرف البدل الخاصة بالأساليب والرؤوس المسموح بها معناها كأحرف بدل وتصبح قيمًا نصية عادية.
2. تعدد القيم: إذا احتوى الرأس Access-Control-Allow-Origin على قيم متعددة أو كان مفصولاً بفاصلة، فإنه يُعتبر غير صالح.
3. مطابقة بيانات الاعتماد: يجب أن تكون قيمة الرأس Access-Control-Allow-Credentials هي true تماماً للطلبات التي تتضمن بيانات اعتماد.
4. استثناء رأس التفويض: يجب إدراج رأس Authorization بشكل صريح في الرأس Access-Control-Allow-Headers عند الحاجة إليه، ولا يمكن تغطيته باستخدام حرف البدل * حتى في حال عدم تضمين بيانات الاعتماد.
5. غياب سطر الحالة: إذا لم تتضمن استجابة الاختبار المبدئي الملصقة سطر حالة HTTP، فإن نتيجة التحقق من حالة الاختبار المبدئي ستكون غير محددة ("indeterminate").

الخصوصية ومعالجة البيانات

تتم معالجة جميع البيانات المدخلة، بما في ذلك رؤوس الاستجابة وتفاصيل الطلب، محلياً داخل متصفح المستخدم. لا يتم رفع أي بيانات أو حفظها بواسطة BroBroGo.

الأسئلة الشائعة

هل يجب علي لصق الاستجابة الفعلية أم الاستجابة المبدئية؟
استخدم الاستجابة الفعلية للتحقق مما إذا كان كود المتصفح يمكنه قراءة استجابة واحدة. استخدم استجابة الاختبار المبدئي لرد OPTIONS الذي يوافق على الطريقة الأحدث وأسماء الرؤوس المطلوبة الخاصة بها.

لماذا يمكن أن تفشل حرف البدل مع بيانات الاعتماد؟
عند تضمين ملفات تعريف الارتباط أو مصادقة HTTP، يجب أن يتطابق الأصل المسموح به مع أصل الطلب تمامًا. تفقد أحرف البدل الخاصة بالأساليب والرؤوس المسموح بها أيضًا معنى أحرف البدل الخاصة بها.

هل تثبت نتيجة النجاح أن الطلب المباشر سيعمل؟
لا، هذه النتيجة تغطي فقط الرد الملصق وتفاصيل الطلب المدخلة هنا. لا يزال بإمكان عمليات إعادة التوجيه والاستجابات المخزنة مؤقتًا وتغيير قواعد الخادم وملحقات المتصفح والاستجابة الفعلية بعد الاختبار المبدئي تغيير النتيجة.