A06: insecure design slid, for a good reason
Insecure Design slid from #4 to #6, overtaken by misconfiguration and supply chain. Introduced in 2021, it covers design and architectural flaws — including business-logic flaws such as failing to define unwanted or unexpected state changes. The project reports noticeable improvement in threat modelling since.
Why it is like this
It exists to make a point no other entry can: some flaws cannot be fixed in code, because the code correctly implements a bad design. No amount of secure coding rescues a workflow that was wrong on the whiteboard.
Not to be confused with
A catch-all for things that are hard to classify. The project's framing is specific — move beyond "shift left" in coding to pre-code activities: requirements and design.
In practice
This is the only category on the list that fell partly because the industry got better at it, rather than because the arithmetic moved.
Source: OWASP Top 10:2025 — A06:2025 Insecure Design. Read on .
The OWASP Top 10:2025 is © 2021-2025 the OWASP Top 10 Team and is licensed under a Creative Commons Attribution 3.0 Unported Licence. These cards are independent commentary written in our own words. ytyk.org is not affiliated with or endorsed by the OWASP Foundation.
Say it back Check yourself
What distinguishes an A06 Insecure Design flaw from an implementation bug, and what does the project say to do about it?
Answer out loud or in writing first, then open the points below.
The points a good answer makes
- The code may be correct; the design it implements is not
- It includes business-logic flaws, such as undefined unwanted or unexpected state changes
- It cannot be fixed by secure coding alone
- Move beyond shift-left in coding to pre-code activities: requirements writing and design
- Use threat modelling, secure design patterns and reference architectures
If a proposed fix is a code change, it is worth asking whether the finding was really a design finding wearing a bug's clothes.