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

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

Maud Nalpas
Maud Nalpas

ملخّص

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

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

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

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

طلب HTTP يتضمن عنوان "المُحيل".

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

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

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

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

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

عناوين URL التي تحتوي على مسارات تم ربطها بمخاطر مختلفة متعلقة بالخصوصية والأمان

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

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

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

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

يمكنك اختيار واحدة من ثماني سياسات. وفقًا للسياسة، يمكن أن تكون البيانات المتاحة من عنوان Refererdocument.referrer) على النحو التالي:

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

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

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

سياسات المُحيل المختلفة وسلوكها استنادًا إلى سياق الأمان والسياق المشترك المصدر.

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

ملاحظات:

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

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

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

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

المتصفح Referrer-Policy / السلوك التلقائي
Chrome والقيمة التلقائية هي strict-origin-when-cross-origin.
Firefox والقيمة التلقائية هي strict-origin-when-cross-origin.
بدءًا من الإصدار 93، بالنسبة إلى مستخدمي ميزة "الحماية الصارمة من التتبُّع" و"التصفّح الخاص"، يتم تجاهل سياستَي المُحيل الأقل تقييدًا no-referrer-when-downgrade وorigin-when-cross-origin وunsafe-url للطلبات من عدة مواقع إلكترونية، ما يعني أنّه يتم دائمًا قطع المُحيل عند الطلب من مواقع إلكترونية متعددة، بغض النظر عن سياسة الموقع الإلكتروني.
Edge والقيمة التلقائية هي strict-origin-when-cross-origin.
برنامج المتصفح Safari وتتشابه هذه السياسة التلقائية مع strict-origin-when-cross-origin، مع بعض التفاصيل. لمزيد من التفاصيل، يُرجى الاطّلاع على مقالة منع تتبُّع ميزة "منع التتبُّع".

إعداد سياسة المُحيل: أفضل الممارسات

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

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

يتم عرض كل من عنوان 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 الذي تم إرساله.

لقطة شاشة للوحة الشبكة في &quot;أدوات مطوري البرامج في Chrome&quot; تُظهر سياسة المُحيل وسياسة المُحيل
"أدوات مطوري البرامج في Chrome"، لوحة الشبكة التي تم اختيار طلب عليها.

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

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

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

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

  • تكون السياسات التلقائية للمتصفِّح no-referrer-when-downgrade أو 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 الكامل مطلقًا، حتى مع الطلبات ذات المصدر نفسه، لذلك إذا كنت بحاجة إلى ذلك، الخيار 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 التي تتلقّاها.

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

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

بدائل Referer

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

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

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

إذا كنت بحاجة إلى المصدر (https://site-one.example) فقط:

  • وإذا كنت تستخدم المُحيل في نص برمجي لديه إذن وصول عالي المستوى إلى الصفحة، يمكنك استخدام 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 أو كانت متوفّرة وتم التحقّق من المصدر الأساسي Referer بنجاح: يمكنك الانتقال إلى طريقة إثبات الملكية الأخرى الأكثر موثوقية (انظر أدناه).

ما هي طريقة التحقّق الأكثر موثوقية؟

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

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

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

الخلاصة

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

لمعرفة المزيد من المعلومات عن الأساليب المختلفة لحماية المستخدمين، يمكنك الاطّلاع على مجموعة الأمان والسلامة من web.dev.

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

المراجِع