Application Security Architecture and Trust Boundaries

Architecture makes decisions visible

An application can include user interfaces, APIs, backend services, databases, queues, caches, background workers, batch jobs, file uploads, webhooks, external integrations, and administrative interfaces. Each boundary can transform data or make an authorization decision. Authenticated access does not automatically mean an operation is authorized or safe. A useful architecture review identifies who or what crosses a boundary, which data is trusted, and which service enforces the next rule.

Application architecture inventory

Component	Review questions
Entry point	Which client, protocol, identity, validation, rate limit, and error behavior apply?
Service and API	Which operation is privileged, which tenant or object rule applies, and which dependency is trusted?
Data and messaging	What is stored or queued, who can read it, how is it retained, and how are failures handled?
Administration and delivery	Which identity changes configuration, deploys code, reads secrets, or has emergency access?

Trust-boundary questions

Where do browser, mobile, partner, webhook, file-upload, and background-job inputs enter the system?
Which attributes are authentication claims, which are user-controlled values, and which are authoritative application data?
How does each service establish tenant, object, or function-level authorization rather than inheriting it from a previous request?
Where are secrets, keys, tokens, and configuration injected, logged, rotated, or exposed to operators?
Which failure paths create retries, partial completion, duplicate work, stale authorization, or sensitive error output?

Data-flow review workflow

Draw a bounded flow for one important user action, including request, identity, authorization, data store, asynchronous work, external integration, logs, and response.
Mark validation, encoding, encryption, authentication, and authorization boundaries separately. They serve different purposes.
Define expected secure defaults for denied access, missing input, dependency outage, and unfamiliar client behavior.
Review multi-tenant separation, service-to-service trust, administrative planes, and support tooling with the relevant owners.
Retain diagrams, interface contracts, authorization decisions, test evidence, and unresolved abuse cases with the design record.

Fictional SaaS example

A SaaS product accepts document uploads through an API, stores processing jobs in a queue, and posts results to a customer webhook. Review finds that the API authenticates the user but leaves tenant selection to a request field in one worker path. The team changes the worker to obtain tenant context from an authorized job record, scopes webhook signing and retries, and logs authorization failures without storing document contents. The design becomes easier to review because each trust decision has an owner and evidence path.

Common architecture mistakes

Common mistakes include treating a gateway as the only authorization layer, relying on client-side checks for privileged operations, sharing service credentials across environments, or omitting background jobs and support consoles from the diagram. Dependency risk also includes availability and integrity: a trusted external service can return incomplete, delayed, or unexpected data that needs bounded handling.

Abuse-case checklist

For a sensitive workflow, ask what happens when a caller uses a valid account for another tenant, repeats a request, submits malformed data, reaches a deprecated client path, triggers a timeout, or causes a downstream dependency to return an unexpected response. The answer should name the enforcing service and evidence source, not just a product setting. Include support and administrative workflows because they can bypass ordinary user paths. These questions guide design review; they are not a substitute for approved testing and implementation review.