Web security, authentication, and secure coding practices
82 posts
في مشهد تطوير التطبيقات الحديث، الأمن ليس مجرد ميزة؛ بل هو الأساس. بالنسبة للمطورين الذين يبنيون أنظمة موزعة ومعقدة، فإن إدارة هوية المستخدم والتحكم في الوصول يدوياً غالباً ما تكون وصفة للكوارث. هنا يأتي دور OAuth 2.0 وOpenID Connect (OIDC)...
أحدثت OAuth 2.0 ثورة في طريقة تفويض الوصول إلى موارد الويب، لكنها أدخلت ثغرة أمنية كبيرة: سرقة الرموز. إذا حصل المهاجم على رمز وصول صالح، فيمكنه غالباً استخدامه للتنكر كمستخدم حتى انتهاء صلاحية الرمز، بغض النظر عما إذا كان قد تم نقله عبر...
لطالما كان تدفق رمز التفويض هو المعيار الذهبي لتأمين تطبيقات الويب. ومع ذلك، قدمت تطبيقات الصفحة الواحدة (SPAs) والعملاء المتنقلين الأصليين تحدياً فريداً: فهي "عملاء عامون". على عكس تطبيقات الخوادم التقليدية، لا يمكن لهذه العملاء تخزين...
في مجال أمن التطبيقات، لا توجد مسؤوليات أكثر أهمية من التعامل مع بيانات اعتماد المستخدمين. لعقود من الزمان، اعتمدت الصناعة على دوال التجزئة أحادية الاتجاه السريعة مثل MD5 وSHA-1. ومع ذلك، مع تطور قدرات الأجهزة، لا سيما مع ظهور وحدات معالجة الرسومات (GPUs) والتخصصات...
عند تصميم تدفق OAuth2 الخاص بك، استخدم دائمًا تدفق منح رمز التفويض مع PKCE (مفتاح إثبات لتبادل الرموز) للعملاء العلنيين لمنع هجمات اعتراض رموز التفويض. تجنب تدفق المنح الضمني تمامًا، حيث يعرض رموز الوصول في جزء عنوان URL.
في المشهد المتطور لتطوير التطبيقات الأصلية للسحابة، أصبح نموذج الأمان التقليدي "القصر والخندق" عفا عليه الزمن. مع انتشار الخدمات المصغرة والأوعية والعمل المؤقت، اختفى جدار الشبكة الداخلي فعلياً. يتطلب هذا التحول تغييراً جوهرياً في...
اعتمد نموذج الأمان التقليدي بشكل كبير على حدود شبكة قوية. داخل أسوار القلعة، كان كل شيء يُعتبر موثوقاً؛ أما خارجها، فكان يُعتبر خبيثاً. في عصر الخدمات المصغرة، والح containers، ونشر السحابة المتعددة، أصبح هذا النهج "قلعة وخندقاً" قديماً. مع تواصل الخدمات عبر شبكات ديناميكية، غالباً عبر مزودي سحابة مختلفين، ذابت الحدود. هنا تظهر بنية الثقة الصفرية (ZTA): نموذج أمني يقوم على مبدأ أن الثقة لا ينبغي أن تكون ضمنية، بل يجب التحقق منها دائماً.