Application Architecture Security Review: Decisions, Boundaries, and Proof

An application architecture security review asks whether the system’s design makes its security promises achievable before implementation details harden around the wrong assumptions. It is most useful when a team is choosing a target architecture, splitting a service, introducing a new identity provider, moving sensitive data, or adding an asynchronous workflow. The review should produce decisions an engineer can implement and a proof plan a risk owner can understand.

Consider a fictional multi-tenant design-file platform. A project member asks the system to prepare a large CAD archive for an external partner. The API checks the member’s access and places a job on a queue. Before the worker runs, the project owner removes that member and withdraws the partner’s access. The worker later creates the archive and a share link because the request was valid when it entered the queue.

No single component is obviously broken. The API authenticated the user, the queue delivered a valid message, and the worker completed the requested task. The unresolved issue is architectural: does authorization attach to the moment of request, the moment of disclosure, or a narrowly bounded delegation that survives between them? A review makes that choice explicit, examines its failure cases, and states how the chosen behavior will be proved.

That focus separates this work from a broad application security audit, which may examine architecture, code, configuration, APIs, and deployed behavior together. It also differs from a source code security audit, which traces security decisions through a particular code revision. Architecture review works earlier and at a different level: relationships, authority, data movement, failure semantics, and design alternatives.

Start with the decision the review must support

“Review the architecture” is not yet a scope. Name the pending decision: approve a proposed design, choose between two identity patterns, decide whether a migration reduces risk, or identify conditions that must be met before release. Record the decision owner, the date by which the decision is needed, and the security outcomes that matter. A review for a prototype can tolerate open implementation questions that would block a production launch.

Establish two baselines. The current state describes what actually exists, including temporary bridges, manual operations, inherited trust, and undocumented integrations. The target state describes the proposed design and the transition needed to reach it. Mixing the two creates false conclusions. A target diagram may show service identity everywhere while the migration still routes some calls through a shared credential. Conversely, a current-state weakness may already have a funded, testable replacement.

The input pack need not be beautiful, but it must be specific. It usually includes component and deployment views; human, service, and administrative identities; data classifications and stores; synchronous and asynchronous flows; external providers; key management; deployment and support paths; important business invariants; known constraints; and earlier findings. The reviewer should mark conflicts in those materials instead of silently choosing whichever diagram looks newest.

The first deliverable is therefore a question set, not a vulnerability list. Which actor is allowed to cause which effect? Where is that decision made? Which component can change the rules? What happens if an identity is revoked, a message is duplicated, a dependency is unavailable, or a recovery operator intervenes? Which parts are observations and which are assumptions?

Draw current and target trust boundaries separately

A useful model shows actors, components, data stores, flows, trust zones, and assumptions. A trust boundary is more than a network line. It appears wherever the basis for trust changes: browser to API, workload to workload, tenant service to shared platform, customer account to provider control plane, production service to support tooling, or queue producer to consumer. Encryption may protect a connection while leaving the authorization relationship undefined.

For every crossing, record the calling identity, the receiving identity, how each is authenticated, what authority is conveyed, what context is lost, and which side enforces the decision. A gateway can validate a token, but the downstream service may still need to verify that the token was intended for it and that the requested action is allowed. Network location alone is a weak substitute for workload identity in environments with proxies, load balancers, dynamic addresses, and multiple clusters.

Keep the control plane visible. A service may have a narrow data-plane API while its deployment identity can replace images, change secrets, rewrite routing, or attach a more privileged runtime role. An administrator who cannot read a customer record through the product UI may still be able to snapshot its database. The review should connect these control-plane powers to owners, approval paths, emergency access, logs, and revocation. “Internal” is not an identity or an authorization policy.

Follow data until it is gone

“Encrypted at rest” is not a data lifecycle. For each sensitive data class, trace collection, validation, use, derived copies, caches, search indexes, telemetry, support exports, backups, archival, and disposal. Record the owner and the required protection at each stage. A deletion design must say what happens to replicas, object versions, search documents, queued payloads, and restoration from an older backup.

This exercise often changes the architecture question. A team may be debating database encryption while the larger exposure is a long-lived analytics export or a diagnostic log available to a broad support role. Another team may minimize its primary record but keep the same identifiers in a dead-letter queue without a retention owner. The review should distinguish data required for the service, data retained for a stated reason, and copies that exist only because nobody designed their end of life.

Treat asynchronous work as an authorization path

Queues, schedulers, webhooks, event buses, and workflow engines cross time as well as component boundaries. The producer and consumer do not share a request context, the user may no longer be present, and policy may change before the effect occurs. The message therefore needs an explicit security meaning. Is it merely a request to reconsider an action, an immutable command already approved, or a constrained delegation to perform one effect before a deadline?

Delivery semantics also matter. An at-least-once queue, such as a standard Amazon SQS queue, can deliver a message more than once. A worker can finish the external effect and crash before acknowledging completion. A timeout can cause another worker to start. Repeated failures may eventually move a message to a dead-letter queue, where a human or tool can replay it. The architecture must define idempotency, deduplication scope, ordering assumptions, maximum age, retry limits, poison-message handling, and who is allowed to replay or edit failed work.

Return to the fictional CAD export. The queued message should not simply contain a project ID and the user’s original role. The design must decide how the worker knows the allowed project, recipient, data selection, expiry, and action. It must also decide what revocation means. If policy requires current access at disclosure time, the worker needs a fresh authorization decision and a safe outcome when the policy service is unavailable. If the business intentionally allows already approved work to complete, the system needs a narrowly scoped, expiring delegation and an audit trail that makes that exception visible.

1. ModelDraw current and target actors, stores, control planes, synchronous calls, queues, and trust changes
2. DecideState the invariant, compare alternatives, choose an owner, and record the residual risk
3. SpecifyTurn the choice into identity, authorization, data, retry, revocation, and observability requirements
4. ProveAssign inspection, automated checks, integration tests, fault tests, or authorized runtime validation to each claim
5. RevisitTrigger review when a boundary, provider, sensitive data flow, or control-plane authority changes

Distributed applications need this treatment across every service chain. The practical scoping problems are explored further in the microservices penetration testing guide, but an architecture review should decide the intended relationships before a runtime test tries to break them.

Compare alternatives against explicit criteria

A security review should not turn the reviewer’s favorite pattern into a universal rule. NIST’s systems security engineering approach treats design as a trade space: define desired outcomes and measurable selection criteria, identify alternatives, evaluate each, then preserve the rationale. Security is one criterion alongside availability, latency, operability, cost, privacy, and migration risk.

For the export workflow, four legitimate models exist. Each can be secure in a suitable context, and each creates different proof obligations.

The selected model should be written as an invariant. If revocation must take effect immediately, for example: “The system serves every download request only while the project currently grants that partner access.” That choice requires a reliable authorization decision on every download and explicit handling of policy outages and release-versus-revocation races. If the team instead chooses a short-lived delegation, the invariant must name the allowed action, resource, expiry, and revocation window. Checking when a link is issued must not be presented as checking every later download. Either form is stronger than “authorization is handled by the API gateway” because it names the actor, object, effect, and decision time.

Identity design needs the same precision. For human federation, separate the identity provider’s assertion from the application’s authorization decision. For workload calls, name the caller and intended receiver. Where OAuth access tokens are used, restrict privileges and audience to the resource server and actions that need them, and require the receiver to verify those restrictions. A broad token accepted by many internal services can let one compromised component reach other services within the authority granted by that token.

Apply this reasoning to administrative paths as well. Who can change a tenant’s policy, issue a service identity, replay a dead-letter message, restore a backup, or bypass a failed dependency? Emergency access may be necessary, but its conditions, duration, approval, and evidence should be part of the design rather than an unwritten operational shortcut.

Separate validated facts from assumptions

Every architecture contains assumptions. The problem is not having them; it is allowing them to masquerade as controls. Maintain an assumption ledger with a statement, owner, reason, consequence if false, validation method, due date, and status. Useful statuses are validated, partially validated, unvalidated, and invalidated. “The queue is private” is too vague. “Only the export API’s workload identity can send to this queue in the production account” can be checked against a policy and a deployment.

Some assumptions are design constraints: the identity provider must be available for interactive access. Some are environmental: a managed key service provides a stated boundary. Some are behavioral: consumers process each job idempotently. Some concern transition: no shared credential remains after migration phase two. Each type needs different evidence.

The proof plan should accompany the target design. Inspection can confirm that an interface contract requires an audience and expiry. Configuration analysis can compare deployed policies with the intended call graph. Unit and integration tests can exercise tenant binding, invalid audiences, revocation, and duplicate delivery. Fault-oriented tests can cover timeouts, partial completion, stale policy data, retry storms, and dead-letter replay. Observability checks can show that denied calls, privileged changes, and replay operations produce useful records.

Evidence must match the claim. A successful happy-path test does not validate fail-closed behavior. A policy document does not show the deployed policy. A dashboard showing no denied calls does not prove denial is enforced. An architecture review can define the required evidence and inspect available artifacts, but it should label anything awaiting implementation or runtime confirmation as unvalidated.

For API-heavy systems, the REST API security assessment guide explains how contracts and deployed behavior can be compared. For multi-step invariants, the business logic security testing guide explains why valid individual requests can still form an invalid outcome. Those runtime methods can close specific proof obligations; they do not replace the design decision.

Accept a decision record, not a generic checklist

A useful report lets an architect, developer, operator, and risk owner reach the same understanding. It should contain the decision and scope; current and target diagrams; actor and authority matrix; sensitive-data lifecycle; synchronous, asynchronous, and administrative paths; assumptions and their status; threats tied to affected design elements; alternatives considered; selected controls; residual risks; and a proof plan with owners and acceptance criteria.

Findings should distinguish four things. A design defect means the current or proposed architecture violates an agreed security objective. An unresolved decision means credible alternatives remain and an owner must choose. An unvalidated assumption means the conclusion depends on evidence that is not yet available. An implementation verification item means the design is clear but code, configuration, or deployed behavior still needs confirmation. Combining these into one severity list encourages teams to “fix” an unanswered question with a ticket title.

The report should also state what was not established. A document review cannot prove network reachability, token validation in every service, deletion from every replica, or behavior under actual failure. It cannot certify that the system is secure. Its value is traceability: each important promise leads to a design decision, a responsible component, and evidence required for acceptance.

Review triggers belong in the deliverable. Revisit the model when a trust boundary moves, a new identity or administrator appears, a sensitive data class gets a new destination, a synchronous call becomes queued, a provider takes on more authority, or a recovery path changes. Otherwise, the target diagram becomes a historical illustration while the real system evolves elsewhere.

Use runtime validation where the proof plan requires it

Runtime testing is useful when a design claim depends on deployed behavior: whether a service rejects a token for the wrong audience, whether tenant authorization is enforced after a queue retry, whether a revoked partner can obtain a prepared artifact, or whether a support role can reach data through an administrative path. These questions can be included in an authorized web application pentest with suitable accounts, roles, test data, environments, and safety limits.

Pentest.red can help turn selected architecture proof obligations into a bounded validation scope. The pentest scope planner records the systems, identities, workflows, exclusions, permitted actions, testing window, and expected evidence before work begins. Testing requires written authorization from every owner whose systems are in scope. The result establishes observed behavior only for the agreed environments, roles, conditions, and time; it is not certification and cannot show that every architectural weakness has been found.

The review is complete when the team can explain the security decision without pointing at a decorative diagram: which boundary matters, whose authority crosses it, what happens to data and queued work, which alternative was selected, which assumptions remain open, and what evidence will show that the implemented system keeps the promise.