مشاركة الموارد عبر الأصول (CORS)

لماذا يهم

حين تكون الواجهة الأمامية وواجهة API على أصلين مختلفين، تعطّل ترويسة CORS مفقودة أو خاطئة ميزات حقيقية: لا تُحمَّل السلة، ولا يفعل زر الحفظ شيئاً، ولا تظهر رسالة الخطأ أبداً. وكثيراً ما تفشل بيئة واحدة فقط، لأن لكل بيئة نطاقاتها وإعدادات بوابتها.

وتحمي CORS البيانات أيضاً: فالخادم الذي يسمح لأي أصل بقراءة الاستجابات المرسلة مع ملفات تعريف الارتباط الخاصة بالمستخدم قد يتيح لمواقع أخرى يزورها المستخدم أن تقرأ تلك البيانات. وبالنسبة إلى المختبِر، تفسّر CORS كثيراً من بلاغات «يعمل في Postman ويفشل في المتصفح».

الأصول وسياسة الأصل نفسه

يتشارك عنوانان الأصل نفسه فقط إذا تطابق البروتوكول والمضيف والمنفذ جميعاً، ولا يهمّ المسار ولا الاستعلام. فالنطاق الفرعي مضيف مختلف، وhttp بروتوكول مختلف عن https، لذا فالمتجر وواجهته البرمجية أصلان مختلفان وإن كانت تديرهما شركة واحدة.

تتعلق سياسة الأصل نفسه بالقراءة أساساً لا بالإرسال: فالروابط والنماذج والصور والسكربتات القادمة من أصول أخرى تعمل كالمعتاد. ما تمنعه هو أن تقرأ شيفرة الصفحة استجابةً من أصل آخر. وتخفّف CORS هذه القاعدة بشروط الخادم: يرسل الخادم الترويسات ويطبّقها المتصفح، أما العملاء خارج المتصفح، مثل curl وPostman، فيتجاهلونها.

Page origin: https://shop.example.com

URL                                   Same origin?  Why
https://shop.example.com/cart?id=7    yes           only path and query differ
https://shop.example.com:443/help     yes           443 is the default https port
http://shop.example.com/cart          no            scheme differs
https://api.example.com/v1/cart       no            host differs (subdomain)
https://shop.example.com:8443/cart    no            port differs

الطلبات البسيطة والطلبات التي يسبقها طلب تمهيدي

طلب GET أو HEAD أو POST لا يحمل إلا ترويسات من القائمة الآمنة في CORS، مثل Accept أو Content-Type بإحدى القيم text/plain أو multipart/form-data أو application/x-www-form-urlencoded، يُرسل فوراً ومعه ترويسة Origin. ويسمّيه MDN «الطلب البسيط» (Simple Request)، مع أن معيار Fetch لا يستخدم هذا الاسم. ويعالجه الخادم أياً كانت إعدادات CORS لديه؛ فـCORS لا تقرر إلا ما إذا كان يحق للصفحة قراءة الاستجابة.

وأي طلب آخر إلى أصل مختلف يسبقه طلب تمهيدي (Preflight): PUT وPATCH وDELETE، أو POST مع Content-Type: application/json، أو ترويسة مثل Authorization. يرسل المتصفح أولاً طلب OPTIONS يذكر فيه الطريقة والترويسات التي يريد استخدامها. ولا يُرسل الطلب الفعلي إلا إذا تلقى الطلب التمهيدي استجابة بحالة من فئة ⁦2xx⁩ تسمح ترويساتها بالأصل والطريقة والترويسات، ثم تُفحص استجابته مرة أخرى. وإذا أُجيب الطلب التمهيدي بإعادة توجيه أو بحالة خطأ فإنه يفشل، ولا يغادر الطلب الفعلي المتصفح أبداً.

وبيانات الاعتماد (Credentials)، أي ملفات تعريف الارتباط أو مصادقة HTTP التي لا تُرسل إلى أصل آخر إلا إذا طلبتها الشيفرة بـcredentials: 'include' في fetch أو بـwithCredentials = true في XMLHttpRequest، تشدّد القواعد: يجب أن تذكر الاستجابتان الأصل بالضبط لا *، وأن ترسلا Access-Control-Allow-Credentials: true، ولا تعود * في قائمتي الطرق والترويسات المسموح بها حرفَ بدل (wildcard) أيضاً. أما الطلب التمهيدي نفسه فلا يحمل ملفات تعريف الارتباط أبداً.

• Origin (يضعها المتصفح)، ومعها في الطلب التمهيدي Access-Control-Request-Method وAccess-Control-Request-Headers: من يطلب، وما الذي سيستخدمه الطلب الفعلي.
• Access-Control-Allow-Origin: الأصل الوحيد المسموح له بالقراءة، أو * حين لا تدخل بيانات اعتماد.
• Access-Control-Allow-Methods وAccess-Control-Allow-Headers: ما تسمح به استجابة الطلب التمهيدي.
• Access-Control-Allow-Credentials: true: مطلوبة عند إرسال بيانات الاعتماد.
• Access-Control-Expose-Headers: ترويسات استجابة إضافية يحق للشيفرة قراءتها، مثل X-Total-Count. وAccess-Control-Max-Age: عدد الثواني التي يجوز فيها إعادة استخدام نتيجة الطلب التمهيدي، ضمن الحد الذي يفرضه كل متصفح.
• Vary: Origin: تخبر ذاكرات التخزين المؤقت بأن الاستجابة تختلف باختلاف الأصل، وهي لازمة حين يعيد الخادم الأصل في استجابته.

جرّبها: فاحص CORS جرّبها: منشئ ترويسات HTTP

أخطاء الإعداد الشائعة

الإعدادات المفرطة في التشدد أو غير المتسقة تحجب الواجهة الأمامية الحقيقية وتعطّل الميزات، والإعدادات المفرطة في التساهل تتيح لمواقع أخرى قراءة البيانات عبر متصفح مستخدم مسجّل الدخول، ولهذا يتناول دليل OWASP لاختبار أمان الويب (Web Security Testing Guide) إعدادات CORS. ويتوقف مدى ما يبلغه موقع آخر فعلاً على سمة SameSite في ملفات تعريف الارتباط وعلى إعدادات المتصفح لملفات تعريف الارتباط التابعة لجهات خارجية (انظر درس ملفات تعريف الارتباط والجلسات)، لكن المختبِر يُبلغ عن السياسة المفرطة في التساهل نفسها.

• يعطّل الميزات: تطبيق المصادقة على OPTIONS، فيتلقى الطلب التمهيدي الخالي من ملفات تعريف الارتباط الحالة 401 أو 403.
• يعطّل الميزات: إعادة توجيه على الطلب التمهيدي، مثل إضافة شرطة مائلة في نهاية المسار (انظر درس إعادة التوجيه في HTTP).
• يعطّل الميزات: ترويسات CORS على استجابات النجاح فقط، فتصل الحالة 400 أو 500 إلى الصفحة خطأَ شبكة عاماً.
• يعطّل الميزات: إرسال Access-Control-Allow-Origin مرتين (من التطبيق ومن البوابة) أو في صورة قائمة؛ ويجب أن تحمل قيمة واحدة.
• يكشف البيانات: إعادة أي Origin مع Access-Control-Allow-Credentials: true، أو السماح بـOrigin: null التي يستطيع أي موقع إنتاجها من إطار معزول (sandboxed).
• يكشف البيانات: مطابقة الأصول بالبادئة أو اللاحقة أو بنمط غير مثبّت الطرفين، فيمرّ https://shop.example.com.attacker.test أو https://notexample.com.

كيف تختبر CORS

ابدأ في متصفح حقيقي، لأن المتصفح وحده هو من يطبّق CORS. في لوحة Network ضمن أدوات المطوّرين يظهر الطلب التمهيدي سطراً مستقلاً بالطريقة OPTIONS قبل الطلب الفعلي مباشرةً (وإن لم يظهر فأزل مرشّح Fetch/XHR). وتشرح وحدة التحكم سبب حظر الاستجابة، بينما لا تتلقى شيفرة الصفحة إلا خطأً عاماً، وهو في Chrome TypeError: Failed to fetch.

ثم أعد إرسال الطلبات باستخدام curl أو أداة CORS Tester، وضع أي قيمة تحتاجها في Origin، وطبّق فحوص المتصفح بنفسك، على الأنظمة التي تملكها أو لديك إذن مكتوب باختبارها فقط. واستخرج شروط الاختبار من المستدعين الحقيقيين: كل أصل للواجهة الأمامية في كل بيئة، وكل طريقة وترويسة، مع ملفات تعريف الارتباط ومن دونها.

• الأصل المسموح: طلب تمهيدي بحالة ⁦2xx⁩ وترويسات Allow-* الصحيحة، وAccess-Control-Allow-Origin في الاستجابة الفعلية أيضاً.
• أصول غير مدرجة مثل https://attacker.test وnull، وصيغ معدّلة من أصل مسموح: http:// بدلاً من https://، ومنفذ آخر، ومضيفون متشابهون في الاسم مثل https://shop.example.com.attacker.test. ولا يجوز أن يُعاد أي منها.
• كل طريقة وترويسة ترسلها الواجهة الأمامية فعلاً، لا GET وحدها.
• استجابات الخطأ (401 و404 و500) بترويسات CORS نفسها التي في استجابات النجاح.
• مع بيانات الاعتماد: لا *، وVary: Origin كلما أُعيد الأصل.

curl -i -X OPTIONS https://api.example.com/v1/cart/items/42 \
  -H "Origin: https://shop.example.com" \
  -H "Access-Control-Request-Method: PUT" \
  -H "Access-Control-Request-Headers: content-type"

جرّبها: فاحص CORS جرّبها: مولّد أوامر cURL جرّبها: محلّل ترويسات HTTP

مثال تطبيقي: تحديث السلة محظور في بيئة الإنتاج

في بيئة Staging يعمل تغيير الكمية في السلة، أما في بيئة الإنتاج فلا يحدث شيء وتعرض وحدة التحكم خطأ CORS. ترسل الواجهة الأمامية على https://shop.example.com الطلب PUT /v1/cart/items/42 إلى https://api.example.com مع جسم JSON وملفات تعريف الارتباط، فيسبقه المتصفح بطلب تمهيدي. ويعيد المختبِر إرسال الطلب التمهيدي باستخدام curl.

الحالة والأصل وبيانات الاعتماد صحيحة، لكن Access-Control-Allow-Methods تخلو من PUT، فيتوقف المتصفح بعد الطلب التمهيدي ولا يصل PUT إلى واجهة API أبداً، ولا يُظهر أي سجل في الخادم تحديثاً فاشلاً. وتعمل بيئة Staging لأن بوابتها مُعدّة على حدة.

وعند تكرار الطلب التمهيدي وطلب GET /v1/cart مع Origin: https://attacker.test ومع أصل آخر لا علاقة له بالتطبيق، يُعاد الأصلان كلاهما مع Access-Control-Allow-Credentials: true: عيب أمني مستقل يُبلَّغ عنه عبر قناة خاصة، لأن مواقع أخرى تستطيع حينئذٍ قراءة بيانات العميل المسجّل الدخول.

OPTIONS /v1/cart/items/42 HTTP/1.1
Host: api.example.com
Origin: https://shop.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://shop.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Credentials: true
Vary: Origin

أسئلة شائعة

المراجع

• Fetch StandardWHATWGيعرّف CORS: طلبات التحقق المسبق وترويسات Access-Control-* والاستجابات التي يسمح المتصفح للصفحة برؤيتها.
• Cross-Origin Resource Sharing (CORS) — MDNMDN Web Docs (Mozilla)كيف يعمل CORS عملياً: الطلبات البسيطة مقابل الطلبات ذات التحقق المسبق، وبيانات الاعتماد، والأخطاء التي تبلّغ عنها المتصفحات.
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• HTML Living StandardWHATWGلغة HTML، بما فيها مراجع المحارف المسماة (الكيانات) وقواعد التحليل التي تتبعها المتصفحات.