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

Maud Nalpas

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

ملخّص

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

مقدمة عن Referer وReferrer-Policy

يمكن أن تتضمّن طلبات 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 المتاحة من عنوان Referer وdocument.referrer:

تقدّم شبكة مطوّري Mozilla قائمة كاملة بالسياسات وأمثلة على السلوك.

في ما يلي بعض النقاط التي يجب الانتباه إليها عند ضبط سياسة الإحالة:

• تتعامل جميع السياسات التي تأخذ المخطط (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 وعنصر meta هما على مستوى الصفحة. في ما يلي ترتيب الأولوية لتحديد السياسة السارية على أحد العناصر:

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، وتستخدم آليات، مثل اقتطاع عنوان URL الخاص بالمُحيل، لطلبات المصادر الخارجية. يمنحك الموافقة الصريحة على سياسة تعزّز الخصوصية قبل تغيير الإعدادات التلقائية للمتصفّح إمكانية التحكّم ويساعدك في إجراء الاختبارات بالطريقة التي تناسبك.

لماذا 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}

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

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

بدائل لـ "Referer"

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

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

لتحديد البدائل، عليك أولاً تحليل الجزء الذي تستخدمه من صفحة الإحالة.

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

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

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

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

إذا لم تتمكّن من استخدام هذه البدائل، اتّبِع الخطوات التالية:

• تحقَّق مما إذا كان بإمكانك تغيير أنظمتك لتتوقّع أن يضبط مصدر الطلب (على سبيل المثال، site-one.example) المعلومات التي تحتاج إليها بشكل صريح في نوع من الإعدادات.
  • الإيجابيات: أكثر وضوحًا، ويحافظ على خصوصية مستخدمي site-one.example بشكل أكبر، وأكثر توافقًا مع الاحتياجات المستقبلية.
  • العيوب: قد يتطلّب ذلك المزيد من العمل من جانبك أو من جانب مستخدمي نظامك.
• تحقَّق ممّا إذا كان الموقع الإلكتروني الذي يرسل الطلبات قد يوافق على ضبط سياسة Referrer-Policy لكل عنصر أو لكل طلب على القيمة 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، يمكنك الانتقال إلى طريقة أخرى أكثر موثوقية لإثبات الملكية.

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

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

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

الخاتمة

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

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

الموارد

• التعرّف على مفهومَي "الموقع الإلكتروني نفسه" و "المصدر نفسه"
• عنوان أمان جديد: سياسة الإحالة (2017)
• Referrer-Policy على شبكة مطوّلي Mozilla
• عنوان Referer: مخاوف بشأن الخصوصية والأمان على شبكة مطوّلي Mozilla
• تغيير في Chrome: نية Blink للتنفيذ
• تغيير في Chrome: نية طرح Blink
• تغيير في Chrome: إدخال الحالة
• تغيير في Chrome: الإصدار التجريبي 85 مشاركة على المدونة
• سلسلة محادثات على GitHub حول اقتطاع عنوان URL الخاص بالمُحيل: ما تفعله المتصفّحات المختلفة
• مواصفات Referrer-Policy

نتوجّه بالشكر إلى جميع المراجعين على مساهماتهم وملاحظاتهم، وخاصةً Kaustubha Govind وDavid Van Cleve وMike West وSam Dutton وRowan Merewood وJxck وKayce Basques.