OWASP Top 10 A06 Guide: Insecure Design (2025): Threat Modelling and Secure Patterns

Insecure design is the risk you cannot patch away: when the control a system needed was never designed, perfect code still ships an exploitable product. In the OWASP Top 10:2025 it is A06:2025 Insecure Design, ranked sixth after entering the list in 2021. This guide explains what OWASP puts in the category, what a secure design process must produce, how identity and machine credentials feature in the most common design flaws, and how to prove to an assessor that design risk is managed. It is for security architects, product security leads, engineering managers and assessors who already know the overview and want the working detail.

Key takeaways

• Design flaws and implementation bugs are different problems. OWASP describes insecure design as missing or ineffective control design; a flawed design cannot be fixed by a perfect implementation because the required control was never created.
• It starts with risk profiling. OWASP names the lack of business risk profiling as a major contributor, because without it a team cannot decide what level of security design the software needs.
• Threat modelling is the core activity. Model authentication, access control, business logic and key flows during refinement, and turn every agreed mitigation into a security requirement and a misuse-case test.
• Identity flaws are often design flaws. Notable CWEs include unprotected and insufficiently protected credentials (CWE-256, CWE-522) and improper privilege management (CWE-269), and recovery and token designs feature in recent incidents.
• Scanners will not find most of it. Average coverage across the mapped CWEs is 35.18%, so evidence comes from design reviews, threat models, business logic tests and architecture decisions, not tool output.

What it is and who it applies to

OWASP is careful to say insecure design is not the source of all other Top 10 risks. It differs from implementation defects in root cause, in when it enters the life cycle and in how it is fixed. A secure design can still contain bugs; an insecure design lacks the control altogether. A06:2025 maps 39 CWEs. The 2025 data show a maximum incidence rate of 22.18%, an average of 1.86%, 729,882 occurrences and 7,647 CVEs, and the category fell from fourth to sixth mainly because Security Misconfiguration and Software Supply Chain Failures rose above it.

• Who it applies to: every team that designs software, APIs or AI-enabled features, and every buyer that needs to judge a supplier's design practice. It matters most for systems with money, identity or multi-tenant data flows.
• What it is not: it is not a coding standard. Code-level requirements sit in OWASP ASVS 5.0, while design practice sits in OWASP SAMM and secure SDLC frameworks. See the OWASP Top 10 Guide and the Secure Software Development Lifecycle (SSDLC) Guide.

Structure and key requirements

OWASP organises the category around three areas. Each one produces artefacts an assessor can inspect.

Threat modelling that actually changes the design

The OWASP Threat Modeling Cheat Sheet frames the work around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Data flow diagrams show processes, stores, external entities and trust boundaries; STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) is applied to components, flows and boundaries; attack trees, misuse cases and LINDDUN cover multi-step attacks, workflow abuse and privacy. Each threat gets a recorded response: mitigate, eliminate the feature, transfer (with the residual owner documented) or accept. See the Threat Modelling Guide.

Business logic as a design control

Two of OWASP's three scenarios are business logic failures: a cinema group-booking discount that lets an attacker hold huge numbers of seats in a few requests, and a retailer with no anti-bot design losing stock to scalpers. ASVS 5.0 turns these into testable requirements: documented per-user and global business logic limits (V2.1.3), steps processed in order without skipping (V2.3.1), locking so limited resources cannot be double-booked (V2.3.4), multi-user approval for high-value flows (V2.3.5, Level 3) and anti-automation controls (V2.4.1). See the Business Logic Vulnerabilities Guide and the Security Requirements and Abuse Cases Guide.

Segregation by design

OWASP asks teams to separate system and network tiers by exposure and protection needs, and to design tenant segregation into every tier rather than relying on access checks alone. See the Multi-Tenant SaaS Architecture Security Guide.

Identity and NHI requirements

Identity is where design decisions are hardest to reverse. Recovery flows, token formats, trust between services and the privileges of background identities are set at design time and then copied into every release.

• Recovery and verification flows: OWASP's first scenario rejects security questions as proof of identity because more than one person can know the answers, and NIST SP 800-63B Rev. 4 says verifiers SHALL NOT prompt subscribers to use knowledge-based authentication or security questions when choosing passwords. The same reasoning applies to automated support channels: in the Meta AI Instagram account takeover, an AI support assistant did not check that a supplied email address matched the account before sending reset codes, while accounts with two-factor authentication were not taken over.
• Service-to-service tokens: design tokens to be signed, audience- and tenant-bound, short-lived, revocable and logged. The Entra ID actor token flaw combined unsigned impersonation tokens, a 24-hour lifetime with no revocation, missing tenant validation in a legacy API and no issuance logging in the victim tenant.
• Privilege of background identities: decide in the design which non-human identity each component runs as and the narrowest privilege it needs (CWE-269). See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.
• Credential storage and rotation: design where secrets are held and how they rotate (CWE-256, CWE-522). ASVS V13.1.4 expects documentation of the secrets critical to the application and a rotation schedule. See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.
• Authentication pathways: ASVS V6.1.3 and V6.3.4 require every authentication pathway to be documented with consistent strength and no undocumented paths, which is where support, API and legacy routes are usually forgotten.
• AI agents: agents that act on behalf of users inherit all of these questions plus delegation and tool scope. See the AI Agent Threat Modelling Guide.

Implementation steps

1. Profile application risk. For each application record data classes, exposure, users, tenants and business impact. OWASP SAMM Threat Assessment stream A starts with a basic per-application assessment and moves to a central, periodically reviewed inventory.
2. Set the threshold for design review. Define which changes trigger a threat model: new external interfaces, new data stores, changes to authentication, authorisation, payment or recovery flows, new tenant or trust boundaries, and new AI agent tools.
3. Start best-effort, then standardise. SAMM stream B maturity 1 is risk-based brainstorming with existing diagrams and checklists; maturity 2 standardises training, process and tools; maturity 3 optimises and automates. Pilot with two or three high-risk teams before mandating it.
4. Write security into stories. Add security acceptance criteria and failure flows to user stories, with misuse cases for each tier, and agree them with the affected parties as OWASP recommends.
5. Build the paved road. Publish reusable, reviewed patterns: authentication and recovery, authorisation middleware, tenant context propagation, file upload handling, rate limiting and secrets retrieval. Teams that use them inherit the control.
6. Test the design, not only the code. Write unit and integration tests that prove critical flows resist the threat model, and run business logic tests from the OWASP Web Security Testing Guide (4.10.1 data validation to 4.10.10 payment functionality).
7. Feed incidents back. Post-incident reviews should ask which design assumption failed and update the pattern library and threat model templates.
8. Roll back safely. When a design flaw is found in production, OWASP's advice for the security question case is to remove and redesign the feature. Use feature flags to disable the flawed flow, provide a safe interim path (for example staff-assisted recovery with strong verification), and record the accepted risk until the redesign ships.

Evidence and assessment

Because tooling coverage is limited, assessors should look for process evidence tied to specific design decisions.

Detection signals: design flaws are exploited through legitimate functions, so monitor business events rather than signatures: unusual volumes of bookings, discounts, refunds or resets per account or source; recovery requests that change contact details; workflow steps arriving out of order; and service tokens used from unexpected tenants or networks. Log the security events your threat model names, as ASVS V16.3.3 expects.

• Metric 1: percentage of high-risk applications with a threat model updated in the last 12 months.
• Metric 2: percentage of qualifying changes that received a design review before build.
• Metric 3: share of production findings and incidents classed as design root cause, trending down.
• Metric 4: adoption of paved-road components for authentication, recovery and tenant isolation.
• Metric 5: number of accepted design risks past their review date.

Mapping to other frameworks

Common pitfalls

• Treating design as a gate, not a habit: OWASP says secure design is not an add-on or a tool; a one-off architecture review before launch misses every later change.
• Threat models that never become requirements: mitigations that are not written into stories and tests are not built.
• Recovery and support paths outside the model: attackers go for the weakest authentication pathway, as the Meta AI case above shows.
• Trusting internal tokens and services by default: missing tenant, audience or signature checks between services turn one weakness into cross-tenant access, as with the Entra ID actor tokens.
• Patching symptoms of a logic flaw: adding rate limits or filters to a broken flow instead of redesigning it, leading to repeated bypasses.
• No owner for accepted risk: transferred or accepted threats with no named owner or review date.

Practitioner checklist

• Maintain a risk profile for each application with data classes, exposure and tenant model.
• Define the changes that require a threat model and enforce it in the delivery process.
• Threat model authentication, recovery, access control, business logic and tenant boundaries first.
• Record a response and owner for every threat; review accepted risks on a fixed date.
• Add security acceptance criteria, failure flows and misuse cases to user stories.
• Publish paved-road patterns for authentication, recovery, authorisation, uploads and secrets retrieval.
• Design service tokens to be signed, tenant-bound, short-lived, revocable and logged.
• Document business logic limits and test them with automated tests and WSTG business logic cases.
• Assess design practice against OWASP SAMM Threat Assessment and Secure Architecture practices each year.
• Feed design root causes from incidents back into patterns and templates.

Standards and references

• OWASP: Top 10:2025 A06 Insecure Design
• OWASP SAMM: Design, Threat Assessment
• OWASP: Threat Modeling Cheat Sheet
• OWASP: Application Security Verification Standard 5.0
• OWASP: Web Security Testing Guide, Business Logic Testing
• NIST: SP 800-218 Secure Software Development Framework
• NIST: SP 800-63B Authentication and Authenticator Management
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: OWASP Top 10 Guide · Threat Modelling Guide · Secure Software Development Lifecycle (SSDLC) Guide · AppSec Maturity Model · Business Logic Vulnerabilities Guide