Spring Securityの新標準!SecurityFilterChainとHttpSecurity DSLの書き方を初心者向けに解説
生徒
「Spring Securityの設定方法が最近変わったって聞いたんですが、どう変わったんですか?」
先生
「はい、従来のWebSecurityConfigurerAdapterは非推奨になって、今はSecurityFilterChainを使った構成が主流です。」
生徒
「難しそうですね…。初心者でもわかるように教えてください!」
先生
「それでは、HttpSecurity DSLとSecurityFilterChainの使い方を丁寧に見ていきましょう。」
1. Spring Securityの構成変更とは?
Spring Security 5.7以降、従来使用されていたWebSecurityConfigurerAdapterは非推奨となりました。
現在は、Java ConfigベースでSecurityFilterChainとHttpSecurity DSLを組み合わせる方式が標準です。
これにより、セキュリティ設定がより柔軟に、モジュール化しやすくなりました。初心者にとっては一見難しく感じるかもしれませんが、ポイントを押さえれば非常に便利です。
2. SecurityFilterChainとは?役割を理解しよう
SecurityFilterChain(セキュリティフィルタチェーン)は、Spring Securityの中で実際のリクエストを処理するフィルタの組み合わせを定義します。
HTTPリクエストが届くたびに、このフィルタチェーンがセキュリティルールに従って処理を行います。
このSecurityFilterChainは、@Beanで定義してHttpSecurityを使って細かく設定します。
3. HttpSecurity DSLの基本構文と役割
HttpSecurityは、リクエストに対するセキュリティポリシーを設定するためのクラスです。
「どのURLにどんなユーザーがアクセスできるのか」「ログイン・ログアウト処理はどうするか」などを、直感的にDSL(ドメイン特化言語)形式で記述できます。
実際の記述例は以下のようになります。
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/admin/**").hasRole("ADMIN")
.requestMatchers("/login", "/public/**").permitAll()
.anyRequest().authenticated()
)
.formLogin(withDefaults())
.logout(logout -> logout.logoutSuccessUrl("/"))
.csrf(csrf -> csrf.disable());
return http.build();
}
}
4. 新標準構成のメリットとは?
新しいSecurityFilterChain構成の最大のメリットは以下の通りです:
- 設定クラスがシンプルに分割可能:用途別にセキュリティ設定を分けられる
- Java Configと親和性が高い:DIコンテナとの統合が容易
- ユニットテストもしやすい:設定の一部だけテストできる
初心者でも、構成を段階的に理解することで柔軟なセキュリティルールが記述できます。
5. よく使うHttpSecurityの設定例
以下はHttpSecurityでよく使う設定パターンです。
フォームログインの有効化:
http.formLogin(form -> form
.loginPage("/login")
.defaultSuccessUrl("/dashboard", true)
.permitAll());
ログアウト処理のカスタマイズ:
http.logout(logout -> logout
.logoutUrl("/logout")
.logoutSuccessUrl("/login?logout"));
CSRF保護の無効化(注意して使用):
http.csrf(csrf -> csrf.disable());
CSRFを無効にすると一部のPOST通信が簡略化されますが、セキュリティ的にはリスクがあるので、本番環境では避けましょう。
6. Spring SecurityのURL保護設定
authorizeHttpRequestsでは、リクエストのパターンに応じたアクセス制限を行います。
よく使われる記述例としては以下のようなものがあります。
permitAll():誰でもアクセス可能authenticated():ログイン済ユーザーのみhasRole("ADMIN"):特定のロールを持つユーザーだけ
複数のURLをグルーピングして柔軟に保護できるのがHttpSecurity DSLの強みです。
7. SecurityFilterChainは複数定義できる
実はSecurityFilterChainは、条件に応じて複数定義することが可能です。
例えば、API用と画面用でセキュリティポリシーを分けるといった設計ができます。
以下はAPI用にCSRFを無効にし、HTTP Basic認証を使う例です:
@Bean
@Order(1)
public SecurityFilterChain apiSecurity(HttpSecurity http) throws Exception {
http
.securityMatcher("/api/**")
.authorizeHttpRequests(auth -> auth
.anyRequest().hasRole("API_USER")
)
.httpBasic(withDefaults())
.csrf(csrf -> csrf.disable());
return http.build();
}
このように、複数のセキュリティチェーンを分離することで、より柔軟な構成が可能になります。
8. Spring Security構成の注意点と実践ポイント
初心者がつまずきやすい点としては以下が挙げられます:
- URLマッチングの順番に注意(先にマッチした設定が優先されます)
csrf().disable()の使いすぎに注意permitAll()を使いすぎるとセキュリティが弱くなる
基本設定に慣れたら、ロール管理やOAuth2連携、セッション管理などにも徐々に取り組んでみましょう。
まとめ
Spring Securityの最新構成であるSecurityFilterChainとHttpSecurity DSLは、従来のWebSecurityConfigurerAdapterから大きく進化した形であり、より柔軟に、より拡張しやすいセキュリティ設定を実現できる点が特徴です。特にSpring Bootを使ったWebアプリケーション開発では、URL単位のアクセス制御、認証・認可処理、ログイン機能の組み込み、ログアウト処理の調整など、数多くのセキュリティ設定が必要になりますが、HttpSecurity DSLを使うことで読みやすく直感的な構文でこの設定を管理できるようになります。初心者にとって最初は難しく感じる部分もありますが、今回の記事で触れたように設定ポイントを順に追って理解していけば、自然と応用の幅を広げられるようになります。 また、SecurityFilterChainを複数定義できるという新しい仕組みにより、画面用・API用・管理画面用など、異なる責務を持つセキュリティポリシーを明確に分離できるようになりました。これにより、必要な部分だけセキュリティ設定を最適化し、無駄なフィルタ処理を回避してパフォーマンスを維持しながら、細かい要件に応じた保護を実現できます。加えて、HttpSecurity DSLが提供するauthorizeHttpRequests、formLogin、logout、csrf、sessionManagementなどのフレーズは、どれも視覚的に理解しやすく、まさに「セキュリティルールをコードでそのまま表現する」感覚で記述できます。 本文中で紹介したようなURL保護のパターンは実務でも頻繁に利用され、管理者専用画面、一般ユーザー向け画面、ログイン前の公開ページなど、役割に応じたアクセス制御を柔軟に設計できます。permitAllやauthenticated、hasRoleといったメソッドは短い記述で強力な制御を実現できるため、セキュリティ設定の流れを理解するうえで非常に重要な基礎となります。これに加えて、今後API開発が増える中で、Basic認証やToken認証なども組み合わせた複合的な設定が求められるため、SecurityFilterChainの複数定義はとくに大きな意味を持ちます。 また、セキュリティ設定を考えるうえで避けて通れないのがCSRFの扱いです。開発中は無効化する場面もありますが、実際には強固なセキュリティ保護の一部であり、本番環境では安易にdisableするべきではありません。今回の記事でも触れたように、便利な機能だからこそ慎重な運用が求められるのがSpring Securityの特徴です。セキュリティはアプリケーションの安全性に直結するため、正しい評価と適切な使い分けが非常に重要です。 以下では、今回学んだ内容を踏まえたサンプル構成として、複数SecurityFilterChainを利用した設定例をもう一度まとめて示します。
サンプルプログラム:画面用とAPI用にSecurityFilterChainを分割する例
@Configuration
@EnableWebSecurity
public class MultiSecurityConfig {
@Bean
@Order(1)
public SecurityFilterChain apiSecurity(HttpSecurity http) throws Exception {
http
.securityMatcher("/api/**")
.authorizeHttpRequests(auth -> auth
.anyRequest().hasRole("API_USER")
)
.httpBasic(withDefaults())
.csrf(csrf -> csrf.disable());
return http.build();
}
@Bean
public SecurityFilterChain webSecurity(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/", "/login", "/public/**").permitAll()
.anyRequest().authenticated()
)
.formLogin(form -> form
.loginPage("/login")
.defaultSuccessUrl("/dashboard", true)
)
.logout(logout -> logout.logoutSuccessUrl("/"))
.csrf(csrf -> csrf.disable());
return http.build();
}
}
このように、SecurityFilterChainを用途別に明確に分割することで、読みやすく管理しやすいセキュリティ構成が実現できます。Spring Securityの柔軟性は非常に高く、設定を理解するほど保護範囲の調整や認証方式の切り替えが容易になるため、Webアプリケーション開発における大きな武器となります。初心者の段階から最新の構成方法に触れておくことで、将来的に複雑なセキュリティ要件にも対応しやすくなります。 "セキュリティを理解すること" はWeb開発の基盤を理解することでもあり、今回の内容を土台に、OAuth2・JWT・セッション管理などさらに広い分野にも挑戦していくことができます。それでは最後に、記事全体の内容を振り返る形で、先生と生徒による理解確認の対話を見ていきましょう。
生徒
「SecurityFilterChainって最初は難しいと思っていましたが、用途ごとに設定を分けられると考えるとすごく便利ですね!」
先生
「そうなんです。HttpSecurity DSLは読みやすくて、設定の意図が明確に見えるのも良いところですよ。」
生徒
「URLパターンごとのアクセス制御やログイン設定もシンプルに書けて驚きました。これなら自分でも設定できそうです!」
先生
「PermitAllやhasRoleのような基本のメソッドを理解すれば、あとは組み合わせるだけで柔軟なルールが作れますよ。」
生徒
「CSRFを無効にするのが簡単なのは便利ですが、本番では慎重に使わないといけないという点もちゃんと覚えておきます!」
先生
「その調子です。セキュリティはアプリケーション全体の安全を守る最後の砦なので、正しく理解して設定していきましょう。」