Spring Securityのバージョンの違いとアップグレードポイントを初心者向けに解説！
新人
「先輩、Spring Securityってよく聞くんですけど、そもそも何をするものなんですか？」
先輩
「Spring Securityは、Webアプリケーションに認証や認可などのセキュリティ機能を組み込むためのフレームワークだよ。ログイン処理やアクセス制御が簡単にできるんだ。」
新人
「へぇ～。でも、Spring Securityのバージョンって結構たくさんあるみたいですね？違いがあるんですか？」
先輩
「もちろん！Spring Securityのバージョンによって書き方も変わるし、新しい機能が追加されたり、古い機能が廃止されたりしているから注意が必要なんだ。」
新人
「それって、バージョンアップしないと危険ってことですか？」
先輩
「うん、安全性を保つためにも定期的にSpring Securityをアップグレードするのが重要なんだ。じゃあ、まずSpring Securityの基本から確認していこうか。」
1. Spring Securityとは？（基本の役割と仕組み）
Spring Securityは、JavaのWebアプリケーションにセキュリティ機能を簡単に追加できるフレームワークです。特にSpring Bootと組み合わせて使われることが多く、ログイン認証やアクセス制限といった機能を少ない設定で実現できます。
Spring Securityの主な機能には、以下のようなものがあります。
- ログイン認証（フォーム認証、Basic認証、OAuth2など）
- ユーザーのロールによるアクセス制御（認可）
- セッション管理
- CSRF対策
- パスワードのハッシュ化
これらの機能を自作するのは大変ですが、Spring Securityを使えば多くの部分が自動で制御されます。
例えば、フォームログイン機能を設定するだけなら、設定ファイルで以下のように記述するだけです。
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/login", "/public").permitAll()
.anyRequest().authenticated()
.and()
.formLogin()
.loginPage("/login")
.defaultSuccessUrl("/home", true);
}
}
このように、@Configurationと@EnableWebSecurityで設定クラスを定義し、HttpSecurityを使ってルールを構成していきます。
2. なぜSpring Securityのバージョンアップが重要なのか（サポート期限や新機能の観点から）
Spring Securityのバージョンを放置していると、以下のようなリスクがあります。
- 既知の脆弱性が放置されてしまう
- 将来的にSpring BootやSpring Frameworkとの互換性が取れなくなる
- 新しい開発スタイル（Lambda式や構成変更）に対応できない
たとえば、Spring Security 5ではOAuth2のサポートが大幅に強化されました。Spring Security 6以降では、設定クラスにSecurityFilterChainを使うスタイルが推奨されています。以前のようなWebSecurityConfigurerAdapterは非推奨となっています。
Spring Securityのアップグレードを行うときは、次のような変更に注意が必要です。
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(authz -> authz
.requestMatchers("/login", "/public").permitAll()
.anyRequest().authenticated()
)
.formLogin(form -> form
.loginPage("/login")
.defaultSuccessUrl("/home", true)
);
return http.build();
}
}
このように、Spring Security 6ではJavaのラムダ式による記述に変更されています。また、GradleでSpring Securityの依存関係を追加するときは、以下のようにします。
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-security'
}
Spring Securityのバージョン違いに応じて、設定の書き方や使える機能が異なるため、古いままにしておくとチーム内での認識にズレが出ることもあります。特に、ドキュメントやサンプルコードを参考にする際には、どのバージョンを対象としているかを確認することがとても重要です。
また、Spring公式のサポートポリシーでは、定期的なアップグレードが推奨されています。バージョンアップをすることで、セキュリティ的にも安心ですし、新しい記述方法や機能も学べて開発効率も向上します。
開発環境がPleiadesであれば、依存関係の追加もGUIで簡単にできるので、バージョンアップも難しくありません。
以上の理由から、Spring Securityのアップグレードは単なる保守作業ではなく、プロジェクトの安全性・成長性を保つ重要なステップなのです。
3. Spring Security 5系と6系の主な違い（構成・依存関係の変化）
Spring Securityのバージョンアップにおいて、5系から6系への移行は非常に大きな変更点が含まれています。特にWebSecurityConfigurerAdapterの非推奨化や、構成の書き方の変更が目立ちます。まずはその違いを初心者向けにやさしく説明していきましょう。
Spring Security 5系では、設定クラスにWebSecurityConfigurerAdapterを継承してセキュリティ設定を行うのが一般的でした。この方法はシンプルで、必要な設定をconfigure()メソッドに書くだけで良かったため、多くのプロジェクトで使われてきました。
しかし、Spring Security 6系では、このWebSecurityConfigurerAdapterが非推奨となり、構成方法が大きく変わりました。代わりに、Javaのラムダ式を使ってSecurityFilterChainというBeanを定義し、設定を行う方式が推奨されています。
まず、5系の構成例をもう一度見てみましょう。
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/login", "/public").permitAll()
.anyRequest().authenticated()
.and()
.formLogin();
}
}
これに対し、Spring Security 6系では以下のように書き換えます。
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(authz -> authz
.requestMatchers("/login", "/public").permitAll()
.anyRequest().authenticated()
)
.formLogin(Customizer.withDefaults());
return http.build();
}
}
このように、6系ではauthorizeHttpRequests()などがラムダ式で記述され、設定内容がより柔軟に書けるようになりました。
また、依存関係の記述には特別な変更はありませんが、6系ではSpring Boot 3以降と組み合わせることが前提となるため、依存ライブラリの互換性には注意が必要です。
Gradleでの記述例は以下のとおりです。
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-security'
}
この記述は5系でも6系でも同じですが、Spring Boot自体のバージョンに応じて、自動的に適切なSpring Securityが使用される仕組みです。
このように、構成方法の違いを理解することで、バージョンアップ後の移行もスムーズになります。
4. バージョンアップ時に注意すべきポイント（設定ファイルやコードの変更）
Spring Securityのバージョンアップを行う際には、単に依存関係を更新するだけではなく、設定ファイルやコードに含まれる記述を見直す必要があります。特に5系から6系へのアップグレードでは、次のような点に注意してください。
① WebSecurityConfigurerAdapterの廃止
前述の通り、Spring Security 6ではWebSecurityConfigurerAdapterは廃止され、使用しないよう求められています。代わりにSecurityFilterChainをBeanで定義し、設定はラムダ式で行います。
また、authorizeRequests()というメソッド名も、6系ではauthorizeHttpRequests()に変更されているため注意が必要です。
// Spring Security 6での設定例
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(authz -> authz
.requestMatchers("/admin/**").hasRole("ADMIN")
.anyRequest().authenticated()
)
.formLogin(form -> form
.loginPage("/login")
.defaultSuccessUrl("/dashboard")
);
return http.build();
}
② requestMatchers()の書き方の変化
以前はantMatchers()というメソッドを使ってURLパターンを指定していましたが、6系ではこれがrequestMatchers()に統一されました。
つまり、以下のように書き換える必要があります。
// Spring Security 5
.antMatchers("/admin/**").hasRole("ADMIN")
// Spring Security 6
.requestMatchers("/admin/**").hasRole("ADMIN")
この変更は細かいようですが、正しく書かないとアクセス制限が機能しなくなるため、確実に書き換える必要があります。
③ passwordEncoderの記述方法も見直しを
Spring Securityでは、パスワードのハッシュ化にPasswordEncoderを使います。BCryptPasswordEncoderが一般的ですが、定義方法もバージョンにより変化することがあります。
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
このようなBean定義は、バージョン問わず共通で使えますが、バージョンアップ時に再確認することで設定漏れを防げます。
④ csrf設定の変更もチェック
Spring Securityでは、CSRF（クロスサイトリクエストフォージェリ）対策がデフォルトで有効になっています。6系では、設定の記述が若干変更されており、CSRFを無効化する場合も以下のようにラムダ式で記述します。
http.csrf(csrf -> csrf.disable());
このように、構成のほとんどがラムダ式化されているため、5系から6系にバージョンアップする際は、記述の書き換えが必要不可欠です。
⑤ @Controllerの活用も忘れずに
Spring Securityの設定だけでなく、@Controllerを使った画面遷移の実装も見直しましょう。ログインページなどを自作する場合、以下のように定義できます。
@Controller
public class LoginController {
@GetMapping("/login")
public String loginPage() {
return "login";
}
@GetMapping("/dashboard")
public String dashboard() {
return "dashboard";
}
}
このように、ログインページとダッシュボード画面をそれぞれ@Controllerでマッピングしておくことで、ログイン成功時の画面遷移がスムーズになります。
Spring Securityのバージョンアップでは、コードの一部だけでなく、全体の構成を見直す必要があります。そのため、少しずつ確認しながら変更していくのが安全です。
バージョンアップによって得られるメリットも多く、今後のセキュリティアップデートにも対応しやすくなるので、プロジェクト全体としても非常に重要な作業です。
5. Spring Securityのバージョンアップ手順（Gradle＋pleiades前提で解説）
ここでは、Pleiadesを使った開発環境で、Spring Securityを安全にバージョンアップする具体的な手順を解説します。Gradleを使っている前提で、初心者の方にもわかりやすく進めていきましょう。
① プロジェクトのバックアップを取る
最初に必ずやるべきことは、現在のプロジェクトのバックアップです。Spring Securityのバージョンアップでは設定ファイルやコードの記述が大きく変わることがあるため、元に戻せるようにしておくことが重要です。
② Pleiadesのプロジェクト設定を確認
Pleiades上で作成したSpring Bootプロジェクトであることを確認します。また、build.gradleファイルをPleiades内のエディタで開けることを確認してください。
③ Gradleの依存関係を変更する
次に、build.gradleに記述されたSpring Security関連の依存関係を最新バージョンに変更します。以下のように編集します。
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-security'
}
バージョン指定は省略してもSpring Bootのバージョンに応じた最新のSpring Securityが自動的に適用されます。もし特定のバージョンを明示したい場合は、バージョンを指定しても構いません。
④ Gradleの同期を実行する
依存関係を変更したら、Gradleの同期を行います。Pleiadesのプロジェクトエクスプローラーでプロジェクトを右クリックし、「Gradle」→「Refresh Gradle Project」を実行します。
⑤ コンパイルエラーと設定ファイルの見直し
バージョンアップ後にコンパイルエラーが出る場合は、古い書き方（WebSecurityConfigurerAdapterなど）を使っていないか確認しましょう。新しい構成方式に従って記述し直す必要があります。
⑥ 動作確認とテストの実施
アプリケーションを起動し、ログイン画面やセキュリティ制御が正しく機能しているかを確認します。ブラウザで/loginにアクセスし、期待通りの画面が表示されれば成功です。
6. バージョンごとの移行対応チェックリスト
Spring Securityのバージョンアップをスムーズに行うためには、対応すべき項目をリスト化しておくと便利です。ここでは、Spring Security 5系から6系への移行で見直すべきポイントを一覧にまとめました。
- WebSecurityConfigurerAdapterを使っていないか確認
- authorizeRequests() → authorizeHttpRequests()への書き換え
- antMatchers() → requestMatchers()への変更
- 設定クラスに
SecurityFilterChainの@Beanを追加 formLogin()やlogout()などの設定をラムダ式で記述- CSRF設定：
csrf(csrf -> csrf.disable())のように記述変更 - 独自
LoginControllerでログインページ遷移を明示 - 依存関係に
spring-boot-starter-securityが最新か確認 - 画面遷移先のテンプレート（login.htmlなど）が存在するか確認
- テストコードでセキュリティ周りの動作確認も実施
このようなチェックリストを使って順に確認すれば、Spring Securityの移行作業も迷うことなく進められます。
7. 安全に移行するためのコツとトラブル対策
Spring Securityのバージョンアップは、セキュリティを強化するうえで非常に重要ですが、一歩間違えるとアプリケーションが正しく動作しなくなるリスクもあります。ここでは、トラブルを防ぎながら安全に移行するためのコツを紹介します。
① 小さな変更単位で作業する
一度にすべての設定を書き換えるのではなく、1つずつ変更して、そのたびに動作確認を行うとトラブルを早期に発見できます。
② 旧設定と新設定の比較を残しておく
バージョンアップの際は、変更前の設定ファイルを別名で保存し、差分を見比べながら進めると理解が深まります。
③ Spring公式ドキュメントを活用
Spring Securityの設定変更は公式ドキュメントが一番詳しい情報源です。「Spring Security 移行方法」や「Spring Security 設定変更」などで検索し、公式のガイドを参考にしましょう。
④ コンソールログのWARNやERRORに注目
起動時のログ出力に表示される警告やエラーはヒントの宝庫です。たとえば非推奨なメソッドを使っていると警告されることがあります。
⑤ エラー例とその対応策
ここではよくあるトラブルとその解決方法を紹介します。
- エラー：WebSecurityConfigurerAdapterが見つからない
→ 対応：SecurityFilterChainによる設定に変更が必要 - エラー：antMatchersが存在しない
→ 対応：requestMatchersに書き換える - 問題：ログイン後に画面が真っ白になる
→ 対応：defaultSuccessUrl()でリダイレクト先を明示 - 問題：ログイン画面が表示されない
→ 対応：LoginControllerで/loginマッピングを設定
Spring Securityのトラブルは、設定ファイルの記述ミスやバージョンによるメソッドの非互換が原因であることが多いです。冷静にログを読み、公式ドキュメントやチェックリストを活用して対応しましょう。
バージョンアップ作業を丁寧に行えば、アプリケーションの安全性と将来性が大きく向上します。「Spring Security トラブル対応」としても、この記事の内容はきっと役立つはずです。
まとめ
Spring Securityのバージョン違いとアップグレードの重要性を振り返る
本記事では、Spring Securityとは何かという基本から始まり、バージョンごとの違い、特にSpring Security 5系と6系の構成変更、 そして安全にアップグレードするための具体的な手順や注意点までを段階的に解説してきました。 Spring Securityは、ログイン認証やアクセス制御、CSRF対策、パスワードのハッシュ化など、 Webアプリケーションの安全性を支える中核的な役割を担っています。 そのため、バージョンを古いまま放置することは、セキュリティリスクの増大や将来的な互換性問題につながります。
特に印象的なのは、Spring Security 6系での大きな設計思想の変化です。 これまで多くの開発者に親しまれてきたWebSecurityConfigurerAdapterが廃止され、 SecurityFilterChainを@Beanとして定義し、ラムダ式で設定を書くスタイルが標準となりました。 これにより、設定の自由度が高まり、コードの可読性や保守性も向上しています。 一方で、antMatchersからrequestMatchersへの変更など、細かな書き換えが必要になる点は、 バージョンアップ時の落とし穴になりやすい部分でもあります。
また、Spring Bootとの関係性も重要なポイントです。 Spring Security単体でバージョンを管理するのではなく、 Spring Bootのバージョンに応じて自動的に適切なSpring Securityが選ばれる仕組みを理解しておくことで、 依存関係のトラブルを避けやすくなります。 Gradleでspring-boot-starter-securityを指定するだけでよいという点は初心者にとって心強い反面、 内部でどのバージョンが使われているかを意識する姿勢も大切です。
アップグレード時に身につけたい実践的な考え方
Spring Securityのバージョンアップは、単なるライブラリ更新作業ではありません。 セキュリティ設定全体を見直し、「なぜこの設定が必要なのか」「どのURLにどんな制限をかけているのか」を 改めて理解する良い機会でもあります。 チェックリストを活用しながら、WebSecurityConfigurerAdapterの使用有無、 authorizeHttpRequestsの書き方、requestMatchersの指定内容、CSRF設定、 LoginControllerによる画面遷移などを一つひとつ確認することで、 設定漏れや想定外の挙動を防ぐことができます。
以下は、この記事で学んだ内容を踏まえた、シンプルなまとめ用のSpring Security 6系設定例です。 実際のプロジェクトでも応用しやすい構成になっています。
@Configuration
@EnableWebSecurity
public class SummarySecurityConfig {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(authz -> authz
.requestMatchers("/login", "/public").permitAll()
.anyRequest().authenticated()
)
.formLogin(form -> form
.loginPage("/login")
.defaultSuccessUrl("/home", true)
)
.csrf(csrf -> csrf.disable());
return http.build();
}
}
このように、Spring Security 6では設定内容がコード上で明確に読み取れるようになっています。 初心者の方は、まずこの形に慣れ、設定項目一つひとつの意味を理解することが、 安全で信頼性の高いWebアプリケーション開発への近道です。
生徒
「Spring Securityって難しそうだと思っていましたけど、 バージョンごとの違いを整理して見ると、何を直せばいいのかが分かってきました。」
先生
「それは良い理解だね。特に5系から6系への移行は大きな変化だから、 構成の考え方を一度リセットして学び直すのが大切なんだ。」
生徒
「WebSecurityConfigurerAdapterが使えなくなった理由も分かりました。 SecurityFilterChainで設定を書くほうが、確かに流れが読みやすいですね。」
先生
「その通り。ラムダ式に慣れると、どのURLにどんな制限をかけているかが一目で分かるようになるよ。」
生徒
「これからは、ただ動けばいいじゃなくて、 なぜこのSpring Security設定が必要なのかを説明できるように意識します。」
先生
「それができれば一人前だね。 Spring Securityのバージョンアップを通して、セキュリティ設計の考え方も身についていくはずだよ。」
この記事を読んだ初心者からの質問集
