وصفات حلوى SameSite

سيتم تغيير سلوك Chrome وFirefox وEdge وغيره من التطبيقات الأخرى بما يتماشى مع اقتراح مجموعة مهندسي شبكة الإنترنت (IETF) ملفات تعريف الارتباط بشكل تزايدي بحيث:

  • سيتمّ التعامل مع ملفات تعريف الارتباط التي لا تحتوي على السمة SameSite على أنّها SameSite=Lax، ما يعني أنّ السلوك التلقائي هو حصر ملفات تعريف الارتباط بسياقات الطرف الأول فقط.
  • يجب أن تحدد ملفات تعريف الارتباط المخصّصة للاستخدام على عدة مواقع إلكترونية السمة SameSite=None; Secure لتفعيل التضمين في سياق الجهات الخارجية.

هذه الميزة هي السلوك التلقائي من الإصدار 84 والإصدارات الأحدث من Chrome. إذا لم يسبق لك فعل ذلك، عليك تعديل سمات ملفات تعريف الارتباط التابعة لجهات خارجية حتى لا يتم حظرها في المستقبل.

التوافق مع المتصفحات

راجِع قسم توافُق المتصفّح في صفحة Set-Cookie في MDN.

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

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

المحتوى ضمن <iframe>

إنّ المحتوى من موقع إلكتروني مختلف معروض في <iframe> يقع في سياق تابع لجهة خارجية. في ما يلي حالات الاستخدام العادية:

  • المحتوى المضمَّن الذي تمت مشاركته من مواقع إلكترونية أخرى، مثل الفيديوهات والخرائط وعيّنات التعليمات البرمجية ومشاركات الشبكات الاجتماعية.
  • تطبيقات مصغّرة من الخدمات الخارجية مثل وظائف الدفعات والتقاويم والحجز والحجوزات.
  • التطبيقات المصغّرة، مثل الأزرار الاجتماعية أو خدمات مكافحة الاحتيال التي تكون أقل وضوحًا <iframes>.

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

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

بالإضافة إلى ذلك، بما أنّ الويب قابل للإنشاء بطبيعتها، يتم استخدام <iframes> لتضمين المحتوى الذي يتم عرضه أيضًا في سياق المستوى الأعلى أو سياق الطرف الأول. سيتم اعتبار أي ملفات تعريف ارتباط يستخدمها هذا الموقع الإلكتروني على أنها ملفات تعريف ارتباط تابعة لجهات خارجية عند عرض الموقع الإلكتروني داخل الإطار. إذا كنت تنشئ مواقع إلكترونية تريد أن يضمِّنها الآخرون بسهولة مع الاعتماد أيضًا على ملفات تعريف الارتباط لتعمل، عليك التأكّد من وضع علامة على تلك المواقع للاستخدام على عدة مواقع إلكترونية أو التأكّد من أنّه يمكنك الاحتفاظ بنسخة احتياطية منها بدون استخدام تلك المواقع الإلكترونية.

الطلبات "غير الآمنة" على المواقع الإلكترونية

قد تبدو كلمة "غير آمن" تثير قلق بعض الشيء في هذه الحالة، إلا أنّ ذلك يشير إلى أي طلب قد يُقصد به تغيير الحالة. على الويب، في الأساس، طلبات POST. سيتم إرسال ملفات تعريف الارتباط التي تم وضع علامة SameSite=Lax عليها في عمليات التنقّل الآمنة ذات المستوى الأعلى، مثل النقر على رابط للانتقال إلى موقع إلكتروني آخر. مع ذلك، لا يتضمّن محتوى مثل إرسال <form> عبر POST إلى موقع إلكتروني مختلف ملفات تعريف الارتباط.

مخطّط بياني لطلب الانتقال من صفحة إلى أخرى
إذا كان الطلب الوارد يستخدم طريقة "آمنة"، سيتم إرسال ملفات تعريف الارتباط.

يُستخدم هذا النمط للمواقع التي قد تعيد توجيه المستخدم إلى خدمة عن بُعد لإجراء بعض العمليات قبل العودة إلى الصفحة السابقة، مثل إعادة التوجيه إلى موفّر هوية تابع لجهة خارجية. قبل أن يغادر المستخدم الموقع الإلكتروني، يتم ضبط ملف تعريف ارتباط يحتوي على رمز مميّز للاستخدام مرة واحدة، مع توقّع إمكانية التحقّق من هذا الرمز المميّز عند الطلب المكرّر للحدّ من هجمات تزوير الطلبات المتبادلة على المواقع الإلكترونية (CSRF). إذا وصل طلب الإرجاع هذا من خلال POST، سيكون من الضروري وضع علامة SameSite=None; Secure على ملفات تعريف الارتباط.

الموارد عن بُعد

قد يكون أي مورد بعيد على الصفحة يعتمد على ملفات تعريف الارتباط لإرسالها مع طلب، من علامات <img> وعلامات <script> وغيرها. تشمل حالات الاستخدام الشائعة وحدات بكسل التتبع وتخصيص المحتوى.

ينطبق ذلك أيضًا على الطلبات التي بدأت من خلال JavaScript من fetch أو XMLHttpRequest. إذا تم استدعاء fetch() باستخدام credentials: 'include' ، يُعدّ هذا مؤشرًا جيدًا على أنّ هذه الطلبات قد تكون متوقّعة. بالنسبة إلى XMLHttpRequest، عليك البحث عن نُسخ افتراضية من السمة withCredentials التي يتم ضبطها على true. وهذا مؤشر جيد على احتمال توقُّع استخدام ملفات تعريف الارتباط لهذه الطلبات. ويجب وضع علامة مناسبة على ملفات تعريف الارتباط هذه لتضمينها في طلبات مواقع إلكترونية متعددة.

المحتوى ضمن WebView

يعتمد WebView في تطبيق خاص بالنظام الأساسي على متصفّح وستحتاج إلى اختبار ما إذا كانت تنطبق القيود أو المشاكل نفسها. في نظام Android، إذا كان WebView مشغّلاً من خلال Chrome، لن يتم تطبيق الإعدادات التلقائية الجديدة على الفور مع Chrome 84. إلا أن الغرض من تطبيقها هو تطبيقها في المستقبل، لذا لا يزال يتعين عليك اختبارها والاستعداد لها. بالإضافة إلى ذلك، يسمح Android لتطبيقاته الخاصة بالنظام الأساسي بضبط ملفات تعريف الارتباط مباشرةً عبر واجهة برمجة تطبيقات CookieManager. وكما هي الحال مع ملفات تعريف الارتباط التي تم ضبطها عبر العناوين أو JavaScript، ننصحك بتضمين SameSite=None; Secure إذا كانت مخصَّصة للاستخدام على عدة مواقع إلكترونية.

كيفية تطبيق SameSite اليوم

بالنسبة إلى ملفات تعريف الارتباط التي لا تحتاج إليها إلا في سياق الطرف الأول، من الأفضل تصنيفها على أنّها SameSite=Lax أو SameSite=Strict، وذلك وفقًا لاحتياجاتك. يمكنك أيضًا اختيار عدم اتخاذ أي إجراء والسماح فقط للمتصفح بفرض الإعدادات التلقائية، ولكن هذا يصاحبه مخاطرة حدوث سلوك غير متسق عبر المتصفحات وتحذيرات وحدة التحكّم المحتملة لكل ملف تعريف ارتباط.

Set-Cookie: first_party_var=value; SameSite=Lax

بالنسبة إلى ملفات تعريف الارتباط المطلوبة في سياق تابع لجهة خارجية، عليك التأكّد من وضع علامة SameSite=None; Secure عليها. تجدر الإشارة إلى أنّك تحتاج إلى استخدام السمتَين معًا. في حال تحديد None بدون Secure، سيتم رفض ملف تعريف الارتباط. ومع ذلك، هناك بعض الاختلافات غير المتوافقة بين المستخدمين في عمليات تنفيذ المتصفّح، لذا قد تحتاج إلى استخدام بعض استراتيجيات التخفيف الموضّحة في مقالة التعامل مع البرامج غير المتوافقة أدناه.

Set-Cookie: third_party_var=value; SameSite=None; Secure

التعامل مع البرامج غير المتوافقة

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

الخيار الأول هو تعيين كل من ملفات تعريف الارتباط الجديدة والقديمة:

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

وستضبط المتصفّحات التي تطبّق السلوك الأحدث ملف تعريف الارتباط بالقيمة SameSite، بينما قد تتجاهله المتصفّحات الأخرى أو تضبطه بشكل غير صحيح. في المقابل، ستضبط هذه المتصفّحات نفس ملفّ تعريف الارتباط "3pcookie-legacy". عند معالجة ملفات تعريف الارتباط المضمّنة، يجب أن يتحقّق الموقع الإلكتروني أولاً من توفُّر ملف تعريف الارتباط ذي النمط الجديد، وفي حال عدم العثور عليه، ينتقل إلى ملف تعريف الارتباط القديم.

يوضح المثال أدناه كيفية إجراء ذلك في Node.js، مع الاستفادة من إطار عمل Express والبرمجيات الوسيطة cookie-parser الخاصة به.

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());

app.get('/set', (req, res) => {
  // Set the new style cookie
  res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
  // And set the same value in the legacy cookie
  res.cookie('3pcookie-legacy', 'value', { secure: true });
  res.end();
});

app.get('/', (req, res) => {
  let cookieVal = null;

  if (req.cookies['3pcookie']) {
    // check the new style cookie first
    cookieVal = req.cookies['3pcookie'];
  } else if (req.cookies['3pcookie-legacy']) {
    // otherwise fall back to the legacy cookie
    cookieVal = req.cookies['3pcookie-legacy'];
  }

  res.end();
});

app.listen(process.env.PORT);

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

يمكنك بدلاً من ذلك اختيار رصد العميل من خلال سلسلة وكيل المستخدم عند إرسال العنوان Set-Cookie. راجِع قائمة البرامج غير المتوافقة ثم استخدِم المكتبة المناسبة لنظامك الأساسي، على سبيل المثال مكتبة ua-parser-js على Node.js. ننصح بالعثور على مكتبة للتعامل مع اكتشاف وكيل المستخدم، لأنك على الأرجح لا تريد كتابة تلك التعبيرات العادية بنفسك.

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

إتاحة "SameSite=None" في اللغات والمكتبات وأُطر العمل

تتيح معظم اللغات والمكتبات استخدام سمة SameSite لملفات تعريف الارتباط، إلا أنّ إضافة SameSite=None لا تزال جديدة نسبيًا، ما يعني أنّك قد تحتاج إلى العمل على اتّباع بعض الإجراءات العادية في الوقت الحالي. تم توثيق ذلك في SameSite أمثلة repo على GitHub.

الحصول على المساعدة

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