なぜ、あなたのWebサイトは「見知らぬ誰か」に操作されるのか？ ― CSRFから身を守るSpring Securityの流儀
こんにちは！セキュリティの現場で日々「見えない泥棒」と戦っているエンジニアです。
今日は、Webアプリケーション開発の登竜門であり、避けては通れない「CSRF（クロスサイト・リクエスト・フォージェリ）」についてお話しします。名前は難しそうですが、仕組みを知れば「なるほど、家の防犯と同じか！」と腑に落ちるはずですよ。
一歩ずつ、安全な開発の世界へ足を踏み入れていきましょう。
—
1. CSRFとは何か？ 「偽造された依頼」の恐怖
皆さんの自宅を想像してみてください。あなたは玄関の鍵をしっかり閉めていますよね。でも、もし「合鍵」を勝手に作られて、泥棒が堂々と玄関から入ってきたらどうでしょう？
Webの世界でのCSRFは、まさにこれです。
ブラウザは「自分がログインしたサイト」に対しては、自動的に「ログイン証明（セッション情報）」を添えてリクエストを送ります。攻撃者は、この「ブラウザが勝手にやってくれる便利機能」を悪用します。
1. あなたが銀行のサイトにログインしている。
2. 悪意のあるサイト（罠サイト）をうっかり開いてしまう。
3. 罠サイトが、あなたのブラウザに「銀行の振込ボタンを勝手に押させる」命令を出す。
4. ブラウザは、あなたがログイン中なので「正当なリクエスト」だと判断し、セッション情報を添えて銀行に送信してしまう。
これがCSRFのメカニズムです。「あなたは悪くないのに、ブラウザの親切心によって勝手に操作されてしまう」というのが、この攻撃の恐ろしいところなんです。
—
2. Spring Securityの「CSRFトークン」という名の合言葉
この泥棒を防ぐために、Spring Securityには強力な武器が標準装備されています。それが「CSRFトークン」です。
これは、「そのページを表示した本人しか知らないはずの、使い捨ての合言葉」のこと。
- フォームを送信する際、サーバーは「このリクエストが本当に正しい画面から来たものか？」を確認するために、この合言葉をチェックします。
- 罠サイトは、銀行のページを自由に覗き見ることができないので、この「合言葉（トークン）」を知ることができません。
- 合言葉がない、あるいは間違っているリクエストは、サーバー側で「門前払い」します。これで泥棒の侵入は阻止できるわけです。
—
3. 実装の現場：Spring Securityでの自動化
幸いなことに、Spring Securityを使っていれば、この仕組みは驚くほど簡単に実装できます。設定ファイル（`SecurityFilterChain`）で、以下のように書くだけです。
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
// CSRF対策を有効にする（デフォルトで有効ですが、明示的に書くと安心です）
.csrf(csrf -> csrf
.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
);
return http.build();
}
この設定のポイント
- `CookieCsrfTokenRepository.withHttpOnlyFalse()`: ここが重要です。フロントエンド（JavaScript）からトークンを読み取れるようにするための設定です。ReactやVue.jsなど、モダンなフロントエンドを使っている場合は、この設定が不可欠になります。
- 自動挿入: HTMLの`
—
4. REST APIで「無効化」する際のリスクを知ろう
最近は画面を持たない「REST API」での開発も多いですよね。APIの場合、CSRF対策をあえて無効にする（`.csrf().disable()`）ケースを見かけます。
ちょっと待ってください！ それ、本当に安全ですか？
もし、そのAPIが「Cookieベースの認証（セッション認証）」を使っているなら、無効化はNGです。セッションを使っている以上、ブラウザは依然としてCSRF攻撃の標的になります。
もしAPIでCSRF対策を無効にするなら、それは「JWT（JSON Web Token）など、Cookieを使わない認証方式に完全に切り替えた時だけ」にしましょう。
「とりあえず動くからオフにする」というのは、家の玄関の鍵を「開け閉めが面倒だから」といって外してしまうのと同じです。
—
まとめ：セキュリティは「当たり前」を積み重ねること
CSRF対策は、一度実装してしまえば、あとはSpring Securityが黙々とあなたを守り続けてくれます。
1. セッション認証ならCSRF対策は必須。
2. Spring Securityのデフォルト機能を信頼する。
3. 無効化するなら、リスクを正しく理解する。
セキュリティに「100%」はありませんが、「99%の泥棒を門前払いできる仕組み」は作れます。今日から、皆さんのアプリケーションにもこの「合言葉」の仕組みを取り入れてみてくださいね。
皆さんの書くコードが、今日も誰かの安全を守りますように！
コメント