تأمين واجهات REST البرمجية

خذ إعداد تطبيق ويب تقليدي، ووجّه إليه عميل JavaScript، ثم راقب ما يحدث: بدلًا من استجابة 401 نظيفة، يتلقى استدعاء fetch الخاص بك استجابة 302 تعيد التوجيه إلى صفحة تسجيل دخول بصيغة HTML. وهذا العميل الذي كان ينتظر JSON يحاول تحليل HTML فيفشل برسالة غير مفهومة. ومع ذلك لا شيء معطّل، فـ Spring Security يفعل بالضبط ما طُلب منه، أي أن يتصرف كما لو أن متصفحًا يتبع مسار تسجيل دخول.

هذا هو التعديل الأول المطلوب: الواجهة البرمجية لا تعيد التوجيه، بل تردّ برمز. أما التعديل الثاني فيتعلق بالحالة. يخزّن التطبيق القائم على الجلسات الهوية على جانب الخادم ويستعيدها عبر ملف تعريف ارتباط (cookie)، بينما تشترط الواجهة عديمة الحالة أن يحمل كل طلب دليل هويته الخاص. كلا النموذجين يعمل، لكن نقاط الضعف فيهما ليست نفسها، والحمايات الملائمة لأحدهما لا تلائم الآخر.

وهنا يقع أكثر الخطأين شيوعًا في هذا المجال. الأول هو نسخ csrf.disable() دون التساؤل عمّا جعل هذه الحماية ضرورية، ثم تعطيلها أيضًا في أجزاء التطبيق التي تستخدم ملفات تعريف الارتباط. والثاني هو التعامل مع CORS على أنه آلية أمان وهو ليس كذلك، وفتح منفذ وصول ظنًّا أننا نتحكم فيه.

لذلك يضع هذا الدرس إعدادًا صحيحًا لواجهة برمجية، ثم يشرح هاتين الآليتين بدقة كافية لتتمكن من اتخاذ القرار بنفسك بدلًا من النسخ.