Skip to content

A06 · Insecure Design

Program: Application Security — OWASP Top 10 and Threat Modeling Module: OWASP Top 10 — Web Application Security Risks Submodule: A06:2025 · Insecure Design

Introduced in the 2021 edition as a forward-looking category (surveyed in, not derived from vulnerability data alone). Insecure Design is the class of weakness that no amount of implementation-level correctness can compensate for — the feature was designed in a way that is insecure by construction. It stays in the Top 10 as A06:2025. This is the category that threat modeling exists to prevent.

Where the other Top 10 categories say "we built this feature but got detail X wrong," A06 says "we shouldn't have built this feature this way at all."


1. What It Is

Insecure Design covers weaknesses in architecture and business logic, not in code:

  • Missing or weak abuse-case analysis — no one ever asked "how would this be misused?"
  • Insufficient security requirements for the feature.
  • Missing trust boundaries in the design.
  • No rate limiting, no quota, no backpressure on resource-intensive operations.
  • Business logic that allows negative amounts, race conditions on balance updates, coupon stacking, unlimited free trials.
  • Missing segregation of duties — one role can both create and approve.
  • Password reset flows that leak account existence.
  • Multi-step workflows whose steps can be replayed or skipped.
  • Data models that make privacy or access-control enforcement impossible after the fact.

A perfectly implemented insecure design is still insecure.


2. Concrete Examples

DomainInsecure design
Cinema bookingNo cap on seats per user → scalper bots buy every seat, resell.
E-commerceCoupon codes stack additively → 100% discount possible.
Bank transferAmount is a signed integer → attacker sends -1000, credits themselves.
Loyalty pointsRefunds do not reverse point accrual → farming loop.
Password resetEnumerates whether the email exists → user harvesting.
SaaS billingTrial signup allows unlimited accounts per credit card → free service.
KYCFace-photo upload compared to ID photo without liveness check → easily bypassed.
File sharingSharing link has no expiry, no view count, no revocation.
API pagination?limit= accepts arbitrary values → attacker requests 10M rows and DoSes the DB.
Multi-tenant SaaSTenant ID inferred from URL path only → hard to add strict isolation later.

3. Prevention — Design-Time Practices

The prevention pattern for Insecure Design is not a code change; it is a process change: do security work at design time, not just at review time.

Concrete practices:

  • Threat modeling in the design phase — the whole of Module 2 exists to cover how. Establishes trust boundaries and elicits STRIDE/LINDDUN threats before implementation.
  • Abuse cases, not just user stories. For every user story write a matching abuse case (Cigital / Bruce Schneier). Track them in the same backlog.
  • Reference architectures — internal templates that pre-solve common design issues (auth, tenant isolation, rate limits, feature flags).
  • Secure design patterns — OWASP ASVS, IEC 62443 SL levels for ICS, ISO/IEC 27034 for application security, Microsoft SDL Practices.
  • Segregation of duties wherever money, identity, or admin actions are involved.
  • Rate limits and quotas on every user-facing endpoint — especially anything cryptographic, database-heavy, or externally-billable.
  • Business rule review — someone from finance/legal reviews rules that touch money or contracts.
  • "How would a red team abuse this?" as a required checklist question in every design doc.
  • OWASP ASVS (Application Security Verification Standard) as the requirements baseline — L1 for opportunistic, L2 for most business apps, L3 for high-assurance.

4. Detection & Testing

Insecure Design is the category where scanners give you the least help. Detection is done by:

  • Threat modeling review — the design artifact is the input, the threat model output surfaces the gaps.
  • Red-team / pen-test exercises with a business-logic focus, not just technical vulnerability classes.
  • Chaos-engineering-style abuse tests — automatically try to buy 10,000 seats in a booking test env; automatically send -1 as every numeric field; automatically request items you don't own.
  • Post-incident analysis — the strongest signal that a design was wrong is that it produced an incident. Feed the lesson back into the reference architectures.

5. Key Takeaways

  • Insecure Design was added in 2021 to make it explicit that you cannot code your way out of a bad design.
  • The prevention is process, not tooling — threat modeling, abuse cases, security requirements, secure design patterns, ASVS.
  • The category was surveyed in because raw vulnerability data cannot detect a design bug — it can only detect the implementation bug that resulted from one.
  • If your organization has a threat-modeling practice, this category is proactively addressed. If it doesn't, this category is where the most expensive incidents come from.

6. Glossary (this submodule)

  • Abuse case — description of how a feature could be misused by a malicious actor; the security counterpart to a user story.
  • ASVS — OWASP Application Security Verification Standard; tiered (L1/L2/L3) set of ~300 verifiable security requirements.
  • Reference architecture — reusable, pre-vetted design template that pre-solves recurring security decisions.
  • Segregation of Duties (SoD) — control principle where no single person can complete a sensitive workflow alone.
  • Rate limiting / quota — cap on request frequency or total usage per identity/tenant/IP; primary defense against many business-logic and DoS attacks.
  • Business logic flaw — vulnerability at the level of workflow rather than code (e.g. refund without reversing loyalty points).

7. What's Next

  • A07 · Authentication Failures — a specific area where design choices dominate implementation correctness.
  • Cross-refs: A01 · Broken Access Control (missing authorization in the design is worse than a missing check in code), Module 2 · Threat Modeling Methodologies — the toolkit that keeps A06 out.

Personal learning notes — cybersecurity curriculum.