الأمان باستخدام Spring Security

الأمان الذي يُكتب يدويًا داخل المتحكمات (controllers) يفشل دائمًا بالطريقة نفسها. نضيف اختبارًا في بداية كل دالة حساسة — if (session.getAttribute("user") == null) return "redirect:/login"; — فيعمل الأمر، إلى أن يأتي يوم تُكتب فيه دالة جديدة بدون هذا الاختبار. الثغرة ليست في شيفرة الأمان نفسها، بل في غيابها في موضع ما، ولا شيء ينبّه إلى هذا الغياب.

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

يقلب Spring Security هذا الافتراض. فهو يتدخل قبل DispatcherServlet على هيئة سلسلة من فلاتر السيرفلت (servlet filters)، ويطبّق سياسة معلنة في مكان واحد. أي طلب إلى عنوان URL لم تنص عليه السياسة لا يصل إلى أي متحكم، بل ترفضه البنية التحتية. وهكذا فإن إضافة شاشة جديدة لا تفتح ثغرة — في أسوأ الأحوال تكون الشاشة غير متاحة، وهو أمر يُلاحَظ فورًا.

يبني هذا الدرس تلك السياسة لتطبيق Spring MVC: نموذج تسجيل دخول، ومستخدمون مخزَّنون في قاعدة البيانات بكلمات مرور مشفّرة، وأدوار، وحماية CSRF، وعرض مشروط في قوالب Thymeleaf. كما يشدّد على ما تغيّر: فمنذ Spring Security 6 لم يعد WebSecurityConfigurerAdapter موجودًا، بينما تعتمد عليه غالبية الأمثلة التي ستجدها على الإنترنت.