في هذا الدرس 7تصفّح المواضيع
تخيّل أنك سجّلت دخولك إلى حسابك البنكي أو بريدك الشخصي في التبويب الأول من المتصفح، وفي اللحظة نفسها فتحت موقع ألعاب أو مدونة خارجية في التبويب الثاني. ما الذي يمنع كود الذي يعمل داخل التبويب الثاني من إرسال طلب خفي في الخلفية إلى موقع البنك وقراءة رصيدك ورسائلك الخاصة؟ الحارس الأساسي الذي يحميك داخل كل متصفح ويب حديث هو سياسة نفس المصدر ()، وتكملها آلية التصاريح المنضبطة عبر رؤوس الرسائل: مشاركة الموارد عبر المصادر ().
أهداف التعلم في هذا الدرس:
- تحديد مفهوم المصدر () من خلال أركانه الثلاثة الدقيقة () والتمييز بين الروابط المتطابقة والمختلفة المصدر.
- استيعاب الدافع الأمني لفرض سياسة نفس المصدر () افتراضياً لعزل التبويبات وحماية جلسات المستخدم المسجل.
- التعرف على الحالات الهندسية الشرعية التي تحتاج فيها المواقع للتواصل عبر المصادر (مثل تواصل واجهة مع خادم البيانات ).
- تتبع آلية عمل تصاريح عبر رأس الطلب ورأس الاستجابة ، والمقارنة بين الطلبات البسيطة وطلبات التفاوض المسبق ()، وتطبيق قواعد حماية بيانات الاعتماد ومنع النجمة الشاملة ().
قبل الغوص في تفاصيل هذا الدرس، استعرض جدول المصطلحات الأساسية التالية:
| المصطلح بالعربية | المصطلح بالإنجليزية | النطق التقني | المعنى المبسط |
|---|---|---|---|
| المصدر في الويب | ويب أوريجين | الهوية الثلاثية للموقع وتتكوّن من المخطط (Scheme) واسم المضيف (Host) ورقم المنفذ (Port). | |
| سياسة نفس المصدر | سيم أوريجين بوليسي | قاعدة أمان مدمجة في المتصفح تمنع سكربتات صفحة ويب من قراءة بيانات مستلمة من مصدر آخر مختلف. | |
| الطلبات العابرة للمصادر | كروس أوريجين ريكويست | طلب شبكة ترسله صفحة ويب إلى عنوان يختلف عنها في البروتوكول أو النطاق أو رقم المنفذ. | |
| مشاركة الموارد عبر المصادر | كورس (CORS) | آلية قياسية تعتمد على رؤوس HTTP يصرّح فيها الخادم للمتصفح بالسماح لمصادر محددة بقراءة استجاباته. | |
| طلب التفاوض المسبق | بري فلايت ريكويست | طلب استئذان أولي بطريقة OPTIONS يرسله المتصفح تلقائياً للتحقق من موافقة الخادم قبل إرسال الطلب الفعلي. | |
| رأس السماح بالمصدر | أكسس كنترول ألاو أوريجين | حقل رأس الاستجابة الأساسي في CORS الذي يحدد فيه الخادم المصدر المسموح له بقراءة البيانات. |
قبل أن نفهم كيف يعزل متصفح الويب المواقع عن بعضها لحماية المستخدم، نحتاج أولاً إلى معرفة كيف يحدد المتصفح «الهوية الأمنية» لكل موقع، وهو ما يُعرف تقنياً باسم المصدر (). يُعرّف المتصفح المصدر من خلال التطابق التام بين ثلاثة أجزاء أساسية في عنوان فقط:
- 1. المخطط أو البروتوكول (): مثل أو . حتى لو تطابق اسم النطاق بالكامل، يعتبر المتصفح و مصدرين مختلفين.
- 2. اسم المضيف أو النطاق (): مثل أو أو ؛ ويشترط تطابق الاسم حرفياً بما فيه النطاقات الفرعية.
- 3. رقم المنفذ الشبكي (): مثل المنفذ الافتراضي لبروتوكول ، أو المنفذ لبروتوكول ، أو منافذ التطوير المحلية مثل و.
لاحظ أن مسار الملف داخل الموقع (مثل ) أو معلمات الاستعلام (مثل ) لا تدخل في حساب المصدر؛ فجميع صفحات ومجلدات الموقع الواحد التي تشترك في نفس المخطط والمضيف والمنفذ تنتمي إلى نفس المصدر تماماً. تأمل المخطط التوضيحي الآتي:
لمعرفة ما إذا كان رابطان ينتميان إلى نفس المصدر () أم إلى مصدر مختلف ()، قارن الأركان الثلاثة () جنباً إلى جنب. لنفترض أن المتصفح يعرض حالياً الصفحة (حيث المنفذ الضمني لبروتوكول هو ):
| الرابط المطلوب من داخل الصفحة | حكم المتصفح | السبب التقني الدقيق |
|---|---|---|
| نفس المصدر () | تطابق المخطط () والمضيف () والمنفذ ()؛ وتغيّر المسار فقط. | |
| مصدر مختلف () | اختلاف البروتوكول ( بدلاً من ) واختلاف المنفذ الافتراضي ( مقابل ). | |
| مصدر مختلف () | اختلاف اسم المضيف الفرعي ( مقابل ). | |
| مصدر مختلف () | اختلاف رقم المنفذ الصريح ( مقابل المنفذ القياسي ). | |
| مصدر مختلف () | اختلاف اسم النطاق بالكامل (). |
لماذا يطبّق المتصفح سياسة نفس المصدر () بهذه الصرامة؟ لأن المتصفح يحتفظ بملفات تعريف الارتباط () وجلسات الدخول النشطة للمستخدم في مختلف المواقع. فلو لم تكن سياسة موجودة، وكان المستخدم مسجلاً في بريده الإلكتروني ثم فتح موقعاً خارجياً في تبويب آخر، لاستطاع كود في الموقع الخارجي طلب صندوق الرسائل وقراءة جميع محتوياته الخاصة!
وللموازنة بين سهولة تصفح الويب وحماية خصوصية البيانات، تطبّق سياسة نفس المصدر ثلاث قواعد افتراضية واضحة:
- السماح بتضمين الوسائط العامة (): يسمح المتصفح للصفحة بعرض صورة خارجية بوسم أو ملف تنسيق من شبكة توزيع محتوى () دون تمكين السكربت من قراءة البيانات الخاصة.
- السماح بالانتقال بالروابط (): النقر على رابط للانتقال إلى موقع آخر يعمل بشكل طبيعي (ولهذا تستخدم الخوادم سمة للكوكيز لحماية إجراءات التعديل).
- الحظر الصارم لقراءة استجابات المصادر الأخرى عبر : يمنع المتصفح افتراضياً أي كود يعمل في المصدر (أ) من قراءة محتوى الاستجابة القادمة من المصدر (ب)، ما لم يرسل الخادم (ب) تصريحاً صريحاً عبر رؤوس .
إذا كانت سياسة نفس المصدر تحظر قراءة البيانات بين المصادر المختلفة افتراضياً، فماذا نفعل عندما يحتاج تطبيق ويب شرعي إلى جلب بيانات من نطاق آخر عن قصد؟ في بنية تطبيقات الويب الحديثة، تبرز الحاجة المشروعة للطلبات العابرة للمصادر في سيناريوهات يومية عديدة:
- فصل نطاق الواجهة الأمامية عن نطاق الخادم الخلفي (): تستضيف كثير من الشركات واجهة موقعها على النطاق بينما يعمل خادم البيانات على النطاق الفرعي . ونظراً لاختلاف اسم المضيف الفرعي، يُعد كل طلب بينهما طلباً عابراً للمصادر!
- الاتصال بالواجهات البرمجية العامة (): مثل جلب بيانات الطقس أو أسعار الصرف أو الخرائط بصيغة من خدمة خارجية موثوقة.
- تحميل خطوط الويب والموارد من نطاقات التوزيع (): يشترط المتصفح تصريحاً عابراً للمصادر عند جلب ملفات الخطوط () من نطاق مخصص للملفات الثابتة مثل .
للسماح للطلبات الشرعية بالعبور بين المصادر دون المساس بحماية سياسة نفس المصدر، اعتمدت معايير الويب آلية مشاركة الموارد عبر المصادر (). وتعمل آلية عبر حوار منظم باستخدام رؤوس رسائل بين المتصفح والخادم المستهدف:
- الخطوة 1 — يضيف المتصفح رأس الطلب تلقائياً: عندما يرسل كود في طلباً إلى ، يرفق المتصفح تلقائياً حقل الرأس (ولا يستطيع كود تزوير هذا الرأس أو إخفاءه).
- الخطوة 2 — يرد الخادم برأس التصريح : إذا كان الخادم يثق بهذا المصدر، فإنه يدرج في استجابته حقل الرأس (أو القيمة العامة للبيانات العامة المفتوحة للجميع).
- الخطوة 3 — يتحقق المتصفح من التطابق قبل تسليم البيانات: إذا طابق رأس الاستجابة مصدر الصفحة، يسلّم المتصفح بيانات لكود بأمان. أما إذا غاب الرأس أو لم يطابق المصدر، فيحجب المتصفح قراءة الاستجابة فوراً ويظهر تنبيه في لوحة .
شاهد في المثال الآتي كيف يبدو تبادل رؤوس الطلب والاستجابة عند نجاح تصريح :
# 1. Browser Request from https://app.example.com to https://api.example.com
GET /v1/courses HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
# 2. API Server Response Explicitly Allowing https://app.example.com
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Access-Control-Allow-Origin: https://app.example.comيقسّم المتصفح الطلبات العابرة للمصادر إلى فئتين لحماية الخوادم من الطلبات غير المتوقعة التي قد تعدّل البيانات:
- 1. الطلبات البسيطة (): هي الطلبات التقليدية التي تستخدم طريقة أو أو القياسية للنماذج دون رؤوس مخصصة؛ حيث يرسلها المتصفح مباشرة مرفقة برأس ويفحص الاستجابة.
- 2. الطلبات المسبوقة باستعلام التفاوض (): عندما يحاول كود إرسال طلب غير بسيط—مثل استخدام طرق التعديل والحذف ( أو أو )، أو إرسال جسم بصيغة ، أو إرفاق رأس مصادقة مثل —يتوقف المتصفح لحظة ويرسل تلقائياً طلب استئذان أولي بطريقة يسأل فيه الخادم: «هل تسمح لهذا المصدر باستخدام هذه الطريقة وهذه الرؤوس؟». ولا يرسل المتصفح الطلب الفعلي إلا بعد موافقة الخادم!
تأمل تشريح طلب التفاوض المسبق في المثال الآتي، ثم جرّب الحالات الأربع عملياً في المحاكي التفاعلي أدناه:
# Browser Automatic Preflight Request Before Sending DELETE or JSON
OPTIONS /v1/orders/42 HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: authorization, content-type
# Server Preflight Approval Response (204 No Content)
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Typeافتراضياً، لا يرسل المتصفح ملفات تعريف الارتباط () مع طلبات العابرة للمصادر حمايةً للمستخدم. وعندما تحتاج واجهة موثوقة مثل إلى إرسال كوكيز الجلسة إلى خادمها ، يفرض المتصفح قاعدة أمان ذهبية صارمة:
- 1. التصريح الصريح بقبول بيانات الاعتماد: يجب أن يرسل الخادم في استجابته حقل الرأس .
- 2. الحظر التام للجمع بين النجمة الشاملة () والكوكيز: عند تفعيل إرسال الكوكيز وبيانات الاعتماد، يمنع المتصفح منعاً باتاً استخدام القيمة النجمية العامة ويحجب الاستجابة فوراً! بل يجب على الخادم تحديد اسم المصدر الموثوق بالاسم الصريح (مثل ).
- 3. التحقق من قائمة المصادر الموثوقة (): يجب أن يقارن الخادم قيمة بقائمة نطاقات محددة ومعتمدة لديه، وألا ينسخ أي مصدر عشوائي يرد في الطلب.
# INVALID (Blocked by Browser): Wildcard * cannot be used with Credentials!
# Access-Control-Allow-Origin: *
# Access-Control-Allow-Credentials: true
# VALID & SECURE: Explicit trusted origin from server allowlist + Credentials
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: Originملخص الدرس
حصاد الدرسمراجعة مركّزة لأهم المفاهيم والقواعد الهندسية التي أتقنتها في هذا الدرس قبل التطبيق العملي
ماذا تعلّمت في هذا الدرس؟
تعلّمنا في هذا الدرس أن المصدر () في المتصفح يتحدد بثلاثة أركان صارمة ()، وأن سياسة نفس المصدر () تحمي حسابات المستخدمين عبر منع قراءة بيانات المصادر المختلفة افتراضياً، وأن آلية تمكّن الخادم من منح تصاريح آمنة عبر رأس الرسالة وطلبات التفاوض المسبق مع حظر الجمع بين النجمة الشاملة () والكوكيز الخاصة. الخطوة التالية: انتقل الآن إلى الدرس التالي (مبادئ التشفير والتجزئة الرقمية للويب) لنكتشف معاً كيف تحمي خوارزميات التجزئة والتمليح والتشفير المتماثل وغير المتماثل كلمات المرور واتصالات !
سجّل الدخول لحفظ تقدمك
تابع إنجاز المواضيع والمصطلحات والمهام، وكمّل من آخر خطوة على أي جهاز.
المصطلحات8
راجع المعنى، اشرحه لنفسك، ثم علّم البطاقة كمفهومة.
- 01 Web Origin المصدر في الويب (Origin)
- الهوية الأمنية للموقع في المتصفح وتتكوّن من تطابق ثلاثة أجزاء: المخطط (Scheme) واسم المضيف (Host) ورقم المنفذ (Port).
- للمراجعة
- 02 Same-Origin Policy (SOP) سياسة نفس المصدر (SOP)
- آلية الحماية الافتراضية في المتصفح التي تمنع سكربتات موقع من قراءة البيانات المستلمة من مصدر آخر مختلف لحماية جلسات المستخدم.
- للمراجعة
- 03 Cross-Origin Resource Sharing (CORS) مشاركة الموارد عبر المصادر (CORS)
- معيار يعتمد على رؤوس HTTP يسمح للخادم بالتصريح الانتقائي لمصادر خارجية موثوقة بقراءة استجاباته بأمان.
- للمراجعة
- 04 Origin Request Header رأس الطلب Origin
- حقل رأس يضيفه المتصفح تلقائياً للطلب ليخبر الخادم بالمصدر الذي انطلق منه الطلب ولا يمكن للسكربت تزويره.
- للمراجعة
- 05 Access-Control-Allow-Origin رأس التصريح Access-Control-Allow-Origin
- حقل رأس الاستجابة الأساسي في CORS الذي يحدد فيه الخادم اسم المصدر المسموح له بقراءة البيانات أو النجمة (*) للموارد العامة.
- للمراجعة
- 06 Preflight Request (OPTIONS) طلب التفاوض المسبق (OPTIONS)
- طلب استئذان أولي بطريقة OPTIONS يرسله المتصفح تلقائياً قبل إرسال طلبات JSON أو الحذف للتحقق من موافقة الخادم.
- للمراجعة
- 07 Access-Control-Allow-Credentials رأس السماح ببيانات الاعتماد
- حقل رأس يتيح قراءة الاستجابات المقترنة بالكوكيز عبر المصادر، ويشترط تحديد المصدر بالاسم الصريح ويمنع استخدام النجمة (*).
- للمراجعة
- 08 Vary: Origin Header رأس Vary: Origin
- حقل رأس يوجه ذاكرات التخزين المؤقت المشتركة لتمييز النسخ المحفوظة بحسب مصدر الطلب لمنع تداخل تصاريح CORS.
- للمراجعة
لا توجد بطاقات تطابق البحث والتصفية.
اقرأ البطاقات بحرية. سجّل الدخول لحفظ تقدم مراجعتك.
الاختصارات5
راجع المعنى، اشرحه لنفسك، ثم علّم البطاقة كمفهومة.
- 01 SOP SOP
- Same-Origin Policy
- سياسة نفس المصدر في متصفح الويب التي تعزل بيانات المواقع المختلفة لحماية المستخدمين.
- للمراجعة
- 02 CORS CORS
- Cross-Origin Resource Sharing
- مشاركة الموارد عبر المصادر باستخدام رؤوس HTTP للتصريح الآمن بين النطاقات الموثوقة.
- للمراجعة
- 03 ACAO ACAO
- Access-Control-Allow-Origin
- الاختصار الشائع لحقل رأس الاستجابة Access-Control-Allow-Origin في أدوات فحص الشبكة.
- للمراجعة
- 04 WHATWG WHATWG
- Web Hypertext Application Technology Working Group
- مجموعة عمل تقنيات تطبيقات الويب المسؤولة عن معيار Fetch القياسي المنظم لآلية CORS في المتصفحات.
- للمراجعة
- 05 CDN CDN
- Content Delivery Network
- شبكة توصيل المحتوى التي تستضيف الخطوط والملفات الثابتة على نطاقات خارجية وتحتاج لتصاريح CORS.
- للمراجعة
لا توجد بطاقات تطابق البحث والتصفية.
اقرأ البطاقات بحرية. سجّل الدخول لحفظ تقدم مراجعتك.
مهامك قبل الاختبار
خطوة صغيرة كل مرة. وإنجاز تقدر ترجع له.
-
راجع جدول المقارنة في الموضوع الثاني للعنوان https://store.example.com/products/index.html وحدد أي ركن من الأركان الثلاثة (البروتوكول أو المضيف أو المنفذ) أدى لاختلاف المصدر في كل حالة.
-
تنقّل بين الخطوات الأربع في المحاكي التفاعلي بالموضوع السادس وقارن متى يحجب المتصفح قراءة الاستجابة ومتى يرسل طلب التفاوض المسبق OPTIONS تلقائياً.
-
نفّذ في الطرفية أمر curl -i مع إرفاق رأس -H "Origin: https://example.com" على بيئتك المحلية ولاحظ ظهور رأس Access-Control-Allow-Origin في الاستجابة.
تأشير المهمة إقرار منك بإتمامها، وليس تصحيحًا آليًا للكود. يُحفظ تقدمك في حسابك.
اختبر فهمك.
ووصلها للإتقان.
كل سؤال خطوة لقدّام. اختار، اكتب كود، وشوف نتيجتك فورًا.
أكمل المهام، واجمع كل الإجابات الصحيحة. أقل من 100%؟ راجع وأعد المحاولة.
الأسئلة متاحة للاطلاع. سجّل الدخول للتفاعل وحفظ تقدمك.