Insecure Design: Asking Security Questions Before the Code

Insecure Design is the sixth category in the OWASP Top 10:2025. While organizing this part of my PWPA reading, I kept returning to the assumptions behind a feature.

What must remain true for the feature to be safe? Which actions should be impossible? What happens when someone uses a valid feature in a way the designer did not intend?

Those questions can reveal problems before there is any code to review.

Design and implementation need different attention

A design can specify a necessary security control, and the implementation can still get it wrong. A design can also omit that control altogether.

For example, a recovery process may work exactly as specified while relying on information that another person could easily discover. Improving the code's error handling would not resolve that underlying choice of identity evidence.

OWASP's Insecure Design guidance makes this distinction because the causes and remedies differ. Implementation review remains important, and the requirements and workflow need their own review too.

A reservation feature as a study example

Imagine a workshop booking system that lets a visitor hold a place while completing registration.

That sounds useful. Now consider the details:

How long can a place remain on hold?
How many holds can one person create?
What stops someone repeatedly renewing holds without completing registration?
What happens when two requests try to reserve the last place at the same time?
When does an abandoned reservation release capacity?

A system could correctly process every individual request and still let one person tie up all the available places. The missing limits or state-transition rules would need to be addressed in the design.

The right answers depend on the service. A small free workshop and a high-demand ticket sale may need different protections. The exercise helps identify what the application needs to protect and how the business expects it to behave.

Make the security requirement concrete

“The booking system must be secure” leaves a lot open to interpretation.

A more useful requirement would describe when a hold expires, which states may follow one another, and what the server must check before confirming a booking. The design also needs a clear outcome when the operation cannot finish.

These decisions give developers and testers something specific to examine. A test can check whether an expired hold is rejected or whether concurrent requests exceed capacity.

Use threat modeling to examine assumptions

Threat modeling gives this discussion a structure. It starts with understanding the system, its data flows, and the boundaries between different levels of trust. From there, the team considers likely threats, chooses responses, and checks whether those responses are sufficient.

For the booking example, I would sketch the browser, application, booking store, and any external service. Then I would ask which component is allowed to make each decision. A browser displaying one available place does not establish that the place is still available when the request reaches the server.

The OWASP Threat Modeling Cheat Sheet also emphasizes revisiting the model as the system changes. A new API or integration can introduce assumptions that were absent from the original design.

Keep the decisions through development

Reusable, reviewed components can help teams implement common controls consistently. They still need to fit the feature's requirements.

The important design decisions should appear in the work developers and testers use: requirements, acceptance criteria, diagrams, and tests. Security expertise also needs time in the project plan, including after the first release.

My takeaway

This category encourages me to ask about unwanted behavior alongside the intended user journey. A feature's security requirements become much clearer when I can describe what must be prevented and how the application should respond.

Next is Authentication Failures, where the questions follow account access from sign-in through recovery and logout.

Sources and further reading