Secure Design Patterns: A Reference Catalogue

Most serious application weaknesses are not coding slips but missing controls in the design, and no amount of careful implementation fixes a design that never placed the control. OWASP now ranks Insecure Design as A06:2025 and its first prevention advice is to keep a library of secure design patterns or paved-road components. This guide is that library at reference depth: the principles patterns come from, the patterns themselves grouped by the problem they solve (trust boundaries, identity, authorisation, data, isolation, resilience, observability), how to choose between them, how to roll a pattern catalogue out across teams, and how to tell whether it is working. It is for architects, AppSec engineers and tech leads designing web, API and service-based systems. Patterns for AI agents and LLM tool use are covered separately in the Secure Agent Design Patterns Guide.

Key takeaways

Patterns remove flaw classes, not individual bugs. A shared authorisation layer that denies by default prevents every forgotten check, where code review only finds the ones a reviewer happens to notice.
Every pattern answers one design principle. Complete mediation, least privilege, fail safe and compartmentalisation are the test for whether a proposed pattern actually helps.
Edge checks are never enough. A gateway can reject bad traffic, but object, tenant and business rules must be enforced by the service that owns the data.
Prefer identities to secrets. Workload identity, mTLS and short-lived tokens make service-to-service trust verifiable and revocable, where shared static keys are neither.
A catalogue only works as a paved road. Patterns delivered as libraries, templates and platform defaults get adopted; patterns delivered as a PDF get ignored.

Principles first: where secure design patterns come from

A design pattern is a reusable answer to a recurring problem. A secure design pattern is one whose purpose is to make a security property hold by construction. The classic principles were set out by Saltzer and Schroeder in 1975 and are still the vocabulary used by the OWASP Developer Guide, NIST SP 800-160 Vol. 1 Rev. 1 (Engineering Trustworthy Secure Systems) and the NCSC design principles. Use them as acceptance criteria: if a pattern does not advance at least one, it is not a security pattern.

Principle	What it demands of a design	Patterns that implement it
Complete mediation	Every access to every object is checked, not just the first request	Central policy enforcement point, per-request token validation, object-level authorisation
Least privilege	Each component holds only the access it needs, for as long as it needs it	Scoped workload identities, privilege separation, just-in-time elevation
Fail safe defaults	Errors and missing rules result in denial	Deny-by-default policy, fail-closed validation, allow-lists
Compartmentalisation	Compromise of one part does not expose the rest	Tenant isolation, bulkheads, sandboxed processing, network segmentation
Separation of duties	No single actor can complete a sensitive task alone	Four-eyes approval workflow, split signing and release roles
Economy of mechanism	Security logic is small enough to verify	One shared authorisation library instead of per-endpoint code
Least common mechanism	Components at different trust levels do not share state or channels	Separate queues, caches and keys per tenant or trust tier
Open design	Security rests on keys, not on secrecy of the design	Standard protocols (OAuth 2.0, TLS 1.3), published crypto, no home-grown schemes
Psychological acceptability	The secure path is the easy path	Paved-road templates, secure defaults, SDKs that hide crypto choices

The NCSC groups its principles into five aims that make a good structure for a design review: establish the context, make compromise difficult, make disruption difficult, make compromise detection easier, and reduce the impact of compromise. The rest of this guide is organised by the concrete problem each pattern solves. For how these principles show up in policy and regulation, see the Security by Design and by Default Guide.

Trust boundary and choke point patterns

The first design act is to draw trust boundaries: every place where data or control crosses from a less trusted zone to a more trusted one. CWE-501 (Trust Boundary Violation) is one of the weaknesses OWASP maps to Insecure Design, and it arises when trusted and untrusted data are mixed in the same structure.

Single ingress choke point: All external traffic enters through a gateway or reverse proxy that terminates TLS, authenticates the caller, applies coarse authorisation and rate limits, and normalises requests. Direct access to back-end services from outside is blocked at the network layer, not just by convention. See the API Gateway Security Guide.
Edge plus service authorisation: The OWASP Microservices Security Cheat Sheet is explicit that gateway checks complement service controls and do not establish that a downstream operation is authorised. The gateway rejects unauthenticated or obviously out-of-scope requests; each service enforces object, tenant and business rules for the data it owns.
Validate at the boundary, then trust the type: Parse untrusted input once, at the boundary, into a strict domain type (an EmailAddress, an OrderId, a bounded Quantity), and pass only that type inwards. Inner code never sees raw strings, so it cannot forget to validate. Pair it with context-specific output encoding at the point of use. See the Input Validation and Output Encoding Guide.
Outbound request broker: Server-side fetches of user-supplied URLs go through one egress component with an allow-list of destinations, blocked link-local and metadata ranges (169.254.169.254), and no redirect following. This is the design answer to server-side request forgery.
Plausibility checks at every tier: OWASP A06:2025 recommends plausibility checks in each tier, for example rejecting a negative refund amount in the service even if the front end already blocks it. Each tier assumes the one in front of it can be bypassed.

Identity and service-to-service trust patterns

Services need to know who is calling them, and the answer must be verifiable without trusting the network. Three patterns cover most designs, and they are usually combined.

Pattern	How it works	Strengths	Watch for
Mutual TLS between services	Each workload holds a key pair and certificate; both ends authenticate during the TLS handshake	Peer identity plus confidentiality and integrity in transit; works below the application	Key provisioning and trust bootstrap, revocation and rotation (the challenges OWASP lists); needs a private PKI or SPIFFE-style issuer
Signed access tokens, local validation	Caller obtains a signed token (for example a JWT access token per RFC 9068) from a token service; receiver checks signature, issuer, audience and expiry	No per-request call to the issuer; carries scopes and service identity	Cannot see server-side revocation before expiry, so lifetimes must be short (minutes)
Token introspection, online validation	Receiver asks the authorisation server whether the token is active	Immediate revocation	Latency and a hard dependency; cached answers must have bounded lifetimes
End-user identity propagation	The authenticated user context travels with the request in a form each service can validate, separately from the calling service's own identity	Services can enforce user-level rules deep in the call chain	A signed assertion proves integrity, not permission: the receiver still makes its own decision

Two rules apply to all of them. First, reject the request if validation cannot complete; never fall back to "allow". Second, replace long-lived shared secrets with platform-issued workload identities wherever the platform supports it, so a credential is bound to a workload and expires on its own. See the Cloud Workload Identity Guide and the SPIFFE and SPIRE Guide.

Authorisation patterns

Broken access control remains the most common serious web flaw because authorisation is usually scattered across handlers. The design fix is structural.

Externalised policy (PDP and PEP): Separate the policy decision point, which evaluates rules, from policy enforcement points in each service, which ask and obey. Rules live in one versioned, testable place (policy as code) and enforcement is a single call. See the Policy-as-Code for Authorisation Guide.
Deny by default: The OWASP Authorization Cheat Sheet lists deny by default and validating permissions on every request as core recommendations. In practice the framework's default for a new route is "forbidden" until a rule says otherwise.
Object-level checks in the data layer: Every query that loads a record by identifier also constrains by owner or tenant (WHERE id = ? AND tenant_id = ?), ideally enforced by a repository layer or database row-level security rather than by each handler. Unguessable identifiers help, but OWASP is clear they are not a substitute for the check.
Model choice: OWASP prefers attribute- and relationship-based access control over pure RBAC because roles alone cannot express "editors of this document". See the Authorisation Models Guide.
Four-eyes for high-impact actions: Payments above a threshold, role grants and production deletions require a second, independent approver recorded in the audit trail.

Data protection patterns

Data minimisation by design: Do not collect or store a field unless a named feature needs it; the safest data is data the system never held.
Tokenisation: Replace sensitive values (card numbers, national identifiers) with tokens at the point of capture and keep the mapping in a small, isolated vault service. Most of the estate then handles only tokens and falls out of the sensitive scope.
Envelope encryption: Encrypt data with per-object or per-tenant data keys, and encrypt those keys with a master key held in a KMS or HSM that never leaves it. Rotation and crypto-shredding become key operations, not data rewrites. See the Envelope Encryption and KMS Integration Patterns Guide.
Secrets out of code and config: Credentials are fetched at runtime from a secrets manager or replaced by workload identity. OWASP maps CWE-256 (Unprotected Storage of Credentials) and CWE-522 (Insufficiently Protected Credentials) to Insecure Design because storage location is a design decision. See the Secrets Management Guide.
Log redaction at source: Structured logging libraries mask known sensitive fields before emission, so tokens and personal data never reach the log pipeline.

Isolation and containment patterns

These patterns assume something will be compromised and limit how far it spreads, the NCSC aim of reducing the impact of compromise.

Pattern	Problem it solves	Typical implementation
Privilege separation	A parser or network-facing component holding high privileges	Split into a small privileged process and an unprivileged worker that does the risky work (the model OpenSSH uses)
Sandboxed processing	Untrusted files, images, documents or code	Process in a separate container or microVM with no network, read-only filesystem, CPU and memory limits
Tenant isolation	One customer reaching another's data	Silo (per-tenant stack), bridge (shared compute, separate databases) or pool (shared everything with enforced tenant context); segregate tenants across all tiers, as OWASP A06:2025 advises. See the Multi-Tenant SaaS Architecture Security Guide
Bulkhead	One failing or abused dependency exhausting shared resources	Separate thread pools, connection pools and queues per dependency or customer tier
Tier segregation	Lateral movement from an exposed tier	Network policy allowing only declared flows between presentation, application and data tiers
Upload quarantine	CWE-434 unrestricted upload of dangerous file types	Store uploads outside the web root under generated names, verify type by content, scan, then release

Resilience and abuse-resistance patterns

Rate limiting and quotas: Per identity, per tenant and per endpoint, enforced at the edge and again for expensive operations in the service. See the Rate Limiting and API Abuse Guide.
Timeouts and circuit breakers: Every outbound call has a timeout; a circuit breaker stops calling a failing dependency and returns a safe degraded response. Make sure the degraded response fails closed for security decisions: if the policy service is down, deny.
Idempotency keys: State-changing APIs accept a client-supplied key and return the stored result for repeats, which defeats double-spend through retries. Combine with transactional checks to address race conditions (CWE-362).
Explicit state machines: Model orders, accounts and workflows as states with allowed transitions. OWASP notes that insecure design includes failing to define unwanted state changes; a state machine makes "refund after refund" impossible rather than merely unlikely.

Observability and audit patterns

The NCSC aim of making compromise detection easier is a design property: if events are not emitted with context, no monitoring tool can recover them later.

Central log pipeline: The pattern in the OWASP Microservices Security Cheat Sheet: services write to stdout or a local file, a host agent buffers and forwards over mTLS to a broker, and a central service processes logs. Agents hold least-privilege broker access and report their own health.
Correlation IDs: Generated at ingress and propagated through every call so one user action can be traced across services.
Security event schema: Authentication success and failure, authorisation denials, privilege changes, policy changes and data exports are emitted as named, structured events, not free text.
Tamper-evident audit trail: Audit records go to an append-only store that application identities cannot modify or delete.

Choosing patterns: decision guidance

Situation	Start with	Add when it grows
Monolith, one team	Framework-level deny by default, boundary validation, secrets manager, repository-layer tenant filter	Externalised policy once more than one service needs the same rules
Microservices on Kubernetes	Gateway plus service authorisation, workload identity and mTLS via mesh or SPIFFE, network policies	Central PDP, per-tenant keys, bulkheads for noisy tenants
Multi-tenant SaaS	Enforced tenant context in every query, per-tenant encryption keys	Silo model for regulated or large tenants
Processing untrusted content	Sandboxed workers, upload quarantine, outbound request broker	MicroVM isolation for code execution
Regulated data (cards, health)	Tokenisation at capture, envelope encryption, four-eyes on exports	Dedicated vault service in its own account or subscription

Trade-offs: Introspection gives instant revocation at the cost of latency; local validation is fast but needs short lifetimes. Silo tenancy is the strongest isolation and the most expensive to operate. A central PDP improves consistency but becomes critical infrastructure that must be highly available and must fail closed. Small organisations get most of the value from framework defaults and a secrets manager; large ones need a platform team to own the paved road.

How to implement a pattern catalogue

Harvest from incidents and findings: Group the last two years of penetration test findings, bug bounty reports and incidents by flaw class. The top five classes decide the first five patterns.
Write each pattern as a one-page record: problem, context, solution, the principle it serves, the threats it addresses, a reference implementation, tests that prove it, and known limits. Record adoption decisions in architecture decision records; see the Security architecture decision records (ADRs) page.
Ship code, not prose: Each pattern comes with a maintained library, service template or platform setting, so following it is less work than not following it.
Pilot with two teams: Choose one greenfield and one brownfield service. Measure the effort to adopt and fix the template before scaling.
Wire it into design review: Threat modelling sessions ask "which catalogue pattern covers this boundary?" and record exceptions. OWASP's Secure by Design Framework provides a review checklist answered Yes, No or N/A with justification that can serve as the gate. See the Threat Modelling Guide.
Test the pattern, not just the app: Write misuse-case unit and integration tests (another user's ID, missing tenant header, expired token, policy service down) as OWASP recommends, and run them in CI.
Roll back safely: Introduce enforcement in log-only mode where the platform allows (policy engine in audit mode, network policy in observe mode), review denials for a sprint, then enforce. Keep the previous version deployable behind a flag until the new path is proven.

Detection and measurement

Monitor: authorisation denials by service and route (spikes suggest probing or a broken rule), requests reaching services without passing the gateway, token validation failures, egress broker blocks to metadata or internal ranges, and sandbox resource limit hits.
Pattern coverage: percentage of services using the shared authorisation library and workload identity instead of static secrets.
Flaw-class recurrence: count of findings per quarter in classes a pattern targets (IDOR, SSRF, hard-coded secrets). It should fall after adoption.
Exception count and age: open design-review exceptions and how long they have been open.
Misuse-test coverage: share of critical flows with automated negative tests in CI.
Time to adopt: engineering days for a team to adopt a pattern; rising numbers mean the paved road needs work.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SA-8 Security and Privacy Engineering Principles; SA-17 Developer Security and Privacy Architecture and Design	Requiring principles and an architecture from developers
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement; AC-5 Separation of Duties; AC-6 Least Privilege	Authorisation patterns
NIST SP 800-53 Rev. 5	SC-7 Boundary Protection; SC-39 Process Isolation; SC-5 Denial-of-service Protection; SI-10 Information Input Validation	Boundary, isolation and resilience patterns
NIST CSF 2.0	PR.PS-06; PR.AA-05; PR.IR-01; PR.IR-03	Secure development practice, least privilege, environment protection, resilience
ISO/IEC 27001:2022 Annex A	8.25 Secure development life cycle; 8.26 Application security requirements; 8.27 Secure system architecture and engineering principles	Documented engineering principles applied to design
OWASP Top 10 2025	A06:2025 Insecure Design	The risk a pattern library directly addresses

Common failure patterns

Trusting the gateway: Services assume any request that reached them is authorised, so an internal caller or a bypass path gets full access. OWASP warns against exactly this.
Over-privileged component identities: A network-facing component runs with broad data access. In the Capital One breach, a firewall was induced to fetch its own cloud role credentials from the metadata endpoint, and that role could read far more storage than a firewall needs. An outbound request broker and a scoped role are the design fixes. See the EC2 Instance Metadata Service Hardening Guide.
Fail-open fallbacks: When the policy or token service times out, the code path "temporarily" allows the request.
Object checks in handlers: Each endpoint implements its own ownership check, and the one written last forgets it. The root cause of the T-Mobile API breach was never disclosed, but it shows how much data a single abused record-returning API can expose over weeks, which is why per-object checks and volume monitoring belong in the design.
A catalogue nobody can use: Patterns written as principles with no library or template, so each team reimplements them differently.
Shared secrets as service identity: One API key used by many services, never rotated, impossible to attribute or revoke without an outage.

Practitioner checklist

Draw trust boundaries for each system and name the pattern that protects each crossing.
Block direct external access to back-end services and enforce object, tenant and business rules in the owning service.
Make deny by default the framework behaviour for new routes and fail closed when policy or token validation cannot complete.
Replace static service credentials with workload identity, mTLS or short-lived signed tokens.
Route all server-side fetches of external URLs through an allow-listed egress broker that blocks metadata ranges.
Constrain every record lookup by owner or tenant in a shared data access layer or row-level security.
Process untrusted files and code in sandboxed workers with no network and resource limits.
Publish each pattern as a one-page record with a reference implementation and misuse-case tests in CI.
Track pattern coverage, flaw-class recurrence and exception age every quarter.

Secure Design Patterns: Reusable Architecture Patterns That Prevent Whole Flaw Classes