Webセキュリティの確認順 - OWASP Top 10:2025索引

9分 で読める | 2025.12.02

公式ドキュメント
Security設計AuthAPI

Webセキュリティでは、短いコード例をコピーするより、守る対象と信頼境界を確認し、利用するフレームワークや認証基盤の安全な機能を正しく設定することが重要です。

OWASP Top 10は、Webアプリケーションの重大なリスクについて共通認識を作るための**awareness document（注意喚起資料）**です。10項目をチェックすれば安全が完成する規格や、実装手順の完全な一覧ではありません。具体的な要件はOWASP ASVS、実装判断はOWASP Cheat Sheet Seriesや利用製品の公式資料で確認します。

Web Requestを認証、resourceとactionのServer認可、contextに応じた入力検証、安全な処理と出力で守り、依存関係と安全な設定が支える図

OWASP Top 10:2025を索引として使う

カテゴリ最初に確認すること
A01 Broken Access Controlすべてのresourceとactionをサーバー側で認可しているか
A02 Security Misconfiguration本番設定、不要機能、error表示、security headerを管理しているか
A03 Software Supply Chain Failuresdependency、build、artifact、更新元を追跡・検証できるか
A04 Cryptographic Failures守るdata、鍵管理、転送時・保存時の保護を決めているか
A05 InjectionSQL、HTML、shellなど出力先に合う安全なAPIを使っているか
A06 Insecure Designabuse caseと失敗時の動作を設計・レビューしたか
A07 Authentication Failures実績ある認証基盤を使い、sessionと回復手順を保護しているか
A08 Software or Data Integrity Failuresupdate、CI/CD、serialization、artifactの完全性を検証しているか
A09 Security Logging and Alerting Failures検知後に行動できるlog、alert、対応手順があるか
A10 Mishandling of Exceptional Conditionstimeout、resource枯渇、例外時に安全側へ失敗するか

2021版とはカテゴリ名と順位が変わっています。たとえばInjectionはA05となり、A10はSSRF単独ではなく例外条件の不適切な処理を扱います。記事内の番号だけを暗記せず、参照時点の公式版を確認します。

1. 認証の前に認可境界を見る

認証は「誰か」を確認し、認可は「その主体がこのresourceへこの操作をしてよいか」を確認します。有効なsessionやtokenがあっても、別利用者の注文を読めるとは限りません。

認可はUIでボタンを隠すだけでなく、APIやデータアクセス層で毎回確認します。URL上のID、role、所有者、組織、状態遷移を入力として扱い、拒否を既定にします。管理画面だけでなく、内部API、batch、file downloadも同じ対象です。

2. 入力・処理・出力を分ける

「すべてsanitizeする」という一つの処理では、SQL InjectionとXSSの両方を安全にできません。

  • 入力検証: 型、長さ、許可値、業務上の範囲をサーバー側で確認する
  • SQL: 文字列連結ではなくparameterized queryを使う
  • HTMLなどへの出力: 出力contextに合うencodingや安全なDOM APIを使う
  • HTMLを許可する入力: 実績あるsanitizerを、許可する要素・属性を決めて使う
  • OS command: 可能ならcommand実行自体を避け、安全な専用APIを使う

フレームワークの自動escapeを無効にするAPIや、生HTML挿入機能を使う箇所は特にレビューします。Content Security Policyは被害を抑える層になりますが、安全な出力処理の代わりではありません。

3. 認証・session・CSRFは一組で設計する

パスワードのhash、MFA、login試行制御、account recovery、session固定対策、logout、期限、Cookie属性は相互に関係します。独自の認証方式や暗号処理を作らず、保守されているIdP、framework、libraryを優先します。

パスワードへ「大文字・小文字・数字・記号を必須」とするだけでは十分ではありません。長さ、漏えい済みpasswordの拒否、MFA、安全な回復手順、利用するpassword hashの公式推奨を合わせて確認します。

Cookie sessionではSecure、HttpOnly、適切なSameSiteを検討します。ただしHttpOnlyはXSSそのものを防がず、SameSiteだけで全CSRF要件が完了するわけでもありません。

4. 暗号化より先にdataと鍵の寿命を決める

保存しなくてよい機密dataは保存しないことが第一です。保存が必要なら、誰が復号できるか、鍵をdataと分離できるか、rotation・失効・backup・監査をどうするかを決めます。

暗号algorithm名だけを選んでも、安全なkey managementにはなりません。cloud KMSや保守されたlibraryを使い、独自の暗号文形式を設計しないことを基本にします。passwordは復号可能な暗号化ではなく、password保存用の方式でhash化します。

5. 外向き通信と例外条件を脅威として扱う

利用者が指定したURLをサーバーから取得する機能は、SSRFの入口になります。hostnameの文字列比較やIPv4 private rangeの自作判定だけでは、redirect、DNS rebinding、IPv6、link-local、cloud metadataなどを扱い切れません。

送信先を利用者に自由指定させない設計を優先し、必要ならnetwork egressとapplicationの両方でallowlistを構成します。timeout、response size、redirect、protocol、名前解決後の宛先も、利用するHTTP clientと基盤の仕様に沿って制限します。

例外時には、stack traceやsecretを利用者へ返さず、途中まで成功した状態、queue詰まり、disk不足、依存先timeoutでも権限や整合性を壊さないようにします。

6. dependencyと設定を継続管理する

scannerの警告は、影響するversion・利用経路・修正版・互換性を確認し、更新後にtestして解消します。audit fixのような自動変更を、内容を確認せず本番へ入れません。

lockfile、artifactの取得元、CI権限、署名やprovenance、不要なdependency、保守終了versionも確認します。development dependencyでもbuild時に実行されるcodeはsupply chainの対象です。

security headerは用途ごとに選び、実際のresponseで確認します。CSP、HSTS、X-Content-Type-Optionsなどの設定はdeployment構成やsubdomainへの影響を理解して段階的に導入します。

7. 検知と対応までを完成条件にする

認証失敗、認可拒否、管理操作、設定変更など、対応判断に必要なeventを記録します。一方、password、access token、Cookie、Authorization header、不要な個人情報をlogへ残しません。

alertには担当者、優先度、最初の確認手順、escalation先を結び付けます。収集するだけでなく、検知から封じ込め、復旧、再発防止まで訓練します。

まとめ

OWASP Top 10:2025は、見落としやすいリスクを探す入口です。実装では次の順に確認します。

  1. 資産、主体、信頼境界、abuse caseを決める
  2. 認証後もresourceとactionを認可する
  3. 入力検証、parameterization、context別encodingを分ける
  4. 認証・session・CSRF・回復・失効を一組で設計する
  5. 鍵、dependency、設定、外向き通信、例外条件を管理する
  6. 検知・対応・更新を継続する

この一覧だけで安全が保証されるわけではありません。対象システムの脅威モデルを作り、ASVSや各Cheat Sheet、利用製品の公式資料を要件とtestへ落とし込みます。

参考リソース

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR