OWASP Top 10 を実務目線で読む — 10 カテゴリと現場での対策

具体的な脆弱性のリストではない

個別の CVE ではなく、「脆弱性のカテゴリ」 を扱う。「SQL インジェクションが何件あった」 ではなく、「インジェクション系全般」 という粒度。抽象的すぎず具体的すぎない、現場の議論で使いやすい単位。

3〜4 年ごとに更新される

2013 / 2017 / 2021 / (2025 予定) と更新されてきた。新しいパターン(クラウド設定ミス、サプライチェーン攻撃、AI 由来の入力経路)が時代とともに重み付けが変わる。

対策の世界共通言語

「 うちのアプリ、A03 まだ残ってる」 と言えば世界中のエンジニアに通じる。セキュリティ要件を会話する共通語 として使える価値が大きい。

プロセスへの組み込みが本質

「 開発・レビュー・運用の各フェーズで Top 10 を意識する」 のが理想。「設計レビュー時にカテゴリを 1 つずつチェック」 「年次のセキュリティ棚卸しで現状をマップ」 のような使い方。

よくある失敗

「 URL の ID を書き換えるだけで他人の情報が見える」(IDOR)、「管理者用エンドポイントが認可チェック無しで叩ける」、「フロント側だけで権限制御している」、「API のメソッド差別なし(POST も DELETE も同じ権限で通る)」。

対策の方向性

サーバ側で必ず認可チェック が大前提。「ロール + リソース所有者 + コンテキスト」 を確認するパターンを共通ヘルパに切り出し、「各エンドポイントで明示的に呼ぶ」 設計にする。「認可テスト」 を CI に組み込む。

クラウド時代の追加観点

S3 バケットの誤公開、IAM の過剰権限、「CloudFront のキャッシュ汚染で他人のレスポンスを見る」 のような クラウド層での認可不備 も A01 に含まれる。S3 + OAC 移行 もこのカテゴリ対策。

なぜ最重要扱いか

「 攻撃者にとって最もコスパが良い」 から。「脆弱性スキャナでは検出しづらく、人間がロジックを追わないと見つからない」 種類が多い。被害は 「データ漏洩」 と直結。

よくある失敗

「 パスワードを平文または弱いハッシュ(MD5, SHA-1)で保存」、「通信に TLS を使っていない / 古い TLS バージョン」、「秘密鍵をリポジトリに commit」、「暗号化していない DB バックアップを S3 に置く」。

対策の方向性

パスワードは 「 Argon2」 や 「bcrypt」 でハッシュ + ソルト。通信は TLS 1.2 以上、できれば 1.3。秘密鍵は AWS KMS / Secrets Manager / HashiCorp Vault のような専用基盤に置く。「暗号化は仕組みに任せ、自前で実装しない」 が鉄則。

保存時暗号化の落とし穴

「 S3 や RDS のサーバサイド暗号化を有効にした」 で安心しがちだが、鍵管理がずさんだと意味がない。「同じ KMS 鍵で全環境を暗号化」 「IAM 権限が広すぎて誰でも復号できる」 では 「暗号化していないのと同じ」。

忘れがちな個人情報

「 メールアドレス・氏名・住所・電話番号」 もこのカテゴリの保護対象。「ログに個人情報を平文で出す」 が頻発するアンチパターン。サニタイズ で 「ログ書き込み前にマスキング」 する設計が必要。

よくある失敗

「 SQL を文字列連結で組み立て」、「外部コマンドを shell=True で呼ぶ」、「テンプレートエンジンの自動エスケープを切って HTML 連結」、「ORM の Raw クエリを生で組む」。

対策の方向性

SQL は プレースホルダ(prepared statement)、HTML は テンプレートエンジンの自動エスケープを切らない、外部コマンドは シェルを介さない API + 引数配列。詳細は サニタイズ・エスケープ・バリデーション と エスケープ深掘り 参照。

新興: プロンプトインジェクション

LLM が普及した結果、プロンプトインジェクション という新カテゴリが台頭。OWASP は別途 「LLM Top 10」 を出して扱っているが、「A03 と同じ発想の防御」(入力の文脈分離、権限最小化)が効く。

原則: ホワイトリスト + 分離

「 危ない文字を消す(ブラックリスト)」 ではなく、許す形だけ通す(ホワイトリスト)」 + `データと指示を分ける(プレースホルダ/分離)。これがインジェクション系すべての対策の核。

よくある失敗

「 パスワードリセット URL に有効期限が無い」、「機能フラグで管理者機能を一般ユーザーにも見せられる作り」、「レート制限が無く総当たり攻撃が可能」、`認可境界が曖昧で 「Admin」 と 「User」 の差が APIで実装依存になっている」。

対策の方向性

脅威モデリング(STRIDE / PASTA) を設計フェーズで行う。「このユースケースで攻撃者は何を狙うか」 「想定される攻撃に対し、どの層で守るか」 を 設計段階で言語化する。実装後に脆弱性スキャナで検出するより、はるかに低コスト。

セキュア・バイ・デザイン

「 機能を作る → 後でセキュリティを足す」 ではなく、機能要件と同時にセキュリティ要件を定義する。「このフォームは認証必須」 「この API は管理者のみ」 を 設計ドキュメントの第一級要素 として扱う。

既存システムへの適用

「 一度動いているシステム」 でも、「機能追加や仕様変更のタイミング」 に脅威モデリングを差し込める。「全部やる」 ではなく、重要な機能から優先順位を付けて評価する のが現実解。

よくある失敗

S3 バケットの誤公開、「管理画面のデフォルトパスワードのまま運用」、「本番に開発用デバッグエンドポイントが残っている」、「セキュリティヘッダ(Content-Security-Policy 等)を設定していない」、「管理者向けディレクトリリスティングが見える」。

対策の方向性

Infrastructure as Code + ポリシーチェック(Terraform + Checkov、CloudFormation Guard、AWS Config Rules)で 設定の自動検出と是正を仕組み化する。「人間が気を付ける」 だけでは必ず漏れる。

最小権限・最小機能の原則

「 必要なものだけ有効にする」。デフォルトで全部 ON ではなく、必要だと判明したものだけ明示的に有効化する設計が事故を減らす。「IAM のワイルドカード権限」 をなくすだけでも被害縮小に効く。

継続的な監視

「 AWS Config Conformance Pack」 「Macie」 「GuardDuty」 のような 設定逸脱の自動通知 を組み込む。「設定変更があったら通知 → 24h 以内にレビュー」 のような運用フロー。

よくある失敗

「 package.json / composer.json / requirements.txt の依存を半年以上更新していない」、「CVE が出ているライブラリを使い続けている」、「脆弱性スキャナを CI に組み込んでいない」、「SBOM(Software Bill of Materials)を持っていない」。

対策の方向性

npm audit / pip-audit / composer audit / dependabot を CI に組み込み、「新規脆弱性発見時に自動 PR」。ロックファイルをコミットして再現性を確保 し、「依存追加時にレビュー」 する文化を作る。

最近の事故事例

Mini Shai-Hulud Worm(2026 年 5 月の npm/PyPI 大規模サプライチェーン攻撃)が代表例。「正規パッケージのメンテナアカウントを乗っ取って悪意あるバージョンを公開」 で全世界に伝播した。

SBOM とライセンス

「 自社が使っているライブラリの一覧」 を機械可読で持つ(SBOM)のが大企業では事実上必須化。「脆弱性公表時に影響を 1 時間以内で把握できる」 体制が現代的。

よくある失敗

「 短すぎるパスワード許可」、「MFA(多要素認証)が無い」、「セッション ID が予測可能」、「セッションタイムアウトが長すぎる」、「パスワードリセットが攻撃に弱い」、「ブルートフォース対策(レート制限)無し」。

対策の方向性

認証は自前で書かず、AWS Cognito / Auth0 / Okta / Firebase Auth のような既製品に任せる。MFA を 標準で有効にする。レート制限を WAF や API Gateway で実装。OAuth 2.0 と OIDC の正しい使い分けも重要。

パスワード周りの現代的ベストプラクティス

「 強制定期変更は逆効果(NIST が非推奨化)」、「12 文字以上の長さを優先(複雑さより)」、「既知の漏洩パスワードリストとの照合(haveibeenpwned API)」、「MFA を必須化」。

パスキー / WebAuthn の台頭

「 パスワードレス認証(パスキー、WebAuthn)」 が普及フェーズに入っている。「フィッシング耐性」 と 「ユーザビリティ」 を同時に上げられるので、新規システムは積極的にパスキー対応 を検討する価値あり。

よくある失敗

「 署名検証なしの自動更新」、`CI/CD で外部スクリプトを 「curl | sh」 する」、「セッションオブジェクトを Cookie に詰めて改ざん検証なし」、「untrusted な JSON / YAML を deserialize して任意コード実行」。

対策の方向性

署名検証 + チェックサム を更新パイプラインに組み込む。「デシリアライズ前にスキーマ検証」。CI/CD では 信頼できるレジストリからのみ取得 + SLSA レベルでの担保。

サプライチェーン視点

A06(古いライブラリ)と密接。依存の出所と完全性 を 「常に検証する」 ことが鍵。「コンテナイメージの署名(Cosign、Notation)」 「npm の provenance」 などのインフラが整いつつある。

Webhook の検証

「 Stripe / GitHub Webhook」 のような 外部から来るデータの署名検証 を必ず行う。「HMAC 署名のヘッダを検証する」 のは必須で、これを忘れて任意リクエストを受け付けるとビジネスロジックが攻撃される。

よくある失敗

「 認証失敗ログを取っていない」、「管理操作の監査ログが無い」、「異常検知のアラートが設定されていない」、「ログが攻撃者に上書きされる場所に置いてある」。

対策の方向性

認証・認可・重要操作のイベントを構造化ログに残す、「改ざん不可能な場所(S3 Object Lock、CloudWatch Logs)に保管」、「異常パターンで自動アラート(WAF、GuardDuty、Datadog)」。事故時に 何が起きたか追える状態 を最低ラインに。

クラウドネイティブな最低構成

「 CloudTrail データイベント + GuardDuty + Security Hub + S3 アクセスログ」 を有効化するだけでも、「攻撃に気付くまでの時間」 が大幅に短くなる。「設定するだけで効く」 のが現代的な選択肢の良さ。

プライバシーとのバランス

「 ログに個人情報を残さない」 とのバランスが必要。セキュリティ目的に必要最小限の情報をログに残し、個人情報はマスキング の設計を最初に決める。後から個人情報を消すのは大変なので、設計段階で考慮するのが効率的。

よくある失敗

「 ユーザー指定の URL を fetch する画像取得 / Webhook テスト機能」 で、「http://169.254.169.254/」(クラウドメタデータエンドポイント)に到達可能、「内部 IP やプライベートサービスに到達可能」。

対策の方向性

内部 IP 範囲(127.0.0.1, 10.0.0.0/8, 169.254.169.254 など)へのアクセスをブロック、「URL スキームをホワイトリスト(http/https のみ)」、「DNS 解決結果も検証(リバインディング攻撃対策)」、「必要なら専用プロキシ経由でのみ外部リクエスト」。

クラウドでの被害シナリオ

「 EC2 や Lambda で動くアプリが SSRF で 169.254.169.254 を叩く → IAM 一時クレデンシャル取得 → AWS API を任意実行 → データ取得 / 削除 / マイニング VM 起動」。IMDSv2 を必須化するだけでもかなり緩和できる。

最近の事例

2026 年 5 月の Next.js セキュリティリリース にも SSRF が含まれていた。「フレームワーク側の脆弱性」 として出ることもあり、「常に最新版に保つ」 ことも対策の一つ。