الخلاصة

  • يعمل Backend for Frontend في RFC 10017 عميلاً سرياً لـOAuth. يحتفظ برموز الوصول والتحديث خلف جلسة تعتمد على cookie، ثم يضيف الرمز المناسب إلى الطلب الصادر. لذلك لا يجد JavaScript رمزاً قائماً يسرقه، ولا يملك credentials العميل لاستبدال authorization code جديد بنفسه.
  • مع ذلك تستطيع شفرة خبيثة تعمل داخل المصدر الشرعي استدعاء endpoint يستطيع frontend الشرعي استدعاءه. يضيف المتصفح الجلسة ويترجم BFF الطلب إلى طلب يحمل token. النتيجة هي اختطاف العميل، وهو أضيق من سرقة الرمز لكنه يتسع بقدر الأفعال المتاحة فعلاً.
  • يربط الإيصال القابل للمراجعة بين المصدر وإصدار frontend، والجلسة وسياسة cookie، ونتيجة CSRF، وendpoint، والوجهة/المسار/الطريقة المسموح بها، وaudience وscopes، وترخيص خادم المورد، ومعالجة الاستجابة، وقرار الشذوذ، ومسار الإصلاح.

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

لم يحتج المهاجم إلى قراءة cookie من نوع HttpOnly أو العثور على refresh token في storage. شغّل شفرته داخل origin التطبيق، وصاغ طلباً يشبه طلب الواجهة الصحيحة، وترك المتصفح يرفق الجلسة. وجد BFF الرمز المرتبط بها، ثم أرسل الطلب إلى resource server.

تفصل RFC 10017 بين هذا المسار وبين حيازة credential. صدرت OAuth 2.0 for Browser-Based Applications في أغسطس 2026 بصفتها Best Current Practice من IETF، وبأسماء Aaron Parecki وPhilippe De Ryck وDavid Waite. يسجل IETF Datatracker المحفوظ في 31 أغسطس 2026 Parecki رئيساً مشاركاً لمجموعة SCIM، ويعرض RFC 10017 بين وثيقتي RFC. أما موقعه فيذكر عمله في معايير الهوية وإشرافه على oauth.net ومشاركته في مجموعة OAuth التابعة لـIETF.

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

يبدأ التحليل بعد دخول الشفرة الخبيثة

سؤال «أين نخزن token؟» مهم، لكنه يفترض أن التطبيق هو صاحب كل JavaScript. تبدأ RFC من حالة أصعب: XSS أو مورد خارجي مخترق أو ثغرة أخرى تسمح بتشغيل JavaScript أو WebAssembly في execution context الخاص بالتطبيق.

عندها لا تتصرف الشفرة كمستخدم خارجي مجهول، بل تملك privileges الشفرة المشروعة. تستطيع قراءة storage المتاح، واستدعاء functions، وتغيير control flow، والتعامل مع سياقات المصدر نفسه، وإرسال طلبات إلى backend.

لهذا تبقى المعالجة الصحيحة للمدخلات، وتقليل الموارد الخارجية، وSubresource Integrity، وContent Security Policy، وعزل origins ضوابط أساسية. منع التنفيذ هو السبيل الوحيد لمنع client hijacking نفسه. أما اختيار architecture فيحدد ما يبقى للمهاجم إذا فشل المنع.

تفرق RFC بين سرقة token مرة واحدة، وسرقته بصورة مستمرة مع كل تحديث، والحصول على مجموعة جديدة عبر authorization flow، وإرسال الطلبات من متصفح المستخدم بلا سرقة. في المسار الأخير يضيف browser أو component خارجي عنصر التفويض آلياً. عدم قابلية credential للتصدير لا تعني عدم قابلية العملية للاستدعاء داخل الجلسة.

يزيل BFF السلطة المحمولة

تعرض RFC ثلاثة أنماط رئيسية بترتيب تنازلي للأمن، ويأتي BFF أولاً. وتوصي به بقوة لتطبيقات الأعمال والأنظمة الحساسة وتلك التي تعالج بيانات شخصية. يصبح الخادم confidential client، وينفذ Authorization Code مع PKCE، ويحفظ tokens، ويمرر كل تفاعل مع resource server.

هناك علاقتان منفصلتان. يمنح authorization server الرموز إلى BFF. ثم ينشئ BFF جلسة مع browser عبر cookie. عندما يطلب frontend مورداً، يرسل الطلب إلى BFF؛ فيقرأ الأخير session state، ويحذف cookie من الطلب الخارجي، ويلحق access token المناسب قبل الإرسال.

هذا التصميم يمنع استخراج الرموز الموجودة وسرقتها المتواصلة. وحتى إن حصلت الشفرة على authorization code جديد، فلا تملك client credentials اللازمة للاستبدال، فيما يحمي PKCE جانباً آخر من المعاملة. ويمنع HttpOnly قراءة session state مباشرة، فلا يتحول اختطاف العميل تلقائياً إلى جلسة محمولة.

لكن القدرة الباقية مرتبطة بالمتصفح الحي. تستدعي الشفرة الخبيثة endpoints التي تستطيع الواجهة استدعاءها. لا يدّعي BFF أنه يميز نية برنامجين لهما privileges متطابقة؛ بل يمنع منح المتصفح credential مستقلاً، ويتيح تضييق سطح الأفعال على الخادم.

يجب أن تكون مخارج المترجم محددة

يترجم BFF طلباً داخلاً يحمل session إلى طلب خارج يحمل token. إذا حدد input الوجهة بحرية، أمكن توجيه token إلى server يملكه المهاجم.

لذلك تلزم RFC التحقق من destination hosts، والاحتفاظ بقائمة صريحة من resource servers المسموح بها، وضبط dynamic routes بحسب host وpath. ويقلل تقييد HTTP methods لكل endpoint من الخطر؛ فلا ينبغي لمسار قراءة أن يمرر DELETE لمجرد أن الطلب الوارد حمله.

السماح بالhost وحده غير كاف. قد يجمع domain واحد API المستخدم وAPI الإدارة. وقد يحتوي body على URL، أو تعبر redirect الحدود بعد نجاح الفحص الأول. السياسة القابلة للإعادة تجمع scheme وhost وpath template وmethod وrequest schema وقاعدة redirect وtoken audience وscopes ونوع response.

ويظل resource server صاحب قرار مستقل. يتحقق من issuer وaudience وexpiry وpermissions، ثم يقرر العملية على object بعينه. يوسع token عريض مع proxy عام أثر الاختطاف؛ أما routes ضيقة وobject-level authorization فتحافظ على الحدود.

هنا تعمل Minimum Initial Specification كما ينبغي: يحدد المعيار المشترك confidential client وcookie محمية وCSRF وproxy محدوداً، ويحدد المشغل المحلي خريطة الأفعال الخاصة به من دون أن يجعل عبارة «BFF متوافق» بديلاً عنها.

تحمي cookie هوية الجلسة لا نية الإنسان

تفرض RFC Secure وHttpOnly، وتوصي بـSameSite=Strict وpath يساوي / وعدم وضع Domain واستخدام prefix مثل __Host-Http- حين يكون مناسباً. وإذا احتوت client-side session على token material فينبغي تشفيرها كي لا يُحفظ في disk كنص واضح.

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

وتجعل cookie-based authentication حماية CSRF إلزامية. لا يكفي SameSite=Strict دائماً؛ فقد يكون subdomainان من الموقع نفسه مع اختلاف origin، ويخلق takeover لأحدهما مسار forgery ضد الآخر.

يمكن استخدام CORS إذا فُرض preflight. فالطلبات safelisted قد تُرسل قبل أن يمنع browser المصدر الخارجي من قراءة response. توصي RFC بـcustom header، وإذا استُخدم هذا الأسلوب وجب التحقق من وجوده في كل incoming request. وتوجد بدائل anti-forgery أو double-submit في frameworks.

تفصل حماية CSRF بين origin خارجي والorigin الصحيح. أما malicious code الموجود بالفعل داخل الصحيح فهو في الجهة المقبولة من هذا الحد. نجاح CSRF check ليس إثباتاً لنية المستخدم.

حجم الخطر المتبقي قابل للقياس

client hijacking أضعف من امتلاك token مباشرة. يبقى المهاجم مقيداً بالbrowser والجلسة وBFF routes وسياسات العميل وresource authorization. قد تمنعه CORS أو route غير مكشوف أو قرار على مستوى object. تحافظ RFC على هذا الفرق ولا تساوي بين الهجومين.

لكن يجب إثبات القيود، لا رسمها فقط. يلزم inventory لكل endpoint يربطه بـhost وpath وmethod وtoken وaudience وscopes وقاعدة object والبيانات الراجعة. ثم تُشغّل شفرة hostile مضبوطة داخل origin وتحاول الخروج عن التركيبات المعتمدة.

يرى BFF كل traffic يمر عبره، ولذلك يصلح لـrate limiting وanomaly detection. burst أسرع من الاستخدام البشري، وتسلسل endpoints غير معتاد، ومجموعة objects غريبة، أو استمرار session بعد إبطال refresh token كلها triggers مفيدة.

وتنشأ كلفة privacy من الرؤية نفسها. إذا استضاف طرف ثالث BFF، استطاع رؤية requests وresponses كلها. لذا تلزم minimization وretention محدودة وtenant isolation وضبط وصول operators. نقل token إلى الخادم لا يمنح سلطة مراقبة بلا حدود.

وينبغي أن تتبع مدة session مدة السلطة الأساسية. تقترح RFC مساواتها بأقصى عمر refresh token وإبطالها عندما يصبح الرمز غير صالح. تسهل server-side session الإبطال لكنها تحتاج state replication؛ وتنتشر client-side session بسهولة أكبر لكنها تعتمد على expiry وrevocation للرموز.

إيصال كامل بلا أسرار

لا تُسجّل raw tokens أو client secret أو cookie كاملة. يكفي session correlation ID غير قابل لإعادة الاستخدام، ووقت الإنشاء والانتهاء، وسياسة cookie، وauthentication event، وcode transaction، وهوية عميل BFF، وإصدار frontend.

أضف endpoint وmethod وpath template ونتيجة CSRF/origin/CORS وschema validation. ثم resource server وoutbound path/method وإصدار allowlist وtoken fingerprint غير السري وissuer وaudience وscopes وexpiry وأحداث refresh/rotation/revocation ذات الصلة.

يكتمل الإيصال بقرار resource authorization وstatus وتحويل response وقرار rate limit أو anomaly وصاحب التغيير ومسار remediation. عندها يمكن فصل token exfiltration عن session theft وعن CSRF وعن same-origin abuse وعن proxy escape وعن downstream over-authorization.

يقدم Running-Code Primacy الاختبار الحاسم: تشغيل hostile script مضبوطة داخل origin، وإثبات أنها لا تقرأ token/session، ولا تكمل flow مستقلاً، ولا تتجاوز host/path/method، ولا تهزم object authorization، وتترك alert مفهوماً عند استخدام فعل مسموح بصورة شاذة.

ينجح BFF عندما لا يخرج token، وتبقى سلطة الطلب المتبقية ضيقة وقابلة للرؤية والإبطال.

المصادر