OWASP Top 10: A04:2021 Insecure Design and a Deep Dive into STRIDE Threat Modeling 🧐

Nov 3, 2026

—

Hello everyone! 👋 I’m your security guide, here to help you on your journey to secure web development. Today, we’ll explore A04:2021-Insecure Design, a new addition to the 2021 OWASP Top 10, and delve into how to effectively utilize a powerful tool for identifying and preventing such design flaws: STRIDE Threat Modeling.

🤔 What is Insecure Design?

‘Insecure Design’ literally refers to fundamental security vulnerabilities that arise from insufficient consideration of security from the initial design phase of software. Just as a building constructed without a solid foundation can easily collapse, flaws in the design phase can lead to critical security issues, no matter how perfectly the code is written. 🏡

For example, if a password reset process is designed to be completed merely by clicking an email link, this is a design flaw itself, regardless of how well it’s implemented. A hacker could easily take over an account simply by compromising the email, right? 😨

OWASP emphasizes the importance of the ‘Secure by Design’ principle and ‘Threat Modeling’ to prevent such design flaws. This is where STRIDE comes in!

🛡️ STRIDE Threat Modeling: Six Lenses to Uncover Design Flaws

STRIDE is a threat modeling methodology developed by Microsoft that helps systematically identify and respond to potential security threats by categorizing them into six areas. It’s like examining our system’s blueprint thoroughly with six magnifying glasses. 🔍

Let’s look at how each threat connects to ‘Insecure Design’:

1. Spoofing (Identity Impersonation) 🎭

Threat: An attacker impersonates another user or system.
Insecure Design Example:
Designing a user authentication process with only a username and password (no Multi-Factor Authentication (MFA)).
Not including mutual authentication procedures in the design for server-to-server communication.
Omitting logic to verify email sender addresses (e.g., SPF, DKIM) during the design phase.
Consideration: “How is our system designed to verify and assure the identity of users and components?”

2. Tampering (Data Modification) ✍️

Threat: An attacker maliciously alters data in transit or stored data within the system.
Insecure Design Example:
Not designing integrity verification logic (e.g., hash, digital signature) for important data (e.g., transaction amounts, user permissions) during transmission.
Inadequate access control design for data flow between administrator and user functions.
Designing without considering the possibility of log file tampering.
Consideration: “Are control mechanisms designed to ensure data integrity during creation, transmission, and storage reflected in the design?”

3. Repudiation (Denial of Action)

Threat: A user denies having performed a specific action. (e.g., “I never clicked that payment button!”)
Insecure Design Example:
Not designing the system to log major user actions (e.g., login, important information modification, payment).
Missing design for audit trail functionality that can track who did what and when.
Consideration: “Is the system designed to record and track all important user or system actions in a non-repudiable manner?”

4. Information Disclosure (Exposure of Information) 📂

Threat: Unauthorized users gaining access to sensitive information.
Insecure Design Example:
Designing the system to expose detailed internal information (e.g., DB version, parts of code) to users directly when an error occurs.
Designing URL parameters to predictably expose sensitive information (e.g., user ID).
Designing the system to store important information in databases or file systems in plain text without encryption.
Consideration: “Is the system designed to maintain confidentiality in all segments where sensitive information is stored, processed, and transmitted? How will unauthorized access be prevented?”

5. Denial of Service (Service Disruption) 🚦

Threat: An attacker depletes system resources, making the service unavailable to legitimate users.
Insecure Design Example:
Not incorporating usage limits (Rate Limiting) or resource allocation limits into the design for specific functions (e.g., file upload size, API request frequency).
Designing the system to allow expensive API calls without any restrictions.
Consideration: “Are mechanisms included in the design to protect the system from excessive external requests or resource usage and maintain availability?”

6. Elevation of Privilege (Privilege Escalation) 🚀

Threat: A regular user obtains administrator or other user privileges to perform unauthorized actions.
Insecure Design Example:
Designing user permissions simply as single roles (e.g., admin, user), making fine-grained access control impossible.
Not designing the system to require additional authentication procedures when accessing administrator functions.
Designing data flow in a way that user input can affect other system components.
Consideration: “Is access control for all functions clearly designed according to the principle of least privilege? Are there any potential privilege escalation paths?”

Conclusion: Secure Design is a Must, Not an Option! ✅

‘Insecure Design’ is a much more fundamental and serious problem than simply fixing a few coding errors. From the early stages of development, specifically the design phase, it is crucial to utilize threat modeling methodologies like STRIDE to identify potential security threats in advance and establish corresponding defense strategies.

A culture where development, planning, and security teams all put their heads together and constantly ask, “How can an attacker break our system?” is the first step towards ‘Secure by Design’. To build robust and secure services, why not start today by applying STRIDE’s six lenses to your blueprints? ✨