OWASP A04
Testing for Insecure Design
Every other category on the list is something built wrongly. This one is something never built at all — a control the design does not contain, which no amount of correct implementation will produce.
- Found through threat modelling and abuse cases, not payloads
- Covers business logic that behaves exactly as written
- Design guidance delivered as architecture, not patches
What insecure design looks like in a real application
A lending platform lets an applicant upload supporting documents, then lets them edit the application after upload. Every endpoint authorises correctly, every input is validated, nothing is injectable. An applicant can submit clean documents, pass automated review, then amend the declared income before final approval. No control was implemented incorrectly. The control that should have frozen the application at review was never designed.
This is the category that automated tooling cannot approach even in principle, because there is no defect to detect. The application is working.
The insecure design variants we test for
- Workflow sequence bypasses — reaching a later state without completing an earlier one, or returning to an earlier state after approval
- Missing rate and volume limits on operations that cost money, send messages, or consume finite inventory
- Race conditions on limited resources: coupon redemption, credit limits, stock, referral bonuses and withdrawal requests
- Trust boundary assumptions where client-side calculation, ordering or validation is accepted by the server
- Absent segregation of duties, letting one identity both request and approve a privileged action
- Insufficient anti-automation on enumeration, scraping and credential testing paths
- Recovery and support flows designed for convenience, which frequently bypass the authentication they sit behind
- Economic logic — refunds, partial cancellations, currency rounding and discount stacking producing unintended value
How we test for insecure design
This work starts before any request is sent. We build a model of what your application is for, who the actors are, what each of them wants, and what an actor might want that you would not want them to have. That produces abuse cases, which are the test plan.
The most productive question is rarely "can I break this input?" but "what does this feature assume about the person using it?" Features built for trusted internal users and later exposed to customers are a reliable source of findings, as are flows where a human review step was replaced by automation without adding the controls the human was providing.
We test concurrency deliberately, because race conditions in financial logic are common, are rarely covered by functional tests, and have immediate monetary impact.
Why this category needs your team in the room
We can infer intent from an application, but we cannot read it. A scoping session with someone who knows why a flow exists shortens this work considerably and materially improves what we find. Where a specification exists, testing against it is faster and more precise than reverse-engineering the intent from behaviour.
How insecure design gets fixed
- Enforce state machines on the server: define legal transitions and reject everything else rather than trusting the client's step order
- Make privileged actions require a second identity where the business consequence justifies it
- Apply limits by business meaning — per account, per instrument, per day — not only per IP address
- Handle concurrency with database-level guarantees rather than application-level checks
- Re-run the threat model when a feature's audience changes, since exposure changes the control requirement
Common questions
How is insecure design different from a misconfiguration?
A misconfiguration is a control that exists but is set wrongly, and it is fixed by changing a setting. Insecure design is a control that does not exist in the system's architecture, and it is fixed by building something. That is why these findings often carry a longer remediation timeline and need product decisions rather than only engineering work.
Can you find design flaws without our documentation?
Yes, but less efficiently. Without documentation we infer intent from behaviour, which finds the obvious cases and misses assumptions that are not visible from outside. An hour with someone who can explain why a flow exists typically produces more findings in this category than a day of black-box probing.
Is threat modelling included in a standard engagement?
A working threat model is built during scoping on every engagement, because it determines where exploitation effort is spent. A formal, documented threat modelling exercise delivered as its own artifact is separate work, and we will tell you during scoping whether your situation warrants it.
How do you test for race conditions?
By issuing the same operation concurrently and checking whether the business rule survives. Redeem one coupon in twenty simultaneous requests, submit two withdrawals against one balance, or accept the same invitation repeatedly. Functional tests almost never cover this because they run sequentially, and financial logic is where the consequences are immediate.
Can design flaws be fixed without rebuilding the feature?
Sometimes. Where the missing control is a server-side state check or a limit, it can be added without redesigning anything. Where the design assumed a trusted user and that assumption is now false, the honest answer is that a patch will not hold. We say which of the two you are facing rather than presenting every design finding as a rebuild.
Do you test business logic in payment and refund flows?
Yes, and it is usually where we spend the most time on a commerce or fintech platform. Partial refunds, cancellations after fulfilment, currency rounding, discount stacking, retries against an idempotency key and reconciliation between your records and the provider's are all places where legitimate functionality produces unintended value.
Who from our team needs to be involved?
Someone who can explain why a flow exists, which is usually a product owner or a senior engineer rather than a security contact. One scoping conversation about intended behaviour typically produces more findings in this category than a day of probing from outside, because we stop guessing what the application was supposed to prevent.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.