Connection Allowlists: جدار حماية داخل المتصفح

في 25 أغسطس 2026 وصل Chrome 152 إلى القناة المستقرة، ومعه ميزة تعيد ترتيب طبقة الأمان في الواجهة: Connection Allowlists. الفكرة مباشرة — تُعرِّف في ترويسة HTTP واحدة الوجهات التي يُسمح لصفحتك بالاتصال بها، والمتصفح نفسه يرفض ما عداها قبل أن يفتح الاتصال أصلًا.

المشكلة: نضبط ما نُحمّله، ولا نضبط إلى أين نُرسل

Content Security Policy عالجت نصف السؤال: من أين يُسمح بتحميل الـ scripts والصور والأنماط. لكنها لم تُصمَّم للسؤال الثاني، وهو الأخطر اليوم: بعد أن يعمل الـ script داخل الصفحة، إلى أين يستطيع أن يُرسل؟

هذه الفجوة هي بالضبط ما تستغله هجمات سلسلة التوريد. dependency واحدة مسمومة داخل الـ bundle لا تحتاج ثغرة XSS ولا تعديلًا في الـ DOM؛ يكفيها استدعاء fetch إلى domain يملكه المهاجم لتُخرج الـ tokens وحقول النماذج بهدوء تام. والنمط تكرر أكثر من مرة خلال 2026 — راجع هجمات npm التي تعمل عند الـ import. ضبط المصدر وحده لا يكفي حين تكون الوجهة هي محل الخطر.

ما الذي تغيّر

Connection Allowlists تنقل القرار إلى طبقة الشبكة داخل المتصفح. تُرسَل الترويسة مع استجابة الصفحة، وتُطبَّق على كل اتصال صادر منها:

Connection-Allowlist: (response-origin "https://api.example.com/*"
  "https://*.cdn.example"); report-to=network-reports

الصياغة مبنية على Structured Fields (RFC 8941)، ومطابقة العناوين تستخدم URLPattern بدل قواعد خاصة مبتكرة — أي أن ما تعرفه من مطابقة المسارات ينطبق هنا مباشرة. والرمز response-origin يسمح تلقائيًا بالـ origin الذي أرسل الاستجابة، فلا تحتاج إلى كتابته يدويًا.

النطاق أوسع مما يوحي به الاسم: الفرض يشمل subresource fetches، والتنقلات وإعادة التوجيه، و preload و preconnect و DNS prefetch، إضافة إلى WebSocket و WebRTC و WebTransport — داخل الـ document وفي dedicated و shared و service workers. والطلب المرفوض يظهر في DevTools بحالة blocked:other.

وقبل الفرض هناك وضع المراقبة، وهو المسار العملي الوحيد لتطبيق قائم بالفعل:

Connection-Allowlist-Report-Only: (response-origin
  "https://api.example.com/*"); report-to=network-reports

يجمع التقارير عبر Reporting API دون أن يكسر شيئًا. راقب أسبوعًا، اقرأ ما يخرج فعلًا من الصفحة — غالبًا ستفاجئك القائمة — ثم شدّد.

التحفّظات الواقعية

• الدعم محصور في Chrome حتى الآن. انتقلت الميزة من origin trial في النسخ 148–151 إلى الشحن في 152 على desktop و Android و WebView. Mozilla و WebKit لم تُعلنا تأييدًا، ومراجعة W3C TAG ما زالت معلّقة. اعتبرها طبقة دفاع إضافية، لا بديلًا عن ضوابط الـ server.
• ليست علاجًا للـ XSS. الاختصاص محدد بوجهة الاتصال، لا بكيفية تحميل المورد أو تنفيذه. الحقن يبقى حقنًا؛ الجديد أن مسار الخروج صار ضيّقًا.
• السياسات تتقاطع ولا تتّحد. عند تطبيق أكثر من سياسة، يمرّ الاتصال فقط إذا اجتازها كلها — نفس المنطق التراكمي في CSP.
• إعادة التوجيه من طرف الـ server ما زالت نقطة نقاش مفتوحة في المواصفة، ومثلها open redirects.
• القائمة وثيقة حيّة. أي أداة analytics جديدة أو مزوّد دفع يعني تحديث الترويسة، وإلا انكسرت الميزة بصمت. اربطها بعملية النشر، لا بذاكرة أحد في الفريق.

الخلاصة

النموذج الذي كنا نبنيه بالـ proxy وقواعد الخروج على مستوى البنية التحتية صار متاحًا داخل المتصفح بسطر واحد. والقيمة الحقيقية ليست في المنع فحسب، بل في أنك تملك — لأول مرة — قائمة صريحة ومكتوبة بما يتصل به تطبيقك فعلًا. ابدأ بـ Report-Only، واجعل القائمة جزءًا من مراجعة الكود لا من إعدادات الطوارئ.

المصدر الأساسي: Connection Allowlists على Chrome for Developers والمواصفة في WICG.