عزل الكوكيز وملفات المتصفح: ما الذي يحميه فعلًا؟

عزل الكوكيز مهم لأنه يمنع Session cookie لحساب من الظهور داخل Profile أخرى، لكنه ليس عزلًا كاملًا وحده. التطبيق الحديث يستخدم LocalStorage و IndexedDB و Cache و Service Workers و Permissions، وقد تعتمد بعض الإضافات على Storage خاصة بها. كذلك الشبكة والبصمة طبقات منفصلة. لذلك يجب النظر إلى Cookie isolation كجزء من Profile boundary، لا كمرادف لها.

ما الذي تحميه Cookie jar مستقلة؟

تمنع مشاركة cookies بين Profiles عندما يكون partitioning صحيحًا. هذا يشمل Session cookies و Persistent cookies و HttpOnly. إذا فتحت نفس الموقع في Profile ثانية يجب ألا ترث تسجيل الدخول فقط بسبب Cookie.

ما الذي لا تحميه؟

LocalStorage و IndexedDB و Cache Storage تحتاج partitioning خاص بها. Permissions مثل Notifications و Camera يمكن أن تكون state مستقلة. Extensions قد تحتفظ Tokens أو حسابات. إذا كانت هذه الطبقات مشتركة، عزل cookies وحده يعطي إحساسًا ناقصًا بالأمان.

الملفات نفسها تحتاج دورة حياة

Browser profile directory تحتوي databases و cache و preferences. لا تنسخها وهي مفتوحة، ولا تعيد استخدامها لحساب جديد بلا تنظيف أو أرشفة. Backup يجب أن تكون متسقة وقابلة للاستعادة.

الشبكة ليست جزءًا من Cookie isolation

Profile قد تكون معزولة في التخزين لكنها تستخدم نفس Proxy أو DNS أو WebRTC policy. إذا كان السيناريو يحتاج شبكة مستقلة، اربطها بال Profile واختبرها منفصلًا.

اختبر الحدود لا الواجهة

قد تظهر Profile جديدة بلا login فتظن العزل ناجحًا، لكن marker في IndexedDB أو Permission قد تكون مشتركة. استخدم صفحة اختبار تقرأ كل الطبقات وتعيد تقريرًا آليًا بعد تحديثات المتصفح.

اختبر العزل أثناء التشغيل المتزامن

افتح Profile A و B في الوقت نفسه على نفس Origin، وسجّل دخولين مختلفين، واكتب markers في LocalStorage و IndexedDB ثم نفذ تحديثات متزامنة. بعض مشاكل partitioning لا تظهر عند تشغيل Profile واحدة ثم إغلاقها قبل فتح الثانية. بعد الاختبار، أعد تشغيل التطبيق وتأكد أن كل بيئة استعادت بياناتها فقط، وأن إغلاق أو تنظيف Profile لا يغير حالة الأخرى.

وثق حدود الاختبار

اكتب بوضوح أي طبقات تم اختبارها وأيها لم تُختبر، حتى لا تتحول نتيجة Cookie isolation إلى ادعاء شامل بعزل كامل لكل خصائص Profile.