Loading module...

Insecure Design | Top 10 Dev Training

OWASP-06

Insecure Design

Insecure design represents weaknesses in the design and architecture of the application.

Audio overview (optional)

AI-generated summary. The Read tab has the full written content, which is the primary source and what the quiz is based on.

Transcript

Insecure design is a different kind of category than most of the others on the OWASP list. It isn't about a specific bug you can fix in code. It's about what happens when the security controls you needed were never designed into the system in the first place.

There's a distinction worth making clearly at the start. Insecure design versus insecure implementation. A design flaw is "we never created the control in the architecture." An implementation flaw is "we had the control but coded it wrong." A secure design can still have implementation bugs, and those bugs can usually be patched. But an insecure design cannot be fixed by any amount of good coding. If the architecture never included rate limiting, no amount of careful line-by-line review will add it. You have to go back and design it in.

Insecure design dropped from number four in 2021 to number six in 2025. The movement reflects real progress. Threat modeling has diffused into normal engineering practice at many companies. Architecture review checklists catch more design-level issues before code ships. Secure-by-default framework choices make some classes of design flaws harder to introduce. But for greenfield systems, this category still matters enormously, because the cost of catching a design flaw after launch is orders of magnitude higher than catching it at whiteboard time.

Let me give you three concrete examples that illustrate what insecure design actually looks like.

First, insecure credential recovery. An application uses security questions and answers as the credential recovery path. What's your mother's maiden name. What was the name of your first pet. These are prohibited by NIST 800-63b, by the OWASP Application Security Verification Standard, and by the OWASP Top 10 itself. The reason is that more than one person can know the answers, the answers are often discoverable through social media or public records, and they cannot be trusted as evidence of identity. This isn't a coding bug. It's a design decision that introduced a vulnerability the implementation cannot fix. The solution is to remove the feature and replace it with a secure design, typically email verification plus MFA.

Second, a business logic flaw. A cinema chain offers group bookings with a discount, capped at fifteen attendees before requiring a deposit. An attacker threat-models the flow and books six hundred seats across every cinema simultaneously, exploiting the fact that the fifteen-attendee limit was enforced per booking rather than across bookings. Massive loss of income, seats unavailable to real customers. The fix is rate limiting, deposit requirements for large bookings, and anomaly detection. Again, a design issue. No amount of careful code at the implementation level would have prevented this, because the business rules themselves were insecure.

Third, bot scalping. A retail website sells high-end video cards. Inventory is limited. The design assumes human buyers. Within seconds of a new drop, automated bots purchase the entire inventory to resell on auction sites. Terrible publicity, revenue loss, alienated customers. The fix is anti-bot design, CAPTCHAs, queue systems, purchase pattern detection, or invite-based access. Design work, not code work.

So how do you avoid insecure design?

First, adopt a secure development lifecycle. Security isn't a phase at the end. It's a thread through the whole process, from requirements through deployment.

Second, threat model at design time. For any critical feature, especially authentication, access control, and business logic, walk through the attack scenarios before the code gets written. Who benefits from abusing this feature? What's the worst outcome they can cause? What controls prevent that?

Third, use reference architectures and secure design patterns. Don't reinvent authentication flows. Don't design your own access control model. Use well-understood patterns that have been stress-tested.

Fourth, integrate security language into user stories. When a product manager writes "user can book group tickets," the security-conscious version includes "and cannot abuse the discount to reserve the whole theater."

And fifth, compile misuse cases alongside use cases. For every feature, ask what an attacker, a malicious insider, or a confused user could do with it. The misuse cases often reveal design gaps the functional requirements never surfaced.

Insecure design is at number six for a good reason, but the reason matters. It's a category about discipline, not tools. The tools catch bugs. The discipline is what keeps the bugs from being baked in.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.

Attestation not yet available

Complete and pass every module quiz in this course to unlock the final attestation. Once all modules are done, this tab will open for signing.

A06:2025 - Insecure Design

Overview

Insecure design represents different weaknesses expressed as "missing or ineffective control design." There is a difference between insecure design and insecure implementation - design flaws occur during planning/architecture, while implementation defects occur during coding.

Impact: A secure design can still have implementation defects, but an insecure design cannot be fixed by perfect implementation as needed security controls were never created.

Key Insight: Notable CWEs include CWE-256 (Unprotected Credentials), CWE-269 (Improper Privilege Management), CWE-434 (Unrestricted File Upload), CWE-501 (Trust Boundary Violation).

Common Vulnerabilities

Missing Security Controls

Lack of security controls in the design phase that cannot be added later through implementation alone.

No Threat Modeling

Not using threat modeling during design for critical authentication, access control, and business logic.

Insufficient Business Risk Profiling

Failure to determine what level of security design is required based on business risk.

Business Logic Flaws

Flaws in application business logic, such as lack of defining unwanted or unexpected state changes.

Weak Tenant Separation

Insufficient separation of tenants in multi-tenant applications.

Trust Boundary Violations

Improper handling of trust boundaries between different security zones.

Real-World Attack Scenarios

Scenario 1: Insecure Credential Recovery

A credential recovery workflow uses "security questions and answers."

Problem: Questions and answers are prohibited by NIST 800-63b, OWASP ASVS, and OWASP Top 10. They cannot be trusted as evidence of identity since more than one person can know the answers.

Impact: Account takeover through social engineering or public information gathering.

Solution: Remove this functionality and replace with more secure design (email verification, MFA, etc.).

Scenario 2: Cinema Chain Business Logic Flaw

A cinema chain allows group booking discounts with maximum of 15 attendees before requiring a deposit.

Attack: Attackers threat model this flow and book 600 seats across all cinemas at once in a few requests, causing massive loss of income.

Impact: Financial loss, denial of service to legitimate customers.

Solution: Implement rate limiting, deposit requirements for large bookings, anomaly detection.

Scenario 3: Retail Bot Protection Failure

A retail chain's e-commerce website has no protection against bots buying high-end video cards.

Attack: Scalpers run bots to buy all inventory within seconds to resell on auction websites.

Impact: Terrible publicity, bad blood with enthusiasts, revenue loss.

Solution: Careful anti-bot design, domain logic rules (purchases within seconds of availability), CAPTCHA, queue systems.

How to Prevent

Secure Development Lifecycle

Establish and use a secure development lifecycle with AppSec professionals
Help evaluate and design security and privacy-related controls
Move beyond "shift-left" to pre-code activities (requirements, design)

Secure Design Patterns

Establish and use a library of secure design patterns or paved-road components
Use reference architectures
Apply principles of Secure by Design

Threat Modeling

Use threat modeling for critical parts:
- Authentication
- Access control
- Business logic
- Key flows
Use as an educational tool to generate security mindset

Security Integration

Integrate security language and controls into user stories
Integrate plausibility checks at each tier (frontend to backend)
Write unit and integration tests validating critical flows resist threat model
Compile use-cases and misuse-cases for each tier

Architecture

Segregate tier layers on system and network layers based on exposure and protection needs
Segregate tenants robustly by design throughout all tiers

Three Key Parts of Secure Design

1. Requirements and Resource Management

Gather security requirements and allocate resources appropriately based on business risk.

2. Secure Design

Create architecture and design with security controls built in from the start.

3. Secure Development Lifecycle

Implement processes that ensure security throughout development.

Core Design Principles

Design decisions are the controls that implementation can never retrofit. A handful of principles recur across secure-design frameworks (OWASP Cheat Sheets, NIST SP 800-160, ISO/IEC 27034) and are directly responsible for many of the insecure-design anti-patterns cataloged above.

Principle of Least Privilege

Every user, service, and process should receive only the permissions required to do its job, and no more. The default posture is deny; access is granted explicitly, narrowly, and time-bounded.

A common violation is defaulting newly created users to an administrator role on the theory that "we'll downgrade them later." That design choice cannot be patched by code review or input validation; the system is designed to over-privilege, and any compromised account inherits that blast radius. Compare to a system designed with minimum viable privileges per role, where a compromise is contained by default.

Separation of Duties

Critical or high-impact operations are split across multiple actors so that no single compromised account can complete the operation end-to-end. Classic examples:

Financial transfer: one user submits, a second user approves before funds move.
Deploy pipeline: the engineer who writes the code cannot also single-handedly push it to production; a reviewer and a build system approve separately.
Key management: the person holding the key cannot also be the person authorizing its use.

Separation of duties is a design-level choice. If the system does not model the approval step, no amount of careful coding recovers it after the fact.

Related principles

Defense in depth: assume any single control can fail and layer independent controls.
Fail closed / fail safe: errors default to denying access, not allowing it.
Complete mediation: every access check is enforced on every request, not cached or inferred.
Economy of mechanism: simpler designs fail in fewer places and are easier to audit.

Additional Resources

Content adapted from OWASP Top 10:2025, licensed under CC BY-SA 4.0