almessadi.
العودة إلى الفهرس

كوكيز HttpOnly مقابل `localStorage` لأمان جلسة المتصفح_

الرموز في `localStorage` سهلة التنفيذ ولكنها أسهل للوصول لها عبر XSS. تقلل كوكيز HttpOnly من تلك المخاطر، على الرغم من أنها لا تزال تتطلب تصميمًا جيدًا لـ CSRF والجلسات.

تاريخ النشر12 يناير 2025
وقت القراءة7 min read

JWTs ليست هي الحجة الحقيقية هنا. إن استراتيجية تخزين المتصفح هي الأمر. غالبًا ما تقوم الفرق بتخزين رموز الوصول في `localStorage` لأن الأمر سهل للإعداد من كود العميل. المشكلة بسيطة: إذا هبط XSS، يكون الرمز عادةً قابلًا للقراءة على الفور.

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

## لماذا تعتبر الكوكيز عادةً أكثر أمانًا في المتصفح

غالبًا ما يبدو الكوكي الآمن للجلسة كما يلي:

```http
Set-Cookie: session=opaque-token; HttpOnly; Secure; SameSite=Lax; Path=/

هذا لا يجعل النظام غير قابل للاختراق. إنه يزيل واحدة من أسهل طرق استخراج الرموز في تطبيقات المتصفح.

التنازلات التي لا تزال بحاجة إلى التعامل معها

يغير نقل الرمز إلى الكوكي نموذج التهديد، وليس الحاجة إلى العمل الأمني:

  • دفاعات CSRF لا تزال مهمة
  • دوران الجلسة لا يزال مهمًا
  • XSS لا يزال خطيرًا لأن المهاجم يمكنه التصرف عبر الصفحة حتى لو لم يتمكن من قراءة الرمز

النقطة ليست "الكوكيز تحل مشاكل المصادقة". النقطة هي أن نقل الجلسة المدارة بواسطة المتصفح غالبًا ما يكون أكثر أمانًا من تسليم رموز التحمل إلى localStorage.

قاعدة أفضل

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

قراءة إضافية