HTTP Basic Authentication من أقدم الطرق وأبسطها لحماية مورد ما بكلمة مرور: يطلب المتصفح اسم المستخدم وكلمة المرور، ثم يرسلهما مع كل طلب إلى الخادم. هذه البساطة نفسها هي أكبر نقطة ضعف فيه.
كيف يُبنى ترويسة Authorization
يُدمج اسم المستخدم مع كلمة المرور بفاصلة نقطتين (username:password)، ثم تُرمَّز السلسلة كاملة بترميز Base64 وتوضع في الترويسة Authorization: Basic <النص_المرمز>. يعيد المتصفح إرسال هذه الترويسة تلقائيًا مع كل طلب لاحق بعد أول تسجيل دخول ناجح.
لماذا Base64 ليس أمانًا
Base64 هو مخطط ترميز وليس تشفيرًا: يمكن لأي شخص فك السلسلة وإعادتها إلى username:password في ثوانٍ دون الحاجة إلى أي مفتاح. إذا اعتُرض الطلب — عبر شبكة Wi-Fi عامة غير محمية مثلًا — تصبح بيانات الاعتماد مكشوفة فورًا.
النص العربي وحجم Base64
Base64 يُرمّز البايتات وليس الأحرف، لذا فإن ترميز النص الأصلي هو ما يحدد النتيجة. الحرف اللاتيني يشغل بايتًا واحدًا في UTF-8، بينما يشغل الحرف العربي بايتين — أي أن كلمة مرور بالعربية مثل كلمةالسر123 ستُنتج رمز Base64 أطول ملحوظًا مقارنة بكلمة مرور لاتينية بنفس عدد الأحرف. الاتجاه من اليمين إلى اليسار (RTL) لا يؤثر إطلاقًا على البايتات المخزَّنة أو على الترميز نفسه — فهو خاصية عرض بصرية فقط، بينما تبقى البايتات دائمًا بترتيبها المنطقي بغض النظر عن اتجاه القراءة.
لماذا يُستخدم هذا
- حماية خادم تجريبي (staging) أو أداة داخلية بكلمة مرور بسرعة أثناء التطوير.
- بناء ترويسة Authorization صحيحة لاختبار واجهة برمجية يدويًا عبر curl أو Postman.
- فهم لماذا يُعتبر استخدام Basic Auth عبر HTTP العادي (دون HTTPS) ثغرة أمنية خطيرة.
لا يوجد تسجيل خروج مدمج في Basic Auth
يخزّن المتصفح بيانات الاعتماد مؤقتًا ويضيف ترويسة Authorization تلقائيًا إلى كل طلب لاحق لنفس origin إلى أن تُغلق علامة التبويب — فالبروتوكول لا يوفر زر "تسجيل خروج" قياسيًا. لإجبار المستخدم على الخروج، تلجأ الخوادم إلى حيل مثل إعادة رمز 401 عمدًا بقيمة realm مختلفة، أو الاعتماد على أن يغلق المستخدم جميع علامات التبويب بنفسه.