أفضل الممارسات المتعلقة بسياسة المُحيلين والمحيلين

توضّح هذه الصفحة بعض أفضل الممارسات لإعداد سياسة المُحيل واستخدام المُحيل في الطلبات الواردة.

ملخّص

• يؤدي تسرُّب المعلومات غير المتوقَّع من مصادر متعددة إلى إلحاق الضرر بخصوصية مستخدمي الويب. ويمكن أن تساعدك سياسة المُحيل الوقائية.
• ننصحك بضبط سياسة المُحيل strict-origin-when-cross-origin. تحافظ هذه الطريقة على معظم فائدة المُحيل، مع الحدّ من خطر تسرُّب البيانات من مصادر متعددة.
• لا تستخدِم المُحيلين للحماية من تزوير طلبات جميع المواقع الإلكترونية (CSRF). استخدِم رموز CSRF المميزة بدلاً من ذلك، والعناوين الأخرى كطبقة أمان إضافية.

سياسة المُحيل والمحيل 101

يمكن أن تتضمّن طلبات HTTP عنوان Referer اختياري، ما يشير إلى عنوان URL المصدر أو صفحة الويب الذي تم تقديم الطلب منه. يحدّد عنوان Referrer-Policy البيانات المتاحة في عنوان Referer.

في المثال التالي، يشتمل عنوان Referer على عنوان URL الكامل للصفحة على site-one التي تم تقديم الطلب منها.

قد يتوفّر عنوان Referer في أنواع مختلفة من الطلبات:

• طلبات التنقّل، عندما ينقر أحد المستخدمين على رابط.
• طلبات الموارد الفرعية، عندما يطلب المتصفح الصور وإطارات iframe والنصوص البرمجية والموارد الأخرى التي تحتاجها الصفحة.

بالنسبة إلى عمليات التنقّل وإطارات iframe، يمكنك أيضًا الوصول إلى هذه البيانات من خلال JavaScript باستخدام document.referrer.

يمكنك تعلم الكثير من قيم Referer. على سبيل المثال، قد تستخدمها خدمة إحصاءات لتحديد أنّ% 50 من زوّار site-two.example جاءوا من social-network.example. أمّا إذا تم إرسال عنوان URL الكامل، بما في ذلك المسار وسلسلة طلب البحث في Referer على مستوى المصادر، قد يؤدي ذلك إلى تعريض خصوصية المستخدم للخطر وإنشاء مخاطر أمنية:

تحتوي عناوين URL من رقم 1 إلى رقم 5 على معلومات خاصة، وقد تحتوي أحيانًا على معلومات حساسة أو تحدد الهوية. قد يؤدي تسرُّب هذه البيانات بشكل صامت عبر المصادر إلى تعريض خصوصية مستخدمي الويب للخطر.

عنوان URL رقم 6 هو عنوان URL للإمكانات. إذا تلقّى أي شخص غير المستخدم المقصود هذه الرسالة، يمكن لجهة ضارة التحكم في حساب هذا المستخدم.

لتحديد بيانات المُحيل التي تتم إتاحتها للطلبات من موقعك الإلكتروني، يمكنك ضبط سياسة المُحيل.

ما هي السياسات المتوفرة وما أوجه اختلافها؟

يمكنك اختيار واحدة من ثماني سياسات. استنادًا إلى السياسة، يمكن أن تكون البيانات المتاحة من عنوان Referer (وdocument.referrer) على النحو التالي:

• ما مِن بيانات (لا يتوفّر عنوان Referer)
• المصدر فقط
• عنوان URL الكامل: المصدر والمسار وسلسلة طلب البحث

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

يعرض الجدول التالي كيفية تقييد سياسات المُحيل لبيانات عناوين URL المتاحة من عنوان المُحيل وdocument.referrer:

نطاق السياسة	اسم السياسة	المُحيل: لا توجد بيانات	المُحيل: المصدر فقط	المُحيل: عنوان URL الكامل
لا يأخذ في الاعتبار سياق الطلب	no-referrer	علامة اختيار
	origin		علامة اختيار
	unsafe-url			علامة اختيار
يركز على الأمان	strict-origin	الطلب من HTTPS إلى HTTP	الطلب من HTTPS إلى HTTPS أو HTTP إلى HTTP
	no-referrer-when-downgrade	الطلب من HTTPS إلى HTTP		الطلب من HTTPS إلى HTTPS أو HTTP إلى HTTP
تركّز على الخصوصية	origin-when-cross-origin		طلب مشترك المصدر	طلب من المصدر نفسه
	same-origin	طلب مشترك المصدر		طلب من المصدر نفسه
التركيز على الخصوصية والأمان	strict-origin-when-cross-origin	الطلب من HTTPS إلى HTTP	طلب متعدد المصادر من HTTPS إلى HTTPS أو من HTTP إلى HTTP	طلب من المصدر نفسه

توفر خدمة MDN قائمة كاملة من السياسات وأمثلة السلوك.

في ما يلي بعض الأمور التي يجب مراعاتها عند ضبط سياسة المُحيل:

• وتراعي جميع السياسات التي تأخذ المخطَّط (HTTPS في مقابل HTTP) (strict-origin وno-referrer-when-downgrade وstrict-origin-when-cross-origin) الطلبات من مصدر HTTP إلى مصدر HTTP آخر بالطريقة نفسها التي تتعامل بها الطلبات من مصدر HTTPS إلى مصدر HTTPS آخر، على الرغم من أنّ بروتوكول HTTP يكون أقل أمانًا. ويرجع ذلك إلى أنّ ما يهمّ بالنسبة إلى هذه السياسات هو ما إذا كان الرجوع إلى إصدار سابق من الأمان قد يكشف عن بيانات من مصدر مشفر إلى مصدر غير مشفّر، كما هو الحال في طلبات HTTPS → HTTP. يكون طلب HTTP ← HTTP غير مشفّر تمامًا، وبالتالي لا توجد إمكانية الرجوع إلى إصدار سابق.
• إذا كان الطلب من المصدر نفسه، يعني ذلك أنّ المخطط (HTTPS أو HTTP) هو نفسه، وبالتالي لا يتم خفض مستوى الأمان.

سياسات المُحيل التلقائية في المتصفحات

اعتبارًا من تشرين الأول (أكتوبر) 2021

إذا لم يتم ضبط سياسة مُحيل، يستخدم المتصفِّح سياسته التلقائية.

أفضل الممارسات لضبط سياسة المُحيل

هناك طرق مختلفة لضبط سياسات المُحيل لموقعك الإلكتروني:

• على شكل عنوان HTTP
• ضمن HTML
• من JavaScript على أساس كل طلب

يمكنك ضبط سياسات مختلفة لصفحات أو طلبات أو عناصر مختلفة.

يتم عرض كل من عنوان HTTP والعنصر الوصفية على مستوى الصفحة. ترتيب الأولوية لتحديد السياسة الفعالة لأحد العناصر هو ما يلي:

1. سياسة على مستوى العنصر
2. سياسة على مستوى الصفحة
3. الإعداد التلقائي للمتصفّح

مثال:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

تم طلب الصورة باستخدام سياسة no-referrer-when-downgrade، وتتّبع جميع طلبات الموارد الفرعية الأخرى من هذه الصفحة سياسة strict-origin-when-cross-origin.

كيف يمكن الاطّلاع على سياسة المُحيل؟

يكون securityheaders.com مفيدًا لتحديد السياسة التي يستخدمها موقع إلكتروني أو صفحة معيّنة.

يمكنك أيضًا استخدام أدوات المطوّرين في Chrome أو Edge أو Firefox للاطّلاع على سياسة المُحيل المستخدَمة لطلب محدَّد. في وقت كتابة هذا التقرير، لا يعرض متصفّح Safari العنوان Referrer-Policy، لكنّه يعرض محتوى Referer الذي تم إرساله.

ما السياسة التي يجب أن تحددها لموقعك الإلكتروني؟

ننصحك بشدة بتحديد سياسة لتحسين الخصوصية، مثل strict-origin-when-cross-origin (أو أكثر صرامة).

لمَ يتم الحديث "بصراحة"؟

في حال عدم ضبط سياسة مُحيل، سيتم استخدام السياسة التلقائية للمتصفّح، وفي كثير من الأحيان تؤجّل المواقع الإلكترونية إلى الإعدادات التلقائية للمتصفّح. وهذا ليس مثاليًا للأسباب التالية:

• تختلف السياسات التلقائية الخاصة بالمتصفّحات المختلفة، لذا إذا اعتمدت على الإعدادات التلقائية للمتصفّح، لن يعمل موقعك الإلكتروني على نحو متوقَّع على مستوى المتصفحات.
• تستخدم المتصفّحات إعدادات تلقائية أكثر صرامة، مثل strict-origin-when-cross-origin، وآليات مثل اقتطاع المُحيل للطلبات من مصادر متعددة. يمنحك تفعيل سياسة تحسين الخصوصية بشكل صريح قبل تغيير الإعدادات التلقائية للمتصفّح إمكانية التحكّم ويساعدك في إجراء الاختبارات على النحو الذي تراه مناسبًا.

ما سبب استخدام strict-origin-when-cross-origin (أو أكثر صرامة)؟

أنت بحاجة إلى سياسة آمنة وتحسّن الخصوصية ومفيدة. يعتمد ما تعنيه كلمة "مفيد" على ما تريده من المُحيل:

• آمن: إذا كان موقعك الإلكتروني يستخدم بروتوكول HTTPS (وإذا لم يكن مفعلاً، اجعله أولوية)، يعني ذلك أنّك لا تريد تسرّب عناوين URL الخاصة بموقعك الإلكتروني في طلبات ليست تستخدم HTTPS. ونظرًا لأن أي شخص على الشبكة يمكنه رؤية هذه الأشياء، فإن التسريبات سوف تعرض المستخدمين لهجمات الوسيط. تساعد السياسات no-referrer-when-downgrade وstrict-origin-when-cross-origin وno-referrer وstrict-origin في حل هذه المشكلة.
• تحسين الخصوصية: بالنسبة إلى طلب من مصادر متعددة، يشارك no-referrer-when-downgrade عنوان URL الكامل، ما قد يتسبب في حدوث مشاكل في الخصوصية. يتشارك strict-origin-when-cross-origin وstrict-origin في الأصل فقط، ولا يشارك no-referrer أي شيء على الإطلاق. يتيح لك ذلك استخدام strict-origin-when-cross-origin وstrict-origin وno-referrer كخيارات لتحسين الخصوصية.
• الإفادة: لا يشارك no-referrer وstrict-origin عنوان URL الكامل مطلقًا، حتى في الطلبات ذات المصدر نفسه. إذا كنت بحاجة إلى عنوان URL الكامل، ننصحك باستخدام strict-origin-when-cross-origin.

يعني كل ذلك أنّ strict-origin-when-cross-origin هو خيار معقول بشكل عام.

مثال: ضبط سياسة strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

أو من جهة الخادم، على سبيل المثال في Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

ماذا لو كانت السمة strict-origin-when-cross-origin (أو الأكثر صرامة) لا تناسب جميع حالات استخدامك.

في هذه الحالة، اتّبِع نهجًا تقدّميًا من خلال ضبط سياسة وقائية، مثل "strict-origin-when-cross-origin"، لموقعك الإلكتروني، ووضع سياسة أكثر منحًا للأذونات في ما يتعلّق بطلبات محددة أو عناصر HTML.

مثال: سياسة على مستوى العنصر

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

قد يضع Safari أو WebKit حدًا أقصى على document.referrer أو عنوان Referer لطلبات المواقع الإلكترونية المتعدّدة. يُرجى الاطّلاع على التفاصيل.

مثال: سياسة على مستوى الطلب

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

ما الذي يجب مراعاته أيضًا؟

يجب أن تعتمد سياستك على موقعك الإلكتروني وحالات الاستخدام التي تحدّدها أنت وفريقك وشركتك. إذا كانت بعض عناوين URL تحتوي على بيانات تعريفية أو حساسة، يمكنك وضع سياسة وقائية.

أفضل الممارسات المتعلّقة بالطلبات الواردة

في ما يلي بعض الإرشادات حول الإجراءات التي يجب اتّخاذها إذا كان موقعك الإلكتروني يستخدم عنوان URL المُحيل للطلبات الواردة.

حماية بيانات المستخدمين

قد يحتوي Referer على بيانات خاصة أو شخصية أو تحدّد الهوية، لذا احرص على التعامل معها على هذا الأساس.

يمكن للمُحيلين الواردين تغيير {referer-can-change}

هناك بعض القيود المفروضة على استخدام المُحيل من الطلبات الواردة من مصادر متعددة:

• إذا لم تكن لديك إمكانية التحكم في تنفيذ باعث الطلب، لن تتمكّن من وضع افتراضات بشأن عنوان Referer (وdocument.referrer) الذي تلقّاه. قد يقرّر منشئ الطلب في أي وقت التبديل إلى سياسة no-referrer أو بشكل عام إلى تطبيق سياسة أكثر صرامة من السياسة التي استخدمها في السابق. يعني ذلك أنّك تتلقّى بيانات أقل من "Referer" مقارنةً بالفترة السابقة.
• تستخدم المتصفّحات بشكل متزايد سياسة المُحيل strict-origin-when-cross-origin بشكل تلقائي. وهذا يعني أنّك قد تتلقّى الآن المصدر فقط في الطلبات الواردة من مصادر متعددة، بدلاً من عنوان URL المُحيل الكامل، وذلك في حال لم يتم تحديد سياسة للموقع الإلكتروني للمرسِل.
• قد تُغيّر المتصفّحات الطريقة التي تدير بها Referer. على سبيل المثال، قد يقرّر بعض مطوّري المتصفِّحات دائمًا قطع المُحيلين إلى المصادر في طلبات الموارد الفرعية المتعددة المصادر، وذلك لحماية خصوصية المستخدم.
• قد يحتوي عنوان Referer (وdocument.referrer) على بيانات أكثر مما تحتاج إليه. على سبيل المثال، قد يحتوي الطلب على عنوان URL كامل إذا كنت تريد معرفة ما إذا كان الطلب من مصادر متعددة.

بدائل Referer

قد تحتاج إلى التفكير في بدائل في الحالات التالية:

• من الميزات الأساسية لموقعك الإلكتروني استخدام عنوان URL المُحيل للطلبات الواردة من مصادر متعددة.
• لم يعُد موقعك الإلكتروني يتلقّى الجزء من عنوان URL المُحيل الذي يحتاجه في طلب من مصادر متعددة. يحدث ذلك عندما يغيِّر مصدر الطلب سياسته أو عندما لا يتم ضبط سياسة ويتم تغيير السياسة التلقائية للمتصفِّح (كما هو الحال في Chrome 85).

لتحديد البدائل، عليك أولاً تحليل جزء المُحيل الذي تستخدمه.

إذا كنت بحاجة إلى المصدر فقط

• وإذا كنت تستخدم المُحيل في نص برمجي لديه إذن وصول عالي المستوى إلى الصفحة، يمكنك استخدام window.location.origin كبديل.
• في حال توفّر عناوين مثل Origin وSec-Fetch-Site، تمنحك Origin أو تصف ما إذا كان الطلب من مصادر متعددة، وقد يكون هذا ما تحتاج إليه بالضبط.

إذا كنت بحاجة إلى عناصر أخرى لعنوان URL (المسار، معلمات طلب البحث...)

• قد تعالج معلَمات الطلب حالة الاستخدام، ما يوفّر عليك عناء تحليل المُحيل.
• إذا كنت تستخدم المُحيل في نص برمجي لديه إذن وصول عالي المستوى إلى الصفحة، قد يعمل window.location.pathname كبديل. يمكنك استخراج قسم المسار فقط لعنوان URL وتمريره كوسيطة، كي لا يتم نقل أي معلومات من المحتمل أن تكون حساسة في معلمات عنوان URL.

إذا لم تتمكن من استخدام البدائل التالية:

• تحقَّق مما إذا كان بإمكانك تغيير أنظمتك لتتوقّع أن توفّر ميزة إصدار الطلبات (على سبيل المثال site-one.example) المعلومات التي تحتاجها بشكل صريح بطريقة معيّنة.
  • الإيجابي: أكثر وضوحًا، ويحافظ على الخصوصية بشكل أكبر لمستخدمي site-one.example، وحماية أكبر للمستقبل
  • السلبيات: المزيد من العمل من جانبك أو من أجل مستخدمي نظامك.
• تأكّد ممّا إذا كان الموقع الإلكتروني الذي يرسل الطلبات قد يوافق على تعيين عنصر مُحيل لكل عنصر أو لكل طلب no-referrer-when-downgrade.
  • السلبيات: من المحتمل أن تكون عملية الحفاظ على الخصوصية أقل لمستخدمي site-one.example، ومن المحتمل ألا تكون متوافقة مع جميع المتصفحات.

الحماية من التزوير على مواقع إلكترونية متعددة (CSRF)

يمكن أن يقرّر انبعاث الطلب دائمًا عدم إرسال المُحيل من خلال ضبط سياسة no-referrer، وقد ينتحل مستخدم ضار المُحيل.

استخدِم رموز CSRF كالحماية الأساسية. للحصول على حماية إضافية، استخدِم SameSite، وبدلاً من Referer، استخدِم عناوين مثل Origin (المتوفّرة في طلبات POST وCORS) وSec-Fetch-Site إذا كانت متاحة.

السجلّ وتصحيح الأخطاء

يُرجى الحرص على حماية بيانات المستخدمين الشخصية أو الحسّاسة التي قد تكون في Referer.

إذا كنت تستخدم المصدر فقط، تحقَّق مما إذا كان بإمكانك استخدام العنوان Origin كبديل. قد يمنحك هذا المعلومات التي تحتاجها لتصحيح الأخطاء في الأغراض بطريقة أبسط ودون الحاجة إلى تحليل المُحيل.

الدفع

قد يعتمد مقدّمو خدمات الدفع على العنوان Referer للطلبات الواردة في عمليات فحص الأمان.

مثال:

• ينقر المستخدم على زر شراء في online-shop.example/cart/checkout.
• يعيد online-shop.example التوجيه إلى payment-provider.example لإدارة المعاملة.
• يتحقّق payment-provider.example من Referer لهذا الطلب بمقارنتها بقائمة من قيم Referer المسموح بها التي أعدّها التجّار. وإذا لم يطابق أي إدخال في القائمة، سيتم رفض الطلب من خلال payment-provider.example. في حال عدم التطابق، يمكن للمستخدم المتابعة إلى المعاملة.

أفضل الممارسات لعمليات فحص الأمان لتدفق الدفع

بصفتك مقدّم خدمات دفع، يمكنك استخدام Referer كإجراء تحقُّق أساسي ضد بعض الهجمات. مع ذلك، لا يشكّل عنوان Referer في حد ذاته أساسًا موثوقًا لإجراء عملية تحقّق. يمكن للموقع الإلكتروني الذي يقدّم الطلب، سواء كان تاجرًا شرعيًا أم لا، ضبط سياسة no-referrer تجعل معلومات Referer غير متوفّرة لمقدّم الدفع.

إنّ الاطّلاع على Referer قد يساعد مقدّمي خدمات الدفع في رصد المهاجمين الذين لم يضعوا سياسة no-referrer. في حال استخدام "Referer" كأول تحقُّق:

• لا تتوقع وجود Referer دائمًا. إذا كانت موجودة، تحقق منها مقابل الحد الأدنى من البيانات التي يمكن تضمينها، وهي الأصل.
  • عند إعداد قائمة قيم Referer المسموح بها، احرِص على تضمين الأصل وليس فقط أي مسار.
  • على سبيل المثال، يجب أن تكون قيم Referer المسموح بها للسمة online-shop.example online-shop.example وليس online-shop.example/cart/checkout. إذا كنت تتوقّع عدم استخدام Referer على الإطلاق أو قيمة Referer تمثّل أصل الموقع الإلكتروني المطلوب فقط، فإنك تمنع الأخطاء التي قد تنتج عن وضع افتراضات حول Referrer-Policy لدى التاجر.
• إذا لم تتوفّر سمة Referer أو إذا كانت متوفّرة وتم التحقّق من أصل Referer الأساسي بنجاح، يمكنك الانتقال إلى طريقة أخرى أكثر موثوقية لإثبات الهوية.

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

ماذا يحدث Referer إذا كان موقع إلكتروني لتاجر يستخدم بروتوكول HTTP لا يتضمن سياسة مُحيلة يُعيد التوجيه إلى مقدّم خدمة الدفع الذي يستخدم بروتوكول HTTPS؟

لا يظهر Referer في الطلب المُرسَل إلى مقدّم خدمة الدفع HTTPS، لأنّ معظم المتصفحات تستخدم strict-origin-when-cross-origin أو no-referrer-when-downgrade تلقائيًا عندما لا يتم ضبط سياسة للموقع الإلكتروني. لن يؤدّي تغيير Chrome إلى سياسة تلقائية جديدة إلى تغيير هذا السلوك.

الخلاصة

تُعد سياسة المُحيل الوقائية طريقة رائعة لمنح المستخدمين مزيدًا من الخصوصية.

لمعرفة مزيد من المعلومات حول الأساليب المختلفة لحماية المستخدمين، راجع مجموعة الأمان والسلامة

المراجع

• فهم "الموقع الإلكتروني نفسه" و "المصدر نفسه"
• عنوان أمان جديد: سياسة المُحيل (2017)
• سياسة المُحيل بشأن MDN
• عنوان المرجع: مخاوف تتعلق بالخصوصية والأمان بشأن MDN
• تغيير Chrome: غرض Blink التنفيذ
• تغيير في Chrome: هدف Blink للشحن
• تغيير Chrome: إدخال الحالة
• تغيير إصدار Chrome: مشاركة مدونة إصدار تجريبي 85
• يقطع المُحيل سلسلة GitHub: الإجراءات التي تتخذها المتصفحات المختلفة
• مواصفات سياسة المُحيل

نقدّر الكثير من المراجعين على مساهماتهم وملاحظاتهم، وبالأخص "كوستوبا غوفيند" و"ديفيد فان كليف" و"مايك ويست" و"سام دوتون" و"روان ميروود" و"جيكسيك" و"كايس باسك".