SameSite صُمم لتقليل إرسال cookies في طلبات cross-site غير المتوقعة. لكن فهم Lax و Strict و None من التعريف فقط لا يكفي لأن السياق يختلف بين top-level navigation و fetch و iframe. كما أن Secure مرتبط غالبًا ب ـSameSite=None في المتصفحات الحديثة.
حدد site لا origin فقط
مفهوم same-site يعتمد على schemeful site وقواعد registrable domain، بينما origin يضيف port. موقعان قد يكونان same-site لكن cross-origin. هذا يفسر حالات CORS موجودة مع إرسال Cookie.
اختبر Lax
Lax يسمح عادة ببعض top-level navigations الآمنة بينما يمنع كثيرًا من subresource/cross-site POST scenarios. أنشئ صفحة على domain A تفتح أو تطلب B وسجل Cookie header.
اختبر Strict
Strict أكثر تحفظًا وقد يمنع cookie حتى عند انتقال المستخدم من site آخر إلى الرابط. مناسب لبعض الحالات لكنه قد يؤثر على flows مثل links أو auth callbacks.
اختبر None و Secure
SameSite=None يستخدم لحالات cross-site المقصودة مثل بعض embeds، وغالبًا يحتاج Secure. على HTTP المحلي قد ترى رفض cookie أو behavior مختلف، لذلك استخدم HTTPS test environment.
خطوات عملية
- Set cookie.
- navigate cross-site.
- fetch/iframe.
- inspect request Cookie.
راقب Defaults
Cookie بدون SameSite قد تعامل ك Lax-by-default في متصفحات حديثة. لا تعتمد على سلوك قديم؛ صرّح attribute عندما يهم التطبيق.
اربط الاختبار ب ـCSRF
SameSite طبقة حماية مساعدة لا بديلًا شاملًا عن CSRF tokens في كل تصميم. راجع flow والتوافق قبل الاعتماد عليها وحدها.
قائمة مراجعة
- top-level GET.
- cross-site POST.
- iframe.
- fetch with credentials.
اختبر Redirect Chains وال ـEmbedded Contexts
Flows الواقعية مثل OAuth تبدأ من Site A وتنتقل إلى Identity Provider ثم تعود. SameSite Cookie قد تتصرف بصورة مختلفة خلال top-level navigation مقارنة ب ـiframe أو fetch. أنشئ سيناريو redirect كامل وسجل Cookie header في كل hop، ثم اختبر نفس endpoint داخل iframe إذا كان المنتج يعتمد embedding. راجع أيضًا Partitioned Cookies أو CHIPS عندما يكون third-party context جزءًا من التصميم؛ لا تخلطها مع SameSite لأنها آلية أخرى. هذا يساعد على تفسير حالات login تعمل عند فتح الرابط مباشرة وتفشل داخل widget أو embedded tool، ويمنع تغيير SameSite إلى None بصورة واسعة فقط لإنقاذ حالة واحدة.
قائمة مراجعة
- Top-level redirect.
- Callback.
- Iframe/embed إن كان مستخدمًا.
- Cookie headers في كل مرحلة.
اختبر Cookie Deletion بنفس Attributes
حذف cookie يحتاج غالبًا نفس Path و Domain وأحيانًا السياق المناسب الذي أُنشئت فيه. اختبر logout وتأكد أن Set-Cookie للحذف يطابق السمات الضرورية وأن cookie تختفي من الطلب التالي. إذا بقيت نسخة على path آخر، قد يبدو SameSite السبب بينما المشكلة duplicate cookies بأسماء متطابقة.
من المثال إلى تطبيق يمكن صيانته
في «SameSite Cookies: سيناريوهات Lax و Strict و None داخل المتصفح» جرّب الحل على حالة صغيرة ثم أضف failure path واضحًا واختبارًا آليًا يحمي السلوك المتوقع. حدّد contract للمدخلات والمخرجات، وتعامل مع القيم الناقصة قبل الوصول إلى طبقة التنفيذ. إذا كان الحل يتعامل مع API أو ملف أو DOM، أضف logging مختصرًا يوضح المرحلة وكود الخطأ دون بيانات حساسة. بعد ذلك اختبر التوافق مع نسخة سابقة أو بيئة مختلفة. هذه الخطوات تجعل المثال مفيدًا في مشروع حقيقي بدل أن يبقى snippet يعمل فقط في المسار المثالي.
قائمة مراجعة
- Contract للمدخلات والمخرجات.
- اختبار failure path.
- رسائل خطأ قابلة للتشخيص.
- Regression test قبل الدمج.
توثيق النتيجة للفريق
بعد الانتهاء من اختبار «SameSite Cookies: سيناريوهات Lax و Strict و None داخل المتصفح»، احفظ ملخصًا قصيرًا يوضح البيئة والخطوات والنتيجة وما الذي تغير عن ال ـbaseline. أرفق أكواد الأخطاء أو المقاييس الضرورية فقط، واربطها برقم الإصدار. هذا السجل يجعل المراجعة اللاحقة أسرع ويمنع إعادة نفس النقاش من الصفر، كما يسمح لفريق آخر بتكرار التجربة دون الاعتماد على ذاكرة الشخص الذي نفذها. إذا كانت النتيجة غير حاسمة، اكتب ذلك صراحة وحدد الاختبار التالي بدل تحويل الاحتمال إلى استنتاج نهائي.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…