مقدمة إلى Spring Security

لا تأتي معظم الثغرات الأمنية التي نصادفها في بيئة الإنتاج من خوارزمية تشفير معطوبة. إنما تأتي من مطوّر نسخ إعدادًا وجده على الإنترنت دون أن يعرف على وجه الدقة ما الذي يسمح به. استخدام permitAll() أوسع مما ينبغي، أو قاعدة تفويض وُضعت بعد قاعدة أخرى فابتلعتها، أو حماية عُطّلت «لكي يعمل التطبيق محليًا» ولم تُفعَّل بعد ذلك أبدًا: هذا هو الحال اليومي في عمليات التدقيق.

Spring Security إطار عمل يجعل الأمان تصريحيًا (declarative). وهذه نقطة قوته وفخّه في آن واحد. نقطة قوته، لأن عشرة أسطر تكفي للحصول على نظام مصادقة سليم، يقاوم الهجمات الكلاسيكية، مع كلمات مرور مجزّأة (hashed) بالشكل المناسب. وفخّه، لأن هذه الأسطر العشرة تبدو كإعداد عادي لا خطر فيه، بينما يحسم كل سطر منها من يحق له قراءة ماذا.

لذلك يبدأ هذا الدرس بالنموذج قبل الصيغة. ستفهم أولًا أين يتدخل Spring Security في معالجة طلب HTTP، وأي كائن يمثل المستخدم الحالي، وكيف يميّز الإطار بين سؤالين نخلط بينهما باستمرار: «من أنت؟» و«هل يحق لك ذلك؟». وما إن يترسخ هذا النموذج حتى يتوقف الإعداد عن كونه تعويذة ويصبح قراءةً.

وأخيرًا، نقطة عاجلة: يضمّ Spring Boot 3 الإصدار 6 من Spring Security، وقد حُذف منه الصنف WebSecurityConfigurerAdapter. ومع ذلك لا تزال غالبية الأمثلة المتاحة على الويب تستخدمه، ولن تُترجَم برمجيًا (compile) عندك. القسم المخصص لهذا الموضوع أدناه سيوفر عليك على الأرجح أمسية كاملة.