Web脆弱性の基礎知識（後編）：アクセス制御・認証・設定——大規模システムが壊れる場所

前編で扱った脆弱性は「コードの書き間違い」であり、多くはスキャナで検出できます。本記事で扱うのは別の系統です。コードは設計どおりに動いており、設計と設定そのものが誤っているのです。経理担当者が役員の給与情報を閲覧できてはいけない——これを知っているのは自動ツールではなく、あなただけです。

OWASP Top 10:2025でBroken Access Controlが引き続き1位である理由もここにあります。40のCWE、180万件を超える検出、32,654件のCVEが報告されました。またSecurity Misconfigurationは5位から2位へ上昇し、71万9千件以上の検出が記録されています。

1. Broken Access Control（A01）：連続で首位

身近すぎて怖い症状をいくつか挙げます。

• IDOR：請求書IDを1042から1043に変えるだけで他人の請求書が見える。APIが「ログイン済みか」しか確認せず、「そのレコードは本人のものか」を確認していないためです。
• 強制ブラウズ：/admin/dashboard を直接入力すると入れてしまう。管理画面をメニューから隠しただけで、サーバー側で保護していないケースです。
• フロントエンドでの認可：削除ボタンはJavaScriptで隠しているのに、DELETEエンドポイントはcurlからのリクエストを受け付ける。OWASPもまさにこのシナリオを挙げています。
• JWTやCookieの改ざんによる権限昇格、過度に緩いCORS設定、POST/PUT/DELETEに対する検査漏れ。

対策

基本はデフォルト拒否です。すべて閉じたうえで、明示的に列挙したものだけを開きます。認可チェックは攻撃者が改変できないサーバー側に置きます。コントローラごとに独自実装するのではなく、認可機構を一度作って全体で再利用してください。穴は必ず「誰かが忘れたエンドポイント」にあります。モデルはロールだけでなくレコードの所有者を検証すべきです。ログアウト時にはサーバー側でセッションを無効化し、JWTは短命にしてリフレッシュトークンと組み合わせ、失効できる状態を保ちます。

多くのチームが見落としている費用対効果の高い施策が認可の統合テストを書くことです。重要なエンドポイントごとに「ユーザーAはユーザーBのデータに触れられない」ことを検証するテストを用意します。QAが担当でき、年1回のペネトレーションテストよりも多くの問題を捕捉します。

2. CSRF：被害者自身のセッションを悪用する

あるタブで銀行にログインしたまま、別のタブで悪意あるページを開く。そのページが密かに送金リクエストを送ると、ブラウザはセッションCookieを自動で付与します。サーバーには正当なリクエストに見えるため、処理されてしまいます。

対策：セッションCookieにSameSite=LaxまたはStrictを設定する（多くのブラウザで既定ですが明示すべきです）。状態を変更するフォームにはsynchronizer token patternによるCSRFトークンを適用する。重要なエンドポイントではOriginまたはRefererヘッダーを検証する。データを変更する操作にGETを使わない。

3. Authentication Failures（A07）

現在の最大のリスクはパスワードを解読されることではなく、クレデンシャルスタッフィングです。他所から流出した膨大なメールアドレスとパスワードの組み合わせを、あなたのログイン画面で総当たりします。Password1!、Password2! のように少しずつ変えて試す亜種も一般的です。さらにセッションフィクセーション、URLに露出したセッションID、ログアウトしても無効化されないセッション、そしてOWASPが「安全にはできない」と評価する秘密の質問による再設定も問題です。

対策

可能な限り多要素認証を有効化し、特に管理者アカウントでは必須にします。既定の認証情報を出荷しない。新しいパスワードは、よくある脆弱なパスワードや漏洩済み認証情報のリストと照合します。NIST 800-63Bに従い、定期的なパスワード変更を強制しない——漏洩が疑われるときだけリセットさせます。強制的な定期変更はかえってパスワードを弱くします。パスワードはArgon2やbcryptなど専用のハッシュ関数とソルトで保存します。ログイン成功後は新しいセッションIDを発行し、Secure・HttpOnly・SameSite付きCookieに保存し、アイドルと絶対の両方のタイムアウトを設定します。アカウント列挙を防ぐため、ログイン失敗時のメッセージは常に同一にします。JWTではaud、iss、expと署名アルゴリズムを検証します。可能であれば、自作せず実績あるID基盤を採用してください。

4. Cryptographic Failures（A04）

このカテゴリはアルゴリズムが破られたというより、使い方の誤りがほとんどです。機密データの平文での送受信や保存、パスワードへのMD5やSHA-1の利用、独自実装の暗号方式、鍵管理のずさんさなどが典型です。

対策：内部通信も含め全接続でTLSを必須にし、HSTSを有効化する。データを分類し、本当に保存時暗号化が必要なものを把握する。プリミティブを自前で組み合わせず、認証付き暗号モードを備えた標準ライブラリを使う。鍵やシークレットはリポジトリ内の設定ファイルではなくKMSやシークレットマネージャーに置く。そして不要なデータは保存しない——存在しないデータは盗まれません。

5. Security Misconfiguration（A02）：最も急上昇したカテゴリ

理由は単純で、システムの挙動がコードよりも設定で決まる割合が増えているからです。典型例として、既定パスワードのままのサンプルアプリや管理コンソールが本番に残っている、ディレクトリリスティングが有効なまま、詳細なスタックトレースがブラウザに返りコンポーネントのバージョンが露見する、クラウドストレージのバケットが公開設定になっている、などが挙げられます。

対策：Infrastructure as Codeで自動化した反復可能なハードニング手順を用意し、新しい環境が常に同じ安全な状態で立ち上がるようにする。dev・QA・本番の設定を揃え、認証情報だけを分ける。使わない機能・ポート・アカウント・サンプルを削除する。Content-Security-Policy、Strict-Transport-Security、X-Content-Type-Options、Referrer-Policyなどのセキュリティヘッダーを揃える。詳細なエラーメッセージは集中ハンドラで抑止する。コードやパイプラインに静的な鍵を埋め込まず、IDフェデレーションや短命な認証情報を優先する。全環境の設定を自動検証する仕組みを持つ。

6. Software Supply Chain Failures（A03）：コミュニティが最も懸念する新カテゴリ

OWASPのコミュニティ調査では、回答者のちょうど50%がこのカテゴリを1位に挙げました。従来の「古いコンポーネント」を、直接・推移的依存関係、IDEと拡張機能、レジストリ、イメージ、ビルドおよび配布システムまで含むエコシステム全体へ拡張したものです。注目すべきは、CVE件数は全カテゴリ中で最少である一方、平均のExploitスコアとImpactスコアは最高である点です。稀ですが致命的です。

対策：製品全体のSBOMを生成・管理する。直接依存だけでなく推移的依存も追跡する。使わなくなったライブラリを削除する。OWASP Dependency-TrackやDependency-Checkなどで継続的にスキャンし、CVE・NVD・OSVを購読する。署名済みの信頼できる供給元からのみアーティファクトを取得する。CI/CDで最小権限と職務分離を徹底し、誰か一人だけで本番までコードを届けられない状態にする。ビルドパイプラインは、それがデプロイするシステムと同等以上に保護すべきです。

7. Logging & Alerting（A09）と Mishandling of Exceptional Conditions（A10）

この2つは直接の被害を生まないため最も軽視されますが、結果として攻撃されていることに気づけなくなります。2025年版でA09が「Logging and Alerting」に改称されたのは、優れたログもアラートがなければほぼ無価値だという指摘です。

ログイン成功と失敗、アクセス拒否、高額取引はすべて、追跡できるだけの文脈とともに記録してください。ログは機械可読な形式で、アプリケーションホストの外へ転送し、改ざん防止の完全性管理を施し、パスワード・トークン・個人情報を含めないことが必須です。あわせて適切なアラート閾値と対応プレイブックを用意します。誤検知が多すぎれば、本物のアラートは必ず見逃されます。

A10は2025年版の新設カテゴリで、エラー処理の不備に関する24のCWEをまとめています。エラーメッセージからの情報漏えい、パラメータ欠落の未処理、そして何よりフェイルオープン——異常時に既定で「通してしまう」挙動です。原則はフェイルクローズ、認証サービスが応答しないなら拒否します。エラーは発生箇所で捕捉し、グローバル例外ハンドラを安全網として用意し、中途半端なトランザクションは完全にロールバックし、繰り返されるエラーパターンを監視してください。それはしばしば、進行中の探索行為の痕跡です。

本番稼働中のチーム向け 30・60・90日ロードマップ

最初の30日：低コストで効果の高い施策から。既定の認証情報をすべて変更、管理者アカウントのMFA有効化、本番でのディレクトリリスティングとスタックトレースの無効化、セキュリティヘッダーの追加、CIでの依存関係スキャン、ストレージバケットの公開設定の棚卸し。

次の30日：コード修正が必要な領域へ。全エンドポイントを棚卸しして所有者チェックを追加、重要エンドポイントの認可統合テストを作成、認証とセッション管理の標準化、シークレットのシークレットマネージャーへの移行。

90日目まで：継続的な能力の構築。SBOMの自動生成、コードによるインフラのハードニング、ログの集約とアラート・プレイブックの整備、机上訓練による対応プロセスの検証。

まとめ

前編が開発者の物語だとすれば、後編はチーム全体の物語です。アーキテクトが認可モデルを決め、DevOpsが設定を決め、QAが何をテストするかを決め、運用が「5分で気づくのか5か月後なのか」を決めます。アプリケーションセキュリティはリリース前のチェック項目ではなく、毎スプリント繰り返される習慣です。

参考文献

• OWASP Top 10:2025 — owasp.org/Top10/2025
• OWASP Cheat Sheet Series — cheatsheetseries.owasp.org
• PortSwigger Web Security Academy — portswigger.net/web-security
• NIST SP 800-63B Digital Identity Guidelines — pages.nist.gov/800-63-3