█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Cybersecurity/Application Security/OWASP A04: Insecure Design
40 minIntermediate

OWASP A04: Insecure Design

After this lesson, you will be able to: Recognize, find, and fix Insecure Design (OWASP A04): flaws in the architecture and business logic that no amount of perfect coding can patch.

Insecure Design is OWASP A04, added in 2021 to capture a different class of problem: the design itself is flawed, not the implementation. You can write bug-free code for a feature that should never have existed as designed. The fix is threat modeling and secure design patterns, applied before code is written.

Prerequisites:Cryptographic Failures

What it is

Insecure Design is a missing or ineffective control by design, distinct from an implementation bug. Examples: a password-reset flow that relies on guessable security questions; a checkout that trusts a client-supplied price; an account-recovery path with no rate limiting, enabling credential stuffing; a 'transfer funds' feature with no second-factor for large amounts. The code may be perfectly written, but the design assumed trust it should not have. The defense lives upstream, in how the feature is conceived.

💡 Real-world example

A recurring class: business-logic and anti-automation failures. Many credential-stuffing breaches succeed not because of a code bug but because the login and password-reset flows were designed with no rate limiting, no lockout, and no bot defense, so attackers replay millions of leaked username/password pairs unimpeded. The 2018+ wave of credential-stuffing attacks on retailers and streaming services exploited this design gap, not a single coding flaw.

How to find it

Insecure design is found by threat modeling and abuse-case analysis, not by scanning code.

  1. 1

    For each feature, ask 'how would an attacker abuse this?' (abuse cases), not just 'does it work?'.

  2. 2

    Threat-model the data flow: what is trusted, where, and why? (STRIDE is a common framework.)

  3. 3

    Look for missing controls by design: no rate limiting on auth/reset, no spending limits, trusting client-side values (price, role, quantity).

  4. 4

    Check whether security requirements existed at all: was abuse considered in the spec?

  5. 5

    Review the flow with a 'deny by default' mindset; if a control is absent, it is a design gap.

How to fix it

Bake the control into the design; never trust the client for security decisions.

tsx
// INSECURE DESIGN: trusts the client-supplied price
app.post('/checkout', (req, res) => {
charge(req.body.price); // attacker sends price: 0.01
});
// SECURE DESIGN: the server computes the price from trusted data
app.post('/checkout', (req, res) => {
const price = computePriceFromCart(req.user.cartId); // server-side truth
charge(price);
});
// Design-level controls to add up front: rate limiting + lockout on auth
// and password reset; server-side validation of all security-relevant
// values; spending/transfer limits with step-up auth; threat modeling in
// the design review.
Quick Check

How does Insecure Design differ from the other OWASP categories?

Pick the precise distinction.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←OWASP A02: Cryptographic Failures and Password Hashing
Back to Application Security
OWASP A05: Security Misconfiguration→