- بواسطة x32x01 ||
هل الـ JWT بتديك أمان حقيقي ولا إحساس زائف؟
كتير من الـ Developers أول ما يستخدموا JWT (JSON Web Token) يحسّوا إن التطبيق بقى “مؤمَّن” تلقائيًا لكن الحقيقة؟
الـ JWT مش نظام حماية كامل… دي مجرد رسالة موقعة.
ولو بتستخدمها بشكل سطحي، إنت كده فاتح باب واسع لأي ثغرة تخطر على بالك
ليه الاعتماد السطحي على JWT خطر؟
البيانات جوه التوكن مكشوفة
الـ Payload مش متشفر، ده معمول Base64 بسيعني أي حد يقدر يفكه ويشوف اللي جواه
- Role
- أي بيانات حساسة
التوقيع يمنع التعديل مش المشاهدة
الـ Signature دوره يقول: "التوكن متلعبش فيه"لكن مش دوره يخبي البيانات
يعني القراءة متاحة… التعديل بس هو الممنوع
مشكلة الـ Token Revocation
الـ JWT Stateless يعني:- التوكن لو اتسرّب
- هيفضل شغال
- لحد ما الـ Expiration يخلص
إلا لو بنيت:
- Blacklist
- Token Versioning
- أو System إضافي معقد
إزاي الـ Senior Developers بيأمنوا الـ APIs بجد؟
الأمان الحقيقي مش في الأداة…الأمان في الـ Strategy اللي إنت شغال بيها
استخدم Short-lived Access Tokens
خلي:- Access Token قصير جدًا (5–15 دقيقة)
- Refresh Token أطول
- HttpOnly
- Secure Cookie
تدوير المفاتيح Secret Key Rotation
مفتاح واحد طول السنة؟ ده خطر كبير الحل:
- غير الـ Secret / Keys دوري
- خلي عندك Key ID
- وادعم أكثر من مفتاح في نفس الوقت
التحقق الصارم من الـ Claims
التحقق من الـ Signature لوحده مش كفايةلازم تتأكد من:
- iss مين اللي أصدر التوكن
- aud مين المسموح له يستخدمه
- exp التوكن لسه صالح ولا لا
مثال تحقق JWT صح
Code:
jwt.verify(token, publicKey, {
issuer: "https://api.example.com",
audience: "example-client",
algorithms: ["RS256"]
});
استخدم RS256 بدل HS256
الأفضل دايمًا:- Private Key للإصدار
- Public Key للتحقق
- السيرفر اللي بيتحقق مش محتاج السر
- أمان أعلى
- تحكم أفضل في الـ Keys
الخلاصة
الـ JWT:- أداة قوية

- مش بودي جارد

اشتغل دايمًا بعقلية: Security First مش Feature First
عشان تبني نظام يستحمل ويعيش