実際のハッキング事故から学ぶSpring Boot・Expressのセキュアコーディング

あなたが管理するサイトも、今まさに攻撃されています

【あわせて読みたい記事】

- velog連載「ハッキング手法 VS 防御方法」: https://velog.io/@bumicklee/series/defense

インターネットに公開されたサーバーには、自動化されたスキャナーやボットからのリクエストが毎日届きます。ログインページには流出したパスワードが絶え間なく入力され、注文番号を一つずつ変えながら他人の注文を開いてみる者もいます。

問題は攻撃が来るかどうかではありません。今この瞬間にも来ています。本当の問いは3つです。

1. そのリクエストは通りますか？200が返ってきた時点で、すでに突破されています。

2. 気づけますか？午前3時、誰もログを見ていません。

3. ブロックされたことを証明できますか？ 「修正しました」ではなく、テスト結果で。

この講義では、3つの質問にコードで答えます。

AIハッキング自動化時代を生き抜く方法

2026年10月、ソウル警察庁は、AIを活用したハッカーが約90カ所から約820万件の情報を盗み出した一連の侵害について発表しました（捜査中のため、数値は変わる可能性があります）。

AIが新たな魔法を使ったわけではありません。ハッカーが以前は見つけられなかった弱点を素早く見つける手助けをするだけです。自動化された攻撃にもパターンがあり、狙われる場所は以前と同じです。そのパターンを把握して事前に対策しておけば、AIがどれだけ速く探しても、見つけられる弱点は少なくなります。

ニュースで報じられたハッキング事故、私たちのコードならどこで起きていたでしょうか？

SK TelecomのUSIM情報流出、Coupangの3,367万件の個人情報流出、TVINGのアクセスキー露出、Lotte Cardへのハッキング、GS Retailのクレデンシャルスタッフィング、Binanceの64億ドル。

事故のニュースは毎週のように届きます。しかし、記事をいくら読んでも、「それで、自分のコードのどこを直せばいいの？」という問いには答えが見つかりません。

この講義は、その問いにコードで答えます。実際のオープンソースのショッピングモールを自分のPC上で起動し、22件の事故がこのコードのどこで発生するのかを自分で再現します。そして一件ずつ防ぎ、防げたかどうかをテストで確認します。

有名なオープンソースも安全ではありません

この講義では、簡単なおもちゃの例ではなく、GitHubで数万個のスターを獲得している実在のオープンソースECサイトを使って実習します。Spring BootのECサイトmall（スター8万個以上）とExpressのECサイトEverShop（スター1万個以上）です。

しかし、この有名なソースを初めて点検したところ、74件の問題が見つかりました。Spring Boot側が48件、Express側が26件です。その中には、次のような致命的な問題もありました。

• 注文番号を書き換えるだけで、他人の注文が開けてしまう

• ログイン済みの会員なら誰でも「決済完了」にできる。

• SMS認証番号がAPIレスポンスに含まれている

• 署名のないトークンも通ってしまう

オープンソースを取り入れた瞬間、その脆弱性も自社サービスに入り込みます。この講義では、このチェックリストに沿ってSpring BootとExpressのコードを一つずつ修正し、防御力を高めます。他人が作ったコードから問題を見つけ出す目が、自社のコードを守る力になります。（チェックリストには、元のコードで確認した脆弱性、デモのデフォルト設定、実習のために追加した運用設定のミスが含まれています。）

Spring BootとExpress、両方を扱います

• Spring Boot（本編）：15のセクション、96のレッスンで、再現→修正→テスト→検知ログまで、すべて自分の手で修正します。

• Express:本編の各レッスンでExpressの同じ箇所の修正diffを示し、DockerなしでNode.jsだけで動くExpressミニ演習18個で同じ攻撃を実際に防ぎます。セクション16では、インストールから一通りの演習まで動画を見ながら進めます。

• チーム内に2つのスタックが混在していても心配ありません。防御の原理は同じで、同じテストで防げたかどうかを確認します。

Express開発者向けの追加講義：セクション16

Expressを使う方向けに、セクション16「Expressで実習を始める」（全6回）を別途用意しました。DockerもDBサーバーも必要ありません。Node.js 24があれば大丈夫です。

セクション16を終えると、Expressミニ演習18個に取り組みます。本編と同じ講義番号で、他人の注文の閲覧、公開された管理者用URL、Mass Assignment、SSRF、SQLインジェクション、XSS、パスワード総当たり、トークンの有効期間、デフォルトのシークレット値、エラーレスポンス、監査記録、ログのマスキング、クーポンの同時使用をExpressのコードで実際に防ぎます。コマンドと実行結果は「Express実践PDF」に、原理と修正前後の図は「Express初心者向け講義教材PDF」にまとめてお届けします。

Expressの授業動画は公開後も追加されます。セクション17「Expressで防いでみる」（13本）とセクション18「Expressユーザー向け補強」（4本：ミドルウェアの順序、非同期エラー、Cookieとセッション、npm依存関係）をアップデートで追加する予定です。動画の確認はmacOSで行いました。

ハッキングはもはやニュースではなく、開発者の仕事です

• 事故が起きたとき、真っ先に呼び出されるのはそのコードを書いた開発者です。防いだ経験のある開発者とない開発者の違いは、事故が起きた日に明らかになります。

• AIがコードを素早く書いてくれる時代だからこそ、そのコードが安全かどうかを判断し、証明する能力が開発者の価値になります。この講義は、その能力を実践を通じて身につける時間です。

こんなお悩みはありませんか？

• 「セキュリティを学ぶ必要があるのはわかっていますが、どこから手をつければいいのかわかりません。」 → セクション1では、攻撃の全体像と脅威モデリングを通じて、自分のサービスでまず確認すべき箇所を決めます。

• 「OWASP Top 10は読んでみたけれど、自分たちのコードでそれがどう現れるのかわかりません。」 → おもちゃのサンプルではありません。GitHubで8万以上のスターを獲得したSpring Bootのショッピングモールmallをフォークした「ダオンマーケット」のコードを、会社のコードのように修正します。

• 「修正はしたけれど、本当に防げているのか自信がありません。」 → 同じ攻撃の再現が【レッド】から【グリーン】に変わり、授業のテストとスコアボードで数値として確認できます。

• 「事故が起きたら何をすればいいのかわかりません。セキュリティチームもいません。」 → 検知ルール、アラート対応ランブック、最初の1時間の手順、個人情報漏えいの報告要否の判断まで、実際に練習します。

この講義を終えたときに手元に残るもの

講義を最後まで受講すると、聞いて終わる知識ではなく、会社のサービスにすぐ活用できる成果物が手に入ります。

1. 脆弱性37件をすべて修正したショッピングモールの最終ソースコード

開始時のスコアボードは「脆弱性37件」です。セクションを一つずつ進むたびに数字が減り、最後のレッスンでは0件になります。すべての対策を施した最終ソースは、自分のサービスの基準コードとして使えます。所有権チェックをどこに置くのか、シークレットをどう読み込むのか、決済コールバックをどう冪等に処理するのか、行き詰まるたびに開いて確認できる参考書になります。

2. 会社のサービスに組み込む防御部品 secure-kit

授業で手作業で修正した防御コードを、内容ごとに使える部品として整理しました。Spring Bootではスターター依存関係と設定で、Expressではミドルウェアとして組み込みます。必要な部品だけ選んで有効にできます。

3. 漏えいを早期に検知するルール

防止攻撃のコードとともに攻撃の兆候を示すログも仕込みます。他人の注文を照会しようとする試み、大量照会、内部アドレス宛てのリクエストといったシグナルをログに記録し、Grafanaのダッシュボードとアラートルールに反映します。クーパンの事故では、情報漏えいが発覚するまで数カ月かかりました。この講義では、異常に気づくまでの時間を短縮する方法を学びます。

4. 構造の変更を提案できる根拠

コードだけを修正するのではありません。アプリとDBだけがある初期状態（A0）に、ゲートウェイ、ネットワーク分離、イグレスプロキシ、シークレットストア（OpenBao）、ログアラート（Loki・Grafana）、イミュータブルバックアップ（MinIO）を一つずつ追加し、A11まで拡張します。会社で「構造をこう変えましょう」という提案書を書く際、そのまま根拠として使えます。

5. 事故発生時に取り出して使うドキュメント

• 警報が鳴ったときに上から順に実行するランブック6種（インシデント発生後最初の1時間、大量照会、所有権の否認、監査ログの完全性、パートナーによる大量エクスポート、アラート対応）

• テンプレート7種（攻撃対象領域マップ、初動調査報告書、インシデント発生後30分の整理、情報漏えい報告の判断、情報漏えい通知文、キャップストーンのタイムライン、振り返り）

• 60個の質問で自分のサービスを点検するオンラインチェックシート

6. インシデントを見る目

講義が終わる頃には、ニュースで新たな事故が報じられたとき、「自分たちのサービスならどこで防げただろうか」を30分以内に整理できるようになります。事故22件を同じ枠組み（何が崩れたのか → 自分たちのコードのどこに当たるのか → どう防ぐのか → どう気づくのか）で繰り返し見ていくためです。

キャリアに残るもの：機能を作るだけの開発者から、サービスを守る開発者へ

• ポートフォリオ：修正したコード、初回点検レポート、インシデント分析のまとめが、自分の作業記録として残ります。

• 面接での回答： 「セキュリティインシデントをどう防ぎますか？」という質問に、実際のインシデントと自分のコードで答えられます。

• 次のステップ：脅威モデリング、アーキテクチャの提案、インシデント対応は、シニアやリードに求められる能力です。この講義では、その3つすべてを練習します。

この講義をぜひ受講すべき理由：今こそ、あなたをレベルアップさせるときです

必ず受講すべき理由は3つです。

1. 攻撃はすでに自動化されています。ボットやAIは休むことなく弱点を探しています。パターンを知り、先回りして防いでおく側が生き残ります。

2. 問題が起きると、真っ先に呼ばれます。そのコードを作った開発者が原因を説明し、修正しなければなりません。

3. 守る能力が自分の市場価値になります。AIがコードを書いてくれる時代、安全かどうかを判断し、証明できる開発者は貴重です。

1つのレッスンは5つのステップで進みます

すべての実習授業が同じ順序なので、いくつかの回についていくだけで流れが身につきます。

1. インシデントと原理：実際のインシデントの一場面から、何が崩れたのかを見ていきます。

2. 再現（レッド）：make replayで、私たちのショッピングモールでも同じ攻撃が通用することを確認します。画面に[レッド] 脆弱と表示されます。

3. 防御：Spring Bootのコードを直接修正します。修正箇所はコード内に示されています。

4. 確認（グリーン）：同じ再現で【グリーン】ブロックに変わり、授業のテストにすべて合格するかを確認します。通常のユーザーがこれまでどおり利用できるかもあわせて確認します。

5. 検知：防いだ箇所にセキュリティイベントログを仕込み、再現をもう一度実行して、そのログが残るか確認します。

扱う実際の事故22件

公式調査結果と報道を基に、インシデントごとに「当社のソースではここ」と示します。

• 国内：SK TelecomのUSIM情報漏えい、Coupangの個人情報漏えいと署名キー、TVINGのアクセスキー露出、Lotte Cardのハッキング、GS Retailのクレデンシャルスタッフィング、KTの少額決済とフェムトセル、YES24・SGIソウル保証のランサムウェア、Upbitのハッキング

• 海外：MOVEitのSQLインジェクション、Snowflakeの顧客アカウント侵害、Microsoft Storm-0558の署名キー、M&S・Change Healthcareへのヘルプデスク攻撃、Salesloft Drift連携トークン、バイナンス・Bybitの署名事故、Capita、ジャガー・ランドローバー、Cloudflare・AWSの障害など

OWASP Top 10:2025の全10項目に加え、一覧にはないものの実際によく発生するリスク20種類（リクエストスマuggling、キャッシュに残る他人のページ、クーポンの同時使用、リトライの集中、カードテスティングなど）もすべて含まれています。

構造まで変えます：A0からA11まで

ダオンマーケットは、顧客アプリ、管理者アプリ、MySQL、MongoDB、Redis、RabbitMQ、MinIOで構成された実際のショッピングモールです。すべてDocker composeを使って、自分のPC1台で動作します。セクションを進むたびに、この構成に防御策を1つずつ追加し、マップで何が変わったのかを目で確認します。クラウドアカウントは必要ありません。

とても簡単に実践できるようにしました

セキュリティ実習の講義で最も多い挫折の理由は、「環境が整っていないから」です。そこで、誰でも簡単に取り組めるよう工夫しました。

• どのレッスンでも、その開始地点から：make goto L=8-3の1行で、前のレッスンの正解が適用された8-3の開始状態にコードとデータが切り替わります。前のレッスンを飛ばしても大丈夫です。

• 次に入力するコマンドを教えてくれます：数日休んで戻ってきても、make whereで現在の位置を、make nextで次のコマンドを確認できます。

• うまくいかないときは、まず診断から：make doctorがDocker・メモリ・ディスク・設定・コンテナをチェックし、解決方法を一行ずつ案内します。

• 行き詰まったら正解と比較：make solutionが自分のコードと正解の異なる行を表示します。