Objective
Verify that the application has been designed with explicit security requirements and that its architecture, workflows and business rules can enforce those requirements against realistic abuse cases.
Insecure design is fundamentally different from a straightforward implementation defect. An implementation bug can often be corrected without changing the underlying security model. An insecure design may remain vulnerable even when the code works exactly as originally specified.
The assessment therefore examines whether the intended security properties were considered before implementation, and whether the design provides an effective mechanism for enforcing them.
Scope
The review should consider:
Prerequisites
| Authorization | Confirm authorization to review application architecture, requirements, workflows and security controls. |
|---|---|
| Architecture documentation | Obtain relevant architecture diagrams, component relationships, trust boundaries and deployment information. |
| Business requirements | Identify the intended business rules, security objectives and critical workflows. |
| Security requirements | Obtain available security requirements, threat models, risk assessments and acceptance criteria. |
| Test environment | Prefer a controlled environment for validating workflows and security assumptions. |
Methodology
Insecure design assessment should begin with the security properties the system is expected to provide, rather than beginning with individual source-code defects.
| Review stage | Primary question |
|---|---|
| Business context | What must the system protect and what business outcomes must it preserve? |
| Security requirements | What security properties are explicitly required? |
| Threat model | Which realistic threats and abuse cases were considered? |
| Architecture | Does the architecture provide controls capable of enforcing those requirements? |
| Workflows | Can users reach sensitive states through unintended sequences of actions? |
| Failure paths | Do exceptional and recovery paths maintain the same security properties? |
Test procedure
Security requirements
Security controls should be derived from explicit requirements. A system cannot reliably enforce a security property that was never defined.
Define which operations require authentication, what assurance level is required and when re-authentication is necessary.
Define who may perform each sensitive action and what object-level restrictions apply.
Define which business operations require validation, limits, approvals or confirmation.
Define security requirements for password reset, account recovery and identity verification.
Define how sensitive information should be protected throughout its lifecycle.
Define controls for automated abuse, excessive requests, resource exhaustion and business-process manipulation.
Threat and trust-boundary review
The assessment should determine whether realistic threats were considered at the design stage and whether the architecture contains controls appropriate to those threats.
| Area | Review question |
|---|---|
| External users | What can an untrusted user legitimately access or influence? |
| Authenticated users | What happens if a legitimate account is maliciously controlled? |
| Privileged users | Are administrative operations isolated from ordinary user functionality? |
| Internal services | What happens if a downstream service is compromised or behaves unexpectedly? |
| Third parties | Does the design appropriately handle failures or compromise of external dependencies? |
| Client-controlled state | Does the server independently enforce security-critical decisions? |
A document that lists threats but does not lead to concrete controls, design decisions or verification requirements provides limited security value.
Abuse-case analysis
Security testing should examine whether legitimate functionality can be combined or repeated in a way that violates business or security requirements.
Example abuse scenario
An application allows a user to create a transaction and separately confirm the transaction. The design assumes that confirmation can only occur for the transaction created by the same user, but the transaction identifier is trusted without enforcing ownership on the server.
Architecture review
| Architecture property | Verification focus |
|---|---|
| Trust boundaries | Security decisions occur at appropriate trust boundaries rather than relying on untrusted components. |
| Least privilege | Components receive only the permissions required for their intended function. |
| Defense in depth | Critical security properties do not depend on a single easily bypassed control. |
| Secure defaults | Failure, omission or misconfiguration does not unnecessarily disable important security controls. |
| Isolation | Sensitive functions and data are appropriately separated from lower-trust components. |
| Dependency trust | External services are not granted more authority than required. |
Business logic and state transitions
A secure design must define which state transitions are valid and which conditions must be satisfied before a sensitive operation is accepted.
| Review item | Question |
|---|---|
| Preconditions | Are all required conditions verified before the operation is executed? |
| Ownership | Is the actor authorized to modify the affected resource? |
| Sequence | Can required steps be skipped or reordered? |
| Replay | Can a sensitive operation be repeated when it should only occur once? |
| Limits | Are quantity, frequency, monetary or resource limits enforced server-side? |
| Concurrency | Can simultaneous requests produce an invalid business state? |
Assessment
| Condition | Assessment consideration |
|---|---|
| Adequate design | Security requirements are defined and supported by enforceable architectural and workflow controls. |
| Missing requirement | A necessary security property was not defined or considered. |
| Missing control | The requirement exists, but the design provides no effective mechanism to enforce it. |
| Bypassable design | A legitimate alternative workflow can circumvent the intended security control. |
| Unsafe assumption | A security-critical decision depends on an untrusted client, user behavior or undocumented operational assumption. |
Failure criteria
The application's password-reset architecture provides account recovery based solely on a user-controlled account identifier and does not require sufficient proof of control over the account. The weakness is architectural because the workflow lacks an adequate identity-verification mechanism rather than merely containing an implementation error.
Remediation
Design-level weaknesses generally require changes to requirements, architecture or business workflows. Adding a superficial validation check may not address the underlying problem.
- Define explicit security requirements for critical business processes.
- Identify realistic abuse cases before implementation.
- Establish trust boundaries and enforce security decisions on the trusted side of those boundaries.
- Apply least privilege to users, services and external integrations.
- Design sensitive workflows with explicit state transitions and server-side preconditions.
- Protect recovery, reset and exception workflows to the required security level.
- Introduce appropriate rate, quantity, transaction or resource limits where abuse is foreseeable.
- Avoid relying on client-side controls for security-critical decisions.
- Use defense-in-depth for high-impact security properties.
- Incorporate security acceptance criteria into the development lifecycle.
If the underlying workflow permits an unauthorized business action, filtering a particular parameter does not necessarily fix the design. The complete security property and workflow must be addressed.
Post-remediation verification
The required security property is enforced by the design and the tested abuse cases no longer violate the intended security boundary.
The design still permits the original abuse case or an equivalent bypass through another workflow.
The design or workflow could not be adequately evaluated using the available documentation, access or test environment.
Evidence requirements
Redact credentials, personal information, production records, session data, security tokens and other unrelated sensitive information before evidence is stored or published.
Classification
| WebOTG procedure | WebOTG-DS-001 |
|---|---|
| OWASP category | A06:2025 — Insecure Design |
| Procedure type | Security architecture, requirement and business-workflow review |
| Assessment result | PASS / FAIL / NOT TESTED |
| Finding severity | Determine according to affected assets, business impact, exploitability, privileges required and the extent to which the design weakness can be abused. |
WebOTG-DS-001 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.
References
| Source | Relevance |
|---|---|
| OWASP Top 10:2025 — A06 | Primary category definition for Insecure Design. |
| OWASP Web Security Testing Guide | Testing methodology relevant to application security assessment. |
| OWASP Application Security Verification Standard | Verification requirements relevant to application security architecture and design. |
| OWASP Threat Modeling | Guidance for identifying threats, security requirements and abuse cases during system design. |
| CWE | Common weakness classifications relevant to design and architectural security deficiencies. |
WebOTG should maintain authoritative source references, document versions and review dates through its content management system so that the procedure can be maintained independently from application code.