OWASP Risks

Definition

A periodically updated list of the most impactful web application security risk categories. Its value to an architect is not as a checklist but as a map of which risks are addressed by structure rather than by code review.

The categories that are architectural

Broken access control is consistently the largest category, and it is fundamentally architectural. The failure is nearly always the same shape: authorisation checked in some places and not others, because it is implemented per endpoint by whoever wrote it. The structural remedies:

• Authorisation enforced in a single layer that cannot be bypassed, rather than in each handler.
• Deny by default, with access explicitly granted.
• Object-level checks, not just endpoint-level — the classic failure is GET /orders/{id} that verifies the user is logged in but not that the order is theirs.
• Never trusting the network position. Anything reachable internally must still authenticate.

Cryptographic failures — usually sensitive data transmitted or stored without protection, or with keys handled badly. Architectural remedy: classify data, encrypt in transit everywhere, and use a managed key service.

Injection is largely solved structurally: parameterised queries and safe templating make it impossible rather than unlikely. Where it persists it is because a component builds strings.

Insecure design — the category acknowledging that some flaws are not implementation bugs. Threat modelling at design time is the control.

Security misconfiguration — default credentials, verbose errors, unnecessary features, public storage. Remedy: infrastructure as code plus policy enforcement, so the wrong configuration cannot be deployed.

Vulnerable and outdated components — remedied by dependency scanning in CI, a software bill of materials, and a patching cadence that is a policy rather than an intention.

Server-side request forgery — an application fetching a URL it was given. Remedy: egress allowlisting, and blocking the metadata endpoint from workloads.

The architect's use of the list

Not to audit code, but to ask: for each category, is there a structural control, or are we relying on every developer getting it right every time? Categories where the answer is the latter are the ones that will produce an incident.

Interview question

"Broken access control is consistently the top risk. What architectural decisions make it less likely, rather than relying on review?"