A06:2025 - Insecure Design

Insecure Design addresses fundamental flaws in the architecture and design of an application rather than bugs in its implementation. First introduced in the 2021 edition as A04, it has moved to position six in 2025. The critical distinction is that an insecure design cannot be fixed by a perfect implementation. If the architecture itself lacks the necessary security controls, no amount of clean code will close the gap.

Overview

This category was created to emphasize the difference between "insecure design" and "insecure implementation." A secure design can still have implementation defects that lead to vulnerabilities, but an insecure design is missing the controls needed to defend against specific attacks by definition. The shift from A04:2021 to A06:2025 reflects improvements in how teams approach threat modeling and secure design practices, though gaps remain widespread.

Common root causes include skipping threat modeling during the design phase, failing to establish trust boundaries between system components, and not accounting for abuse cases in business logic flows. Unlike implementation bugs that can be patched individually, insecure design often requires significant rearchitecting to remediate.

What Radar Detects

• Missing rate limiting on authentication endpoints.**Login, password reset, and account recovery flows that lack throttling mechanisms, allowing attackers to perform unlimited brute-force attempts without any server-side restriction.

• Absence of input validation at trust boundaries.**Data flowing between components, services, or tiers (e.g., from a public API gateway to an internal microservice) without re-validation at the receiving boundary, violating the principle that each component should validate its own inputs independently.

• Insecure business logic patterns.**Code paths where critical steps in a workflow can be bypassed or manipulated, such as skipping payment verification in a checkout flow, applying unauthorized discounts by manipulating request parameters, or accessing premium features without proper entitlement checks.

• Missing account lockout after failed authentication.**Authentication logic that permits unlimited failed login attempts without implementing temporary account lockout, progressive delays, or CAPTCHA challenges, leaving accounts exposed to credential stuffing and brute-force attacks.

• Missing rate limiting on API endpoints.**Public-facing API endpoints that accept unbounded request volumes without throttling, enabling abuse such as data scraping, resource exhaustion, or enumeration attacks against user accounts and resources.

• Unrestricted resource consumption.**Operations that consume significant server resources (file uploads, report generation, bulk data exports) without enforcing size limits, timeouts, or concurrency caps, enabling denial-of-service through legitimate-looking requests.

Related CWEs

CWE-209 (Generation of Error Message Containing Sensitive Information), CWE-256 (Plaintext Storage of a Password), CWE-501 (Trust Boundary Violation).

See the CWE Reference for details.

Prevention

• Build and maintain a secure design pattern library that teams can reference when architecting new features, covering authentication flows, payment processing, data validation, and session management.
• Perform threat modeling for every critical feature and data flow before writing code, identifying trust boundaries, entry points, and potential abuse scenarios.
• Write unit and integration tests that specifically cover abuse cases and negative scenarios, not just the happy path. Test what happens when a user skips steps, replays requests, or tampers with parameters.
• Implement rate limiting on all authentication, registration, and password recovery endpoints, using token bucket or sliding window algorithms.
• Enforce explicit trust boundary validation so that every component independently validates all incoming data, regardless of whether the sending component is trusted.
• Adopt a defense-in-depth approach where multiple layers of controls protect critical operations, ensuring that no single point of failure can compromise the entire flow.
• Establish resource consumption limits for all user-triggered operations, including file upload sizes, API call rates, and concurrent operation caps.
• Integrate security design reviews into the development lifecycle so that architectural decisions are evaluated for security implications before implementation begins.

Next Steps