OWASP Top 10: A04:2021 Insecure Design and DREAD Threat Assessment 📊 In-depth Analysis!

Nov 2, 2026

—

Hello everyone! 🌐 Your guide to exploring the world of security vulnerabilities. Today, following up on our last discussion, we will delve deeper into A04:2021-Insecure Design, a core component of the 2021 OWASP Top 10, and provide a detailed explanation of the useful DREAD Threat Assessment Model for evaluating the risk of identified threats. 💡

🤔 Why do we need to assess threats?

Last time, through STRIDE threat modeling, we learned how to identify potential threats in our system’s design. However, simply listing threats is not enough. Not all threats carry the same level of risk. 📉 Some threats might be critical issues that need immediate resolution, while others might be low-priority enough to be addressed later.

This is where the importance of threat assessment comes into play. By objectively evaluating the severity of each identified threat and assigning priorities, we can strengthen security by utilizing limited resources and time most effectively. 🛡️ And a powerful tool for this threat assessment is DREAD!

🎲 DREAD Threat Assessment Model: 5 Metrics for Measuring Risk

DREAD is a threat assessment methodology developed by Microsoft that scores the risk of each identified threat using five criteria. Based on each criterion, scores from 1 (low) to 10 (high) can be assigned to calculate a total score, or threats can be categorized as ‘low’, ‘medium’, or ‘high’ based on subjective judgment. These scores help prioritize which threats need to be addressed more urgently. 🎯

Now, let’s take a closer look at each of the five DREAD criteria.

1. Damage 💥

Definition: The severity of potential harm that could occur to the system or business if a threat is successfully exploited.
Considerations:
Scale of data loss, alteration, or leakage? 📉
Service downtime? ⏱️
Financial loss? 💰
Damage to corporate image? 💔
Potential for legal or regulatory violations? ⚖️
Example: Customer personal information leakage (high), temporary service interruption (medium), non-essential log file tampering (low).
Relevance to Insecure Design: Sensitive information handling methods, recovery design for critical services, and data backup and retention policies significantly impact the potential for damage.

2. Reproducibility 🔁

Definition: The ease and consistency with which an attacker can reproduce the same threat.
Considerations:
Do specific conditions required for the attack occur frequently? 🔄
Is the attack procedure complex or simple? 🛠️
Does the same result occur every time? ✅
Example: SQL injection possible with a few clicks (high), a very rare bug occurring only in specific environments (low).
Relevance to Insecure Design: The absence of user input validation logic, and inadequate handling of abnormal data flows can increase reproducibility.

3. Exploitability 🧑‍💻

Definition: The amount of effort, skill, knowledge, and resources required for an attacker to successfully exploit a threat.
Considerations:
Is specific expertise required? 🎓
Are attack tools widely available? 🔧
Is the time required for the attack short or long? ⏳
Is it easy or difficult to bypass? 🚧
Example: Attacks using widely known vulnerabilities (e.g., old libraries) (high), very complex attacks using zero-day vulnerabilities (low).
Relevance to Insecure Design: System complexity, security level of the technology stack used, and management of external dependencies affect exploitability.

4. Affectability (Number of Affected Users) 👥

Definition: The number of users or system components affected if a threat is successfully exploited.
Considerations:
Are all users affected, or only specific groups? 🎯
Is the entire service interrupted, or only some functions? ⚙️
Are only internal systems affected, or external systems as well? 🌍
Example: Vulnerability that can hijack all user accounts (high), vulnerability affecting only one specific administrator (low).
Relevance to Insecure Design: Privilege separation design, service modularization, and user role management directly relate to the number of affected users.

5. Discoverability 🕵️‍♀️

Definition: The ease with which an attacker can discover a threat or vulnerability.
Considerations:
Is the vulnerability publicly known? 📢
Is the system’s design publicly disclosed? 📄
Can it be easily found with automated scanning tools? 🤖
Can it be discovered through visual inspection or basic testing? 👀
Example: Sensitive information included in HTTP headers, easily discoverable (high), vulnerability in deeply hidden code logic (low).
Relevance to Insecure Design: System complexity, documentation level, error message design, and URL structure affect discoverability.

DREAD Scoring and Utilization 📈

After assigning scores from 1 to 10 (or 1 to 3) for each criterion, these scores are summed or averaged to calculate a final risk score.

Example:


Threat Name	Damage	Reproducibility	Exploitability	Affectability	Discoverability	Total Score (Sum)	Risk Level
DB Injection	10	9	8	10	9	46	High
Denial of Service	8	7	6	8	7	36	Medium
Log Tampering	5	4	3	2	4	18	Low

Based on these scores, security improvement work can be carried out in order, starting with the threats that received the highest scores. DREAD provides an objective measure, rather than a subjective feeling about a specific threat, which greatly helps in reaching consensus on threat priorities within a team. 🤝

Conclusion: From Identification (STRIDE) to Assessment (DREAD), Completing Secure Design! 🏆

To effectively respond to A04:2021-Insecure Design, it is crucial to go beyond simply writing secure code and embed security from the design phase. It is important to broadly identify potential threats through STRIDE and objectively assess the risk of identified threats through DREAD, then improve the most critical areas first.

By integrating these two powerful tools into your development process, you will be able to build robust systems that are ‘Secure by Design’ from the outset. 🏗️ Security is not the last stage of development, but a journey that accompanies it from beginning to end!