OWASP Top 10: A04:2021 安全でない設計(Insecure Design)とSTRIDE脅威モデリングを徹底解説 🧐

11月 3, 2026

—

こんにちは！皆さんの安全なウェブ開発の旅をサポートするセキュリティガイドです。👋 今日は、2021年OWASP Top 10に新たに登場したA04:2021-Insecure Design (安全でない設計)について掘り下げ、このような設計上の欠陥を効果的に見つけ出し、予防するための強力な武器であるSTRIDE脅威モデリングをどのように活用できるかを詳しく説明します。

🤔 安全でない設計(Insecure Design)とは何でしょうか？

「安全でない設計」とは、文字通りソフトウェアの初期設計段階からセキュリティを十分に考慮しなかったために発生する根本的なセキュリティ脆弱性を意味します。頑丈な基礎工事なしに建てられた建物が簡単に崩れるように、設計段階の欠陥は、どれほどコードを完璧に記述しても、致命的なセキュリティ問題につながる可能性があります。🏡

例えば、パスワードリセットプロセスをメールリンクのクリックだけで完了するように設計した場合、これは実装がどれほど優れていても、設計自体に欠陥があることになります。ハッカーがメールを乗っ取るだけで、簡単にアカウントを奪うことができるでしょう？😨

OWASPでは、このような設計上の欠陥を予防するために、「設計によるセキュリティ(Secure by Design)」原則と「脅威モデリング(Threat Modeling)」の重要性を強調しています。ここでSTRIDEが登場します！

🛡️ STRIDE脅威モデリング：設計の欠陥を見つけ出す6つのレンズ

STRIDEはMicrosoftが開発した脅威モデリング手法で、潜在的なセキュリティ脅威を6つのカテゴリに分類し、体系的に識別して対応できるように支援します。まるで6つの虫眼鏡を使って、私たちのシステムの設計図を隅々まで調べるようなものです。🔍

それぞれの脅威が「安全でない設計」とどのように関連しているか、一つずつ見ていきましょう。

1. Spoofing (スプーフィング: なりすまし) 🎭

脅威: 攻撃者が他のユーザーやシステムになりすますことです。
安全でない設計の例:
ユーザー認証手順をIDとパスワードのみで単純に設計した場合（多要素認証(MFA)未適用）
サーバー間通信時に、相互認証手順を設計に含めなかった場合
メール送信元アドレスを検証するロジック（SPF、DKIMなど）を設計段階で漏らした場合
考慮事項: 「私たちのシステムは、ユーザーとコンポーネントの身元をどのように確認し、保証するように設計されているか？」

2. Tampering (タンパリング: データ改ざん) ✍️

脅威: 攻撃者がシステムを通過するデータや保存されたデータを悪意を持って変更することです。
安全でない設計の例:
重要データ（例：取引金額、ユーザー権限）送信時に、データの完全性を検証するロジック（例：ハッシュ、電子署名）を設計しなかった場合
管理者機能とユーザー機能間のデータフローに対するアクセス制御設計が不十分な場合
ログファイルが改ざんされる可能性を考慮せずに設計した場合
考慮事項: 「データが生成、送信、保存される過程で完全性を保証するための制御装置が設計に反映されているか？」

3. Repudiation (否認防止)

脅威: ユーザーが自身が行った特定の行為を否認することです。（例：「私はその支払いボタンを押していません！」）
安全でない設計の例:
ユーザーの主要な行為（例：ログイン、重要情報修正、支払い）に関するログを記録するように設計しなかった場合
誰が、いつ、何をしたかを追跡できる監査追跡機能の設計が漏れている場合
考慮事項: 「ユーザーやシステムのすべての重要な行為が否認できないように記録され、追跡されるように設計されているか？」

4. Information Disclosure (情報漏洩) 📂

脅威: 許可されていないユーザーが機密情報にアクセスすることです。
安全でない設計の例:
エラー発生時、システムの詳細な内部情報（例：DBバージョン、コードの一部）をユーザーにそのまま露出するように設計した場合
URLパラメータを通じて機密情報（例：ユーザーID）を予測可能に設計した場合
データベースやファイルシステムに保存される重要情報を暗号化せずに平文で保存するように設計した場合
考慮事項: 「機密情報が保存、処理、送信されるすべての区間で機密性を維持するように設計されているか？権限のないアクセスをどのように防ぐか？」

5. Denial of Service (サービス拒否) 🚦

脅威: 攻撃者がシステムのリソースを枯渇させ、正常なユーザーがサービスを利用できないようにすることです。
安全でない設計の例:
特定の機能に対する使用量制限（レートリミット）やリソース割り当て制限を設計に反映しなかった場合（例：ファイルアップロードサイズ、APIリクエスト回数）
コストのかかるAPI呼び出しを何の制約もなく許可するように設計した場合
考慮事項: 「外部からの過度な要求やリソース使用からシステムを保護し、可用性を維持するための装置が設計に含まれているか？」

6. Elevation of Privilege (権限昇格) 🚀

脅威: 一般ユーザーが管理者や他のユーザーの権限を取得し、許可されていない作業を実行することです。
安全でない設計の例:
ユーザー権限を単一の役割（例：admin、user）のみで単純に設計し、きめ細やかなアクセス制御が不可能な場合
管理者機能にアクセスする際に、追加の認証手順を要求するように設計しなかった場合
ユーザー入力値を通じてシステムの他のコンポーネントに影響を与えることができるようにデータフローを設計した場合
考慮事項: 「最小権限の原則に従い、すべての機能に対するアクセス制御が明確に設計されているか？権限昇格経路となる可能性のある部分はないか？」

結論：安全な設計は選択ではなく必須！ ✅

「安全でない設計」は、単にいくつかのコーディングミスを修正するだけでは解決できない、はるかに根本的で深刻な問題です。開発の初期段階、つまり設計段階からSTRIDEのような脅威モデリング手法を活用して、潜在的なセキュリティ脅威を事前に特定し、対応戦略を策定する必要があります。

開発チーム、企画チーム、セキュリティチーム全員が頭を突き合わせて「攻撃者は私たちのシステムをどのように破壊できるだろうか？」という質問を絶えず投げかける文化こそが、「設計によるセキュリティ」の第一歩です。堅牢で安全なサービスを構築するために、今日から皆さんの設計図にSTRIDEという6つのレンズを当ててみてはいかがでしょうか？✨