الخلاصة

  • صدر RFC 10017 في أغسطس 2026 بوصفه أفضل ممارسة حالية لدى IETF. وهو يوصي بقوة باستخدام Backend for Frontend في تطبيقات الأعمال والتطبيقات الحساسة وتلك التي تعالج بيانات شخصية، لأن رموز OAuth تظل خارج بيئة المتصفح.
  • يحد BFF من سرقة الرموز مرة واحدة أو بصورة مستمرة ومن الحصول على رموز جديدة، لكنه لا يمنع رمزاً برمجياً خبيثاً يشارك التطبيق أصله من إرسال طلبات تحملها الجلسة المستندة إلى ملف تعريف الارتباط. إثبات بقاء السر في عهدته لا يثبت أن الفعل كان مقصوداً.

حادثة لم يختف فيها أي سر

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

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

يفصل المستند أربعة أوضاع تهديد مرتبطة بـ OAuth: سرقة الرموز الموجودة مرة واحدة، واستخراجها باستمرار أثناء دورانها، والحصول على رموز حديثة عبر تدفق تفويض جديد، وتمرير الطلبات عبر متصفح الضحية. الوضع الرابع هو المفتاح هنا، لأنه يفسر وقوع عملية غير مرغوبة فيما بقيت جميع الرموز في مواقع الحفظ المقررة.

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

لذلك يجب إبقاء عبارة «لم تُسرق الرموز» ضيقة. هي تثبت أن قيمة bearer لم تخرج من الحيازة ولم تصبح صلاحية قابلة للنقل وإعادة الاستخدام من جهاز آخر. لكنها لا تثبت أن المستخدم قصد الطلب، ولا أن خريطة مسارات BFF كانت مقيدة كما ينبغي، ولا أن خدمة المورد طبقت قاعدة العمل الصحيحة.

يغيّر BFF عواقب الهجوم لا الثقة في الأصل

يعمل Backend for Frontend بصفته عميل OAuth سرياً. يحتفظ برموز الوصول والتحديث في الخادم، ويمثل جلسة المتصفح بملف تعريف ارتباط، ويمرر طلبات الموارد بعد إضافة الرمز المناسب. يرى المتصفح واجهة للجلسة بدلاً من مادة بيانات الاعتماد.

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

لكن تمرير الطلب عبر المتصفح يبقى ممكناً. تمنع HttpOnly JavaScript من قراءة ملف الجلسة، ولا تمنع المتصفح من إرفاقه تلقائياً بطلب مسموح. يستدعي الرمز الذي يعمل في الأصل نفسه نقطة BFF، فيقدم المتصفح الجلسة، ويحدد BFF الرمز، ثم يرسل الطلب. تعمل السلسلة كما هو مقرر مع أن الدافع الأول اختُطف.

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

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

ملف الجلسة غير المقروء يظل سلطة فعالة

تشترط أفضل ممارسة استخدام Secure وHttpOnly مع ملفات تعريف ارتباط BFF. وتوصي كذلك بـ SameSite=Strict، والمسار /، وعدم تعيين Domain، واستخدام بادئة مرتبطة بالمضيف متى سمح النشر. تقلل هذه السمات الانكشاف أثناء النقل، والقراءة من الرمز البرمجي، والمشاركة الواسعة بين النطاقات الفرعية.

لا تثبت أي سمة منها نية المستخدم. تحتاج تفاعلات BFF المستندة إلى ملف تعريف الارتباط إلى دفاع ملائم ضد CSRF. يفيد SameSite، لكن نطاقين فرعيين شقيقين قد ينتميان إلى الموقع نفسه رغم اختلاف الأصل. وعند السيطرة على أحدهما قد ينفتح مسار ظنه فحص سطحي مغلقاً.

يحتاج CORS أيضاً إلى دليل محدد. بعض الطلبات المصنفة safelisted تُرسل من دون preflight؛ وقد يمنع المتصفح قراءة الاستجابة فقط، لا الأثر الذي حدث. يستطيع BFF اشتراط ترويسة مخصصة لإجبار الفحص المسبق، بشرط أن يثبت الاختبار أن كل نقطة حساسة ترفض أي طلب لا يحملها. عبارة «تم تفعيل CORS» ليست نتيجة تدقيق كافية.

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

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

خريطة الوكيل سطح للتفويض

لا يقتصر BFF على كونه خزنة للرموز. إنه يترجم طلباً داخلاً موثقاً بملف الجلسة إلى اتصال خارج مصرح به برمز bearer. يحدد اختيار المضيف والمسار والطريقة مقدار السلطة التي تستطيع الجلسة إنفاقها.

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

المسار /bff/accounts/{id}، على سبيل المثال، ليس مجرد أنبوب تقني. فهو يقرر هل تستطيع الجلسة القراءة فقط أم التعديل أو التحويل أو الإغلاق، وأي معرفات مسموحة. وعلى خدمة المورد أن تتحقق من الجمهور والنطاق والفاعل وقاعدة العمل الخاصة بالفعل. صحة التوجيه لا تعني تلقائياً صحة النتيجة النهائية.

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

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

ثلاث بنيات تحفظ أدلة مختلفة

تقارن أفضل ممارسة بين BFF كامل، وخادم خلفي يتوسط الرموز، وعميل OAuth يعمل في المتصفح وحده. في الأول يبقى نوعا الرمز في الخادم وتمر كل اتصالات المورد عبر الوكيل. في الثاني تبقى بيانات العميل السرية ورمز التحديث في الخادم، لكن رمز الوصول يعود إلى المتصفح ليتصل مباشرة. وفي الثالث يدير runtime المتصفح تدفق OAuth والرموز كلها.

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

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

يوفر DPoP حداً مفيداً آخر. قد يصعب استعمال رمز مرتبط بمفتاح غير قابل للتصدير بعيداً عن الجهاز. إلا أن ذلك لا يمنع تمرير طلبات بواسطة المتصفح. وإذا استطاع الرمز المخترق بدء تدفق جديد، فقد يحاول ربط الرموز الجديدة بمفتاح يسيطر عليه. لذلك لا تكفي عبارة «مرتبط بالمرسل» من دون تحديد سياق المرسل والمفتاح وتدفق الإصدار.

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

يجب ألا يتجاوز الادعاء حدود الآلية

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

ينبغي للسجل التشغيلي أن يحفظ منشأ الرمز البرمجي وتبعياته، والأصل، وإصدار الجلسة وانتهاءها، وسمات ملف الارتباط، ووقت الطلب وطريقته ومساره وفئة جسمه، ونتيجة CSRF وCORS، وتعيين BFF، وجمهور الرمز ونطاقه، وقرار المورد، والاستجابة، والأثر التجاري، وصاحب مسؤولية التراجع. لكل حقيقة ساعة ومالك مختلفان.

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

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

المصادر