対象：Java／Spring Boot でアプリを運営している人。ここでは攻撃手順は扱わず、本番を固めるための実務リファレンス（優先度つきチェックリスト・領域別対策・自己検証）を示します。フレームワーク全体の考え方は フレームワーク別セキュリティの入口 も参照。
優先度つきハードニング・チェックリスト
まずこの表を上から実施します。P0は前提、P1が最頻の事故源、P2は継続的な運用衛生です。
P0 ── 前提（まずこれ）
依存CVE監視＋即パッチ ／ 本番でエラー詳細を出さない ／ 秘密を外部化
P1 ── 最頻の事故源
Spring Security の認可（既定拒否・所有者チェック）／ Actuator・管理面の露出削減
P2 ── 運用衛生
安全でないデシリアライズ ／ ヘッダ・CSRF・セッション ／ SSRF
| 優先 | 対策 | 具体（Spring Boot） |
|---|---|---|
| P0 | 依存CVE監視 | osv-scanner / dependency-check で監視・実稼働版で判定し即パッチ（Log4Shell系） |
| P0 | 本番エラー | スタックトレースを外部に出さない（server.error.include-stacktrace=never 等） |
| P0 | 秘密の外部化 | 接続情報/鍵を設定ファイルへ直書きせず環境変数/Vault等から。リポジトリにコミットしない |
| P1 | 認可を明示 | Spring Security で既定拒否＋メソッド認可（@PreAuthorize）＋所有者チェック |
| P1 | Actuator 露出削減 | 公開を最小に（health程度）＋認証必須＋別ポート/境界。env/heapdump等を公開しない |
| P1 | デシリアライズ | 信頼できないデータをネイティブにデシリアライズしない。SpEL等に入力を評価させない |
| P2 | インジェクション | JPA/JdbcTemplate でバインド。文字列連結でクエリを組まない |
| P2 | ヘッダ/CSRF/セッション | Spring Security のヘッダ（HSTS等）・CSRF・Cookie属性・セッション固定対策 |
| P2 | SSRF | サーバー側の外部取得は許可先限定＋内部IP/メタデータ遮断 |
1. 依存CVEとエコシステム（P0）
Spring は広く使われるからこそ、依存ライブラリの穴が一斉に波及します。Log4Shell はその象徴です。
- 依存のCVEを osv-scanner や OWASP dependency-check で機械監視し、実稼働版で判定して素早くパッチする（pom.xml/gradle の宣言でなく実際に入っている版で判断）。
- Spring Boot と Java をサポート対象バージョンに保つ。EOL版を放置しない。
- 実例と実務は Log4Shellの解剖 ／ 脆弱性対応の実務 ／ 依存のCVE監視。
2. 本番設定と秘密（P0）
- 本番ではエラーの詳細（スタックトレース）を外部に出さない。内部構造や依存の版が漏れる手がかりを減らす。
- 接続情報・鍵などの秘密は application.properties/yml に直書きせず、環境変数や秘密管理（Vault等）から注入する。リポジトリにコミットしない（→ .envと秘密情報）。
- 開発用ツール（devtools 等）を本番で有効にしない。
3. Spring Security の認可（P1・最多の事故源）
やりがち（危険）
- 既定が緩く、明示許可の設計になっていない
- URLパターンだけで守り、メソッド/所有者チェックが無い
- 認証はあるが「ログイン＝操作可」
- 設定漏れで一部エンドポイントが素通り
正しい
- 既定拒否（明示的に許可したものだけ通す）
- メソッド認可（
@PreAuthorize等）＋所有者チェック - 取得・更新・削除のすべての経路で権限/所有者を確認
- 認可は明示的に組み立て、既定任せにしない
用語は IDORとは。認証と認可は別物で、認可はデータに近い場所で確認します。
4. Actuator と管理エンドポイント（P1）
- 公開する Actuator エンドポイントを必要最小限（例：health）に絞る。
- 認証・認可を必須にし、外部から到達できない別ポート/ネットワーク境界に置く。
env・heapdump・loggersなど機微なエンドポイントを公開しない（情報漏えい・操作の踏み台になり得る）。
5. 安全でないデシリアライズと式評価（P2）
- 信頼できないデータをネイティブにデシリアライズしない（条件次第でRCEに繋がり得る）。由来を検証し、必要なら JSON 等の安全な形式に限定する（→ RCEとは）。
- テンプレートや SpEL にユーザー入力を評価させない。入力は Bean Validation 等で検証する。
6. インジェクションとデータアクセス（P2）
- SQL：JPA / JdbcTemplate でバインドし、文字列連結でクエリを組まない（→ SQLインジェクションとは）。
- テンプレートでHTMLを出す場合は出力エンコードを通し、ユーザー入力をそのまま埋め込まない（XSS対策）。
7. ヘッダ・HTTPS・セッション（P2）
- Spring Security のセキュリティヘッダ（HTTPS時のHSTS等）を活かす。自サイトの状態は セキュリティヘッダ診断 で確認。
- HTTPS強制。ロードバランサ配下では正しいスキーム/クライアントIPを認識させる設定を行う。
- Cookie に Secure/HttpOnly/SameSite、CSRF保護（ブラウザセッションでは既定で有効。APIで無効化するなら代替の対策を伴う）、ログイン時のセッション再生成。
8. SSRF とサーバー側の外部取得（P2）
- サーバーがユーザー指定URLを取得する処理は許可先を限定し、接続時に内部IP／クラウドのメタデータへの到達を遮断する（→ SSRFとは）。
検証：自分のSpring Bootは固められているか
作ったら終わりでなく、点検して初めて完了です。以下は自分の環境に対する防御的な自己チェックです。
Actuator が機微を公開していないか
/actuator 配下に env/heapdump 等が公開されていないこと、認証がかかっていることを確認。エラーで内部が出ないか
認可が効くか
依存とヘッダ
当サイトの視点：堅い基盤ほど『依存と公開面』が勝負
Spring は堅い基盤ですが、広く使われるからこそ依存ライブラリの穴が一斉に波及します。Log4Shell はその象徴で、守りの本命は特定の設定より「依存を機械監視して実稼働版で判定し、素早くパッチする」運用にあります。あわせて、便利な管理エンドポイント（Actuator）を公開面から外し、認可を既定任せにしない。当サイトは別スタックですが原則は同じ——依存の鮮度・公開面の最小化・認可の明示は、フレームワークを問わず効く普遍の守りです。
次に読む
- 入口：フレームワーク別セキュリティ（入口） ／ Next.jsのセキュリティ対策
- 事例・実務：Log4Shellの解剖 ／ 脆弱性(CVE)対応の実務 ／ 依存のCVE監視
- 用語：IDORとは ／ RCEとは ／ SSRFとは
- ツール：セキュリティヘッダ診断
よくある質問
QSpring Bootで最初にやるべきセキュリティ対策は何ですか？
優先度P0の3つです。(1)依存ライブラリのCVEを機械監視し実稼働版で判定して即パッチする（Log4Shellのように土台のライブラリが継承されて一斉に影響するため追従の速さが要）、(2)本番でエラーの詳細（スタックトレース）を外部に出さない、(3)秘密（接続情報・鍵）を設定ファイルへ直書きせず外部化する。次に Spring Security の認可と Actuator の露出削減へ進みます。
QActuator で気をつけることは？
Actuator は稼働情報や診断の管理エンドポイントですが、公開されると内部情報の漏えいや、設定によっては操作の踏み台になり得ます。本番では公開範囲を必要最小限に絞り（例：health 程度）、認証・認可を必須にし、外部から到達できないネットワーク境界や別ポートに置くのが基本です。env・heapdump・loggers など機微なエンドポイントを公開しないこと。
QLog4Shell のような依存の穴にどう備えますか？
Log4Shell は、広く継承されるログライブラリの穴が多数のアプリへ一斉に波及した典型例です。備えの本命は、依存のCVEを機械監視し『実稼働版』で判定して素早くパッチすること（osv-scanner や OWASP dependency-check 等）。pom.xml/gradle の宣言でなく、実際にビルドされている版で判断します。最小権限やネットワーク分離で爆発半径も小さくします。
QSpring Security の認可はどう書けば安全ですか？
既定を『拒否』側に寄せ（明示的に許可したものだけ通す）、URLパターンだけに頼らず、必要に応じてメソッドレベルの認可（@PreAuthorize 等）を使います。ログイン（認証）に加えて、対象リソースが本当にその利用者のものかという所有者チェックを実装します。設定漏れが権限昇格の穴になるため、認可は明示的に組み立てるのが安全です。
Q安全でないデシリアライズはなぜ危険ですか？
信頼できないデータを Java のネイティブなデシリアライズ等で復元すると、条件次第でリモートコード実行(RCE)に繋がり得ます。外部由来のデータをそのまま復元せず、由来を検証し、必要なら JSON など安全な形式に限定します。テンプレートや式言語(SpEL)にユーザー入力を評価させないことも同様に重要です。