Security by Design — Part 2 of 3
An architecture diagram can look reassuring. Clean boxes, well-aligned arrows, familiar logos. Yet the most important question is rarely what a box is called.
It is what we assume about the thing on the other side of the arrow.
That arrow might carry a request from an untrusted browser, an identity assertion, a clinical record, a deployment credential or a message from another organization. Each crossing changes what the receiving system must verify.
Follow the data, not just the components
Take a deliberately simplified example: a person uses a browser to access a service backed by an API and a database. An identity provider helps establish who the person is. The application must still decide whether that person may carry out the requested action.
Illustrative architecture, not a universal technology prescription. The important part is the decision at each boundary, not the choice of a particular framework or proxy.
Here are the questions I would ask as we trace a request from left to right:
- Browser to application: What can the client claim, and which claims must the server independently verify?
- Application to identity provider: How are identity assertions validated, how long are they trusted and what happens when they expire?
- Application to data: Who decides that this user may access this exact record, not merely this category of records?
- Service to service: Is the calling workload identifiable, scoped and auditable on its own terms?
- System to operations: What can be observed without leaking personal data, tokens or secrets into logs?
Authentication is only one part of the story
A valid token is useful evidence of an authentication event or a delegated authority, depending on its type and claims. It is not a universal permission slip.
Suppose a user is allowed to view their own request. If an endpoint accepts a different request identifier without checking its relationship to the user, the architecture has lost its authorization decision. Strong sign-in does not repair that gap.
This is why I prefer to write authorization requirements as actions on resources: this actor may perform this operation on this object under these conditions. It is less ambiguous than "access restricted to authenticated users".
Make the assumptions testable
| Boundary | Design decision | Evidence to ask for |
|---|---|---|
| Public client to service | Client input is untrusted; identity is verified server-side. | Tampered claims and invalid sessions are rejected. |
| Application to record | Object-level permission is checked for each relevant action. | A user cannot retrieve another user's record by changing an identifier. |
| Service to data store | The workload has scoped credentials and permissions. | Attempts outside the approved data operations fail. |
| Application to telemetry | Logs provide traceability without exposing sensitive content. | Representative logs contain no credentials or personal payloads. |
These are examples, not a complete assurance argument. Different systems will have different boundaries. The goal is to replace vague confidence with statements that can be checked.
The diagram is a conversation starter
One useful practice is to draw the same system twice. The first view shows the components and connections. The second overlays the trust boundaries, identities, data sensitivity and authorization decisions.
If the second drawing is difficult, that is often a sign the design still contains unanswered questions. Better to find them in a workshop than in a production incident.
The OWASP Threat Modeling project organizes this thinking around four questions: what are we building, what could go wrong, what will we do about it and did we do enough? For applications, the OWASP ASVS helps translate some of those answers into verifiable requirements.
Security architecture becomes more useful when it explains why a connection is trusted, under which conditions, and how that trust can fail.
Continue: Secure Defaults: The Safest Path Should Be the Easiest. Or go back to Security by Design Is Not a Final Gate.