Loading module...
Loading module...
OWASP-06
Insecure design represents weaknesses in the design and architecture of the application.
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).
Lack of security controls in the design phase that cannot be added later through implementation alone.
Not using threat modeling during design for critical authentication, access control, and business logic.
Failure to determine what level of security design is required based on business risk.
Flaws in application business logic, such as lack of defining unwanted or unexpected state changes.
Insufficient separation of tenants in multi-tenant applications.
Improper handling of trust boundaries between different security zones.
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.).
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.
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.
Gather security requirements and allocate resources appropriately based on business risk.
Create architecture and design with security controls built in from the start.
Implement processes that ensure security throughout development.
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.
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.
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:
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.
Content adapted from OWASP Top 10:2025, licensed under CC BY-SA 4.0