Security Pattern – API based Microservices
Overview
The following security pattern describes security architecture for enabling microservices-based applications exposing Restful API’s.
The microservices architecture is built around decoupled components that are separated into individual self-contained applications, and invoke each other across network communication services. Microservice applications represent small, loosely coupled entities that communicate with each other (typically) via RESTful interfaces over HTTP/S.
This differs in comparison to traditional monolithic architectures, whereby each component invokes another using internalised methods via shared memory or system resources within the same host.
The document focuses on the challenges associated to establishing a microservices architecture and the typical methods of deployment.
Typically Challenges
- The decoupled nature of microservice applications increases the risk of inadvertently exposing internal functionality and components. Threats can target weakness within those microservices by directly communicating across exposed API interfaces on the network.
- API based Microservices typically form a broader eco-system of interactions for multiple different consumers. API endpoints exposed may be consumed by a blend of internal, public or partner APIs clients with different security postures. These models also break down traditional perimeter based network segregation (DMZ) for securing web application services.
- Microservices architecture allow for faster and more agile development cycles, but subsequently can allow for broader logic flaws to occur due to additional complexity of managing distributed systems.
Scope
The scope of this document is for addressing the security threats that relate to
ID | Description | Example |
---|---|---|
01 | Deployment and execution of restful API-based microservices | Node.js microservice application |
02 | Consumption of microservices from internal and external clients | External B2B (Partner) and B2C (Consumer) clients |
Out of Scope
ID | Description of exclusion | Reason for Exclusion |
---|---|---|
01 | This pattern does not cover SOAP based services or XML structured communications. | These services require additional considerations to threat modelling and web app security. |
02 | This pattern does not cover microservices using web sockets | Controls applied for Restful APIs may not be applicable. |
03 | Application development environments and tooling for Microservices | Covered under broader security patterns such as Source Code Management and CI/CD Pipelines. |
Dependencies
ID | Description | Impact from dependency not met |
---|---|---|
01 | Summarised security design principles outlined under Jericho Forum® Commandments. https://publications.opengroup.org/w124 | Minimal impact as these principles are used as an example set of baseline requirements within security pattern. |
Constraints
ID | Description | Impact from constraint |
---|---|---|
01 |
Assumptions
ID | Description | Impact if assumption is false |
---|---|---|
01 | Design decisions assume microservices conform to typically practices in Restful API design. | Non-conformance to best practise for Restful API will require separate considerations to controls required. |
02 | Design decisions assume microservices deployed within containerisation. | Different threat modelling maybe required for other technology services used to deploy microservices. |
Assets at Risk
The following section provides a list of assets affected by the problem statement:
Asset Title | Asset Description |
---|---|
API Microservice | Represents an application that performs a complete and standalone function. It exposes API’s (Application Programming Interface) that provide a set of operations available for consuming data and services. |
API Gateway | Primary function of the API gateway is to route inbound API requests to the correct microservices. It can be used as front-door and enforcement point when exposing API’s to various consumers (such as external, partners and or internal developers). |
API Lifecycle Manager | Allow developers to register, publish, promote and manage API’s exposed via the API Gateway. This includes developer portals for searching and discovering published API’s associated to specific microservices. This also typically integrates into CI/CD tooling used for microservice deployments. |
The following assets are also referenced within the pattern but not in scope
- Identity Provider – Referenced in this pattern to describe services used for authentication of clients.
- Secure Token Service – Referenced in this pattern to describe services used for issuing access tokens for authentication and authorisation.
- CI/CD tooling – Required for deployment of Microservices into target hosting environments.
Threat Model
The following section provides a list of threats within the problem statement:
Threat Event (ID / Title) | Threat Description and Characteristics | Diagram |
---|---|---|
TE-14: Inadequate workflows or processes leading to flaws in deployment | Microservice based applications have increased exposure to flaws in workflows and processes due to their distributed nature. Security controls implemented for upstream components could potentially be skipped or bypassed by directly accessing downstream components (confused deputy scenario). A microservice maybe restricted from accessing sensitive processes, data or information, but can potentially still gain access by forwarding requests via other intermediary or downstream microservices that have approved access. | ![]() |
TE-24: Identity theft or impersonation | Microservices are reliant on passing identity and context within each request for communicating with other microservices. This opens up exposure to replay attacks for tokens, thief of exposed tokens/API Keys in query strings or exposure of unprotected credentials within HTTP header requests. | ![]() |
TE-26: Abuse of resources through misconfiguration | Microservices are vulnerable to flaws or misconfiguration within underlying HTTP/S or TLS protocols, used to expose Restful API’s. Microservices can be compromise if these protocols are not correctly implemented, such as poor TLS certificate validation, restrictions to HTTP Methods or weak TLS ciphers. | ![]() |
TE-29: Web application attacks or code injection attack | Microservice based applications still remain vulnerable to web application attacks and susceptible to command injection, encoding or serialization attacks, cross site scripting (XSS), Cross-Site Request Forgery (CSRF), and HTTP parameter tampering. | ![]() |
TE-40: Distributed Denial of service (DDoS) across application services | Denial of service attackers may overwhelm microservice applications with a flood of HTTP/HTTPS requests. Flaws in processing or load balancing of HTTP traffic may also allow for an application-based DOS attack within microservices. | ![]() |
Target State Solution
Summary
The target state solution evaluates the following design requirements to provide the expected target state solution and design principles.
Design Requirements
The target state solution is required to meet the following requirements, as referenced under Dependencies, Assumptions and Constraints.
Requirement | Implication to Design Principles |
---|---|
1. The scope and level of protection are specific and appropriate to the asset at risk. | Maintain segregation of microservices for connectivity between trust domains and environments |
2. Security mechanisms must be pervasive, simple, scalable, and easy to manage. | The security pattern maintains clear security principles to be applied for microservices |
3. Assume context at your peril. | Controls defined in this security pattern are used to identify and measure problems, limitations or issues |
4. Devices and applications must communicate using open, secure protocols. | Open and encrypted communication channels such as HTTPS are applied for API Microservices |
5. All devices must be capable of maintaining their security policy on an un-trusted network. | API microservices are protected against both external and internal threats |
6. All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place. | Validate and inspect all traffic flows to API Microservices via API Gateways |
7. Mutual trust assurance levels must be determinable. | Apply mutual trust between API Gateway and API Microservices |
8. Authentication, authorization, and accountability must interoperate/exchange outside of your locus/area of control. | Apply authentication and authorization for both internal, partner and public clients. |
9. Access to data are controlled by security attributes of the data itself. | Maintain security attributes for API Microservices |
10. Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges. | Apply access restrictions to API Microservice for environments hosting sensitive or high value data |
11. By default, data must be appropriately secured when stored, in transit, and in use. | Apply uniform security policies within API Gateway for inbound, outbound and mediated traffic flows for API Microservices |
Solution Overview
The enforcement of segmentation for API Microservices is reliant on API Gateway services. Microservices establish mutual trust with API Gateway to allow delegation for enforcement of security controls. This includes maintaining segregation for flows between environments and different flows
The consumption of APIs exposed by microservice can be summarised into three main interactions. These interactions are separated on inbound, outbound and internal flows across trust boundaries.
Flow Direction | Description |
---|---|
Inbound Flows | These flows represent various clients consuming APIs exposed by microservices, using the API Gateway as a broker. |
Outbound Flows | These flows represent microservices consuming other internal or external services. |
Internal Flows | These flows represent microservices consuming APIs exposed by microservices, using the API Gateway as a broker. |
These interactions have different implications to how security controls are applied. The following further describes the security model for each flow.
Inbound Flows
The following diagram represents inbound flows originating from different client types to API Microservices.

Regardless of location (internal, public or partner) all inbound flows from various client types are strongly authenticated. The below summary list of client types are expected to authenticate using the following industry standards.
Client Type | Example | Recommended methods [1] |
---|---|---|
Browser | Internet browser executing Single Page Application (SPA) on a client machine. e.g. Chrome or Firefox | OpenID Connect Authorisation Code Type OR OpenID Connect Implicit Grant Type |
Application Client | Stand-alone application that runs on a client machine, i.e.: .NET or Java application running on a workstation. | OpenID Connect Authorisation Code Type. |
Native | Stand-alone application that runs on a mobile device, e.g. iOS or Android. | OpenID Connect Authorisation Code Type. |
System to System | System application runs on a server machine to consume APIs e.g. Partner B2B transactions | OAuth2 Client Credentials grant over TLS-MA. |
Server-Side Application | Traditional frontend web application that runs on a server machine to consume backend APIs. | N/A – Specific authentication method implemented on frontend presentation server not in scope for this pattern. |
[1] Note: The following is a summary based on industry best practise at the time of writing. Please also refer to latest documentation from OpenID Connect and OAuth standards regarding best practice for authentication and authorisation for specific implementations.
Using Access Tokens to Establish Trust Domains
Internal and external trust domains can be established through different types of access tokens. Once the API Gateway validates an access tokens, it exchanges the ‘external’ token with a separately issued ‘internal’ access token.
The separation of ‘external’ and ‘internal’ access tokens is not prescribed under OpenID Connect or OAuth2 standards, but is a design choice for establishing boundaries between external client/provider entities and internally protected resources.
A summary for the characteristics of ‘external’ versus ‘internal’ access tokens is as follows
External | Internal |
---|---|
Used for resource level (coarse grained) authentication and authorisation to API Gateway. | Exchanged and passed onto API Microservices for fine grained authorisation. |
Used across different trust domains such as public or partner sites | Remain within internal trusted domains and zones. |
Tokens are generated, issued and signed by Security Token Service. | Tokens are generated, issued and signed by Security Token Service. |
Lightweight and don't contain any contextual information for internal system or services. | Encompass same claims as corresponding external token, but are populated with more contextual information for roles and entitlements. |
The use of access tokens is applied within the following model
Additional Notes
- API Gateway operates as enforcement point for authorisation and access.
- Clients are strongly authenticated, regardless of location (i.e. Internal, Partner or Public)
- Clients are issued ‘external’ access tokens for interactions with API Gateway.
- Once validated, API Gateway replaces ‘external’ access tokens with ‘internal’ access tokens (via exchange with Secure Token Service).
- The Secure Token Service is responsible for maintaining the mapping between external and internal tokens, and maintain associated token lifecycles.
Outbound Flows
The following diagram represents outbound flows originating from API Microservice to a service provider.

Additional Notes
- Any traffic to external public or partner locations uses content inspection for protection against data exfiltration.
- Some controls may look to whitelist connectivity to partners where controls are not applicable (e.g. web content filtering)
- API Microservice traffic to backend internal provider services is not required to traverse the API Gateway (as enforcement and access control are maintained within those assets).
- Connectivity may traverse the API Gateway is mediation is required (e.g. Converting RESTful based JSON formatted traffic into SOAP based XML traffic).
Internal Flows
The following diagram represents internal flows originating from API Microservice to another API Microservice.

Additional Notes
- API to API Microservice communications occurs via API Gateway as intermediary proxy.
- The API Gateway is responsible for maintaining boundaries between API based microservices.
Traffic Flow Traversal Across Environments
Further to above, it’s important to also look at the trust boundaries that exist between different environments. Within this model, we look to categorise environments into the following security attributes.
- Network Security Zoning: Placement of assets within network security environment (see Locations section).
- Security Configuration Hardening: Tightening of asset configurations to meet security baselines (i.e. loosely controlled or tightly restricted)
- Information Security Classification: Access within environment to sensitive data (i.e. sanitised data versus live data).
The security criteria for the environments are evaluated on the following attributes.
Attribute | Development | Testing | Staging | Production |
---|---|---|---|---|
Network Security Zoning | Application Development Environment | Application Non-Production Environment | Application Non-Production Environment | Application Production Environment |
Security Configuration Hardening | Loosely Controlled | Tightly Restricted | Tightly Restricted | Tightly Restricted |
Information Security Classification | Sanitised Data | Sanitised Data | Sanitised Data | Live Data |
The following provides an overlay to the previous interactions across different environments whereby
- Permitted: General access provided for endpoints and associated APIs
- Restricted: Limited access provided for specific endpoints or approved APIs
- Blocked: No access provided by default. Access provided by exception
Inbound Restrictions
The main principles to restrictions within inbound flows is access from clients in untrusted location accessing environments with loosely controls security configuration hardening.
Development | Testing | Staging | Production | |
---|---|---|---|---|
Internal | Permitted | Permitted | Permitted | Permitted |
Partner | Blocked | Restricted | Permitted | Permitted |
Public | Blocked | Blocked | Restricted | Permitted |
Microservices within Development and Testing environments that would not yet be security tested or hardened are not exposed to external partner or public domains.
Outbound Restrictions
The main principles to restrictions within outbound flows is untrusted content accessed from environments with loosely controls security configuration hardening.
Internal | Partner | Public | |
---|---|---|---|
Development | Permitted | Restricted | Blocked |
Testing | Permitted | Restricted | Restricted |
Staging | Permitted | Permitted | Restricted |
Production | Permitted | Permitted | Permitted |
Development environments are blocked from directly accessing resources or content within external public domains. Content is cached and sync’d into internal private repository or internal services where possible.
Internal Restrictions
The main principles to restrictions within internal flows is data sensitivity associated to live data within Production environment.
Development | Testing | Staging | Production | |
---|---|---|---|---|
Development | Permitted | Permitted | Restricted | Restricted |
Testing | Permitted | Permitted | Permitted | Restricted |
Staging | Permitted | Permitted | Permitted | Restricted |
Production | Permitted | Permitted | Permitted | Permitted |
Development environments are restricted (but not blocked) from access to Production environments.
- Any production environments hosting microservices that allows access to sensitive data are blocked from Development.
- The exception however maybe for Production environments permitting access to underlying core infrastructure functions (e.g. Certificate Mgmt, Secrets Mgmt) are permitted.
Design Principles
The following design principles are applied for this pattern, based on the requirements.
- API Gateway operates as enforcement point for inbound, outbound and internal flows.
- API Gateway enforces segregation for flows between Development, Non-Production and Production environments.
- Apply ‘shift-left’ methodology for security controls in Non-Production and Pre-Production environments.
- Maintain segmentation between API Microservices using controls within both network security and identity and access management.
- API Microservices are deployed as immutable services within environments.
Actors
List the actors involved in this pattern.
Actor Type | Actor Description |
---|---|
Internal API consumers | Internal staff consuming Rest APIs for microservice applications, typically via native or browser client types |
Public API consumers (B2C) | External public consumer or anonymous access to Rest APIs for microservice applications |
Partner API consumers (B2B) | External partners or suppler access to Rest APIs for microservice applications |
API Developers | Application developers for build, compile and deploy microservice applications. |
System Administrators | Manage and operate API Gateway and API Lifecycle tooling. |
Locations
This pattern is applied to any locations for assets being utilised
Location | Location Description |
---|---|
Application Development Environment | Development or sandpit environment for API development |
Application Non-Production Environment | Non-production and Pre-production environment for multiple test stage gates for API testing and deployed via CI/CD pipeline |
Application Production Environment | Production environment for deploying and publishing APIs that have passed all testing stage gates required as part of CI/CD pipeline. |
Sequencing
The pattern is designed within the following sequences
Stage gate | Description |
---|---|
Build time | Register and develop stage gate for microservices within API lifecycle |
Deploy time | Compile and deploy stage-gate for microservices within API lifecycle |
Run time | Execution stage gate for microservices within API lifecycle |
Mapping Threats to Controls
The following provides a mapping of security threats to affected assets and the security control objectives required to mitigate them (further detailed in subsequent security pattern logical designs).
Threat Event | Affects Assets | Security Controls Objectives |
---|---|---|
TE-14: Inadequate workflows or processes leading to flaws in deployment | Microservice
API Lifecycle Manager |
CM-02: Baseline Configuration
IA-02: Identification and Authentication (organizational Users) IA-08: Identification and Authentication (non-organizational Users) RA-02: Security Categorization SC-02: Separation of System and User Functionality SC-08: Transmission Confidentiality and Integrity SC-11: Trusted Path SC-13: Cryptographic Protection SC-32: System Partitioning SI-02: Flaw Remediation |
TE-24: Identity theft or impersonation | Microservice
API Gateway |
AC-03: Access Enforcement
AC-04: Information Flow Enforcement AC-14: Permitted Actions Without Identification or Authentication AC-24: Access Control Decisions AU-02: Event Logging IA-09: Service Identification and Authentication SC-08: Transmission Confidentiality and Integrity SC-13: Cryptographic Protection SC-17: Public Key Infrastructure Certificates SC-23: Session Authenticity SC-26: Decoys |
TE-26: Abuse of resources through misconfiguration | Microservice
API Gateway |
AU-02: Event Logging
CM-02: Baseline Configuration CM-06: Configuration Settings RA-05: Vulnerability Monitoring and Scanning SC-11: Trusted Path |
TE-29: Web application attacks or code injection attack | Microservice | AU-02: Event Logging
RA-02: Security Categorization SI-09: Information Input Restrictions SI-11: Error Handling |
TE-40: Distributed Denial of service (DDoS) across application services | API Gateway | SC-05: Denial of Service Protection
SC-06: Resource Availability SC-14: Public Access Protections SC-36: Distributed Processing and Storage |
Security Pattern
Pattern View: API Microservices

Control list: Microservice
Control Objective | Control Description |
---|---|
AC-03: Access Enforcement | Access to APIs are authenticated using access tokens, i.e. JSON Web Tokens. |
AC-04: Information Flow Enforcement | Enforce access to API microservices via API Gateway by validating requests using cryptographic checks i.e. API request is signed by API Gateway. |
AC-14: Permitted Actions Without Identification or Authentication | Do not permit anonymous access directly to API’s. API’s always authenticate and validate requests to ensure these have traversed API Gateway. |
AC-24: Access Control Decisions | Resource level access control is validated within API Gateway. Fine Grained access control is validated within Microservice. |
AU-02: Event Logging | Microservices that generate security event records are aggregated into a centralised security event monitoring (SIEM). |
CM-02: Baseline Configuration | Maintain hardened security configuration for exposing APIs from Microservice. |
IA-09: Service Identification and Authentication | Ensure access tokens or credentials (API Keys) are issued from trusted identity providers. |
RA-02: Security Categorization | Maintain metadata for each Microservice on security categorisation and approved exposure across different endpoints (Internal, Partner, Public) |
RA-05: Vulnerability Monitoring and Scanning | Regularly apply vulnerability scanning across API interfaces to identify potential weakness or flaws in TLS or HTTP configuration. |
SC-08: Transmission Confidentiality and Integrity | Enforce usage of secure protocols for data transmission. |
SC-11: Trusted Path | Consumption of APIs is only initiated from API Gateway when the requests are properly signed. |
SC-13: Cryptographic Protection | API clients and Microservices implement message or field-level encryption if end-to-end encryption is required. |
SC-23: Session Authenticity | Validate authenticity of access token (expiry and signature) for all API requests. |
SC-26: Decoys | Honeypot microservices are deployed for detection of malicious activity or use of compromised credentials. |
SC-32: System Partitioning | Microservice deployments are partitioned and segregated between environments (Production, Non-Production and Development) |
SI-02: Flaw Remediation | Security testing is applied for microservices within Application Non-Production Environment. This may include Static Source Code Analysis, Software Component Analysis, Malware Scan or Dynamic application security testing. |
SI-09: Information Input Restrictions | Apply fine-grained validation rules to inspect API messages, i.e. Business rules validation. |
SI-11: Error Handling | Microservice manage errors and report sanitised failure information. |
Control list: API Gateway
Control Objective | Control Description |
---|---|
AC-03: Access Enforcement | Client access to APIs is authenticated and authorised using industry standards (OpenID Connect / OAuth2). Once authenticated, API Gateway exchanges ‘external’ token for ‘internal’ token (issued by Secure Token Service) before forwarding messages to API Microservices or downstream systems. |
AC-04: Information Flow Enforcement | Ensure API requests are via API Gateway. Apply digitally signature in request header for API Requests being forwarded to downstream APIs. |
AC-14: Permitted Actions Without Identification or Authentication | Anonymous public APIs do not require authentication or authorisation. Exposure of these APIs are separated from authenticated endpoints. |
AC-24: Access Control Decisions | Resource level access controls are validated within API Gateway, based on ‘external’ access tokens. Fine Grained access controls are validated within API Microservice, based on ‘internal’ access tokens. |
AU-02: Event Logging | Endpoints exposed via API Gateways generate security authentication and authorisation audit records for all API transactions. |
CM-02: Baseline Configuration | Maintain hardened security configuration for exposing APIs within endpoints. |
CM-06: Configuration Settings | Maintain separate configuration settings for different endpoints exposed on API Gateway (Internal, Public, Partner) |
IA-09: Service Identification and Authentication | Challenge clients for access credentials from trusted whitelist of identity providers. |
RA-05: Vulnerability Monitoring and Scanning | Regularly apply vulnerability scanning across endpoints exposed by API Gateways to identify potential weakness or flaws in TLS or HTTP configuration. |
SC-05: Denial of Service Protection | Denial of Service and Distributed Denial of Service Protection is implemented for protection against network and HTTP protocol abuse. |
SC-06: Resource Availability | Apply performance counters, thresholds and rate limitation to protect availability of APIs and back-end resources. |
SC-08: Transmission Confidentiality and Integrity | Enforce usage of secure protocols for data transmission. |
SC-11: Trusted Path | Expose separate endpoints to API consumers originating from different trust domains (e.g. Internal, Partner, Public). Apply API firewall rules to control access to APIs. |
SC-13: Cryptographic Protection | Ensure support for API requests that implement message or field level encryption. |
SC-14: Public Access Protections | Enforce web application firewall rules to inspect API messages (e.g. CWE/SANS Top 25 or OWASP Top 10). Ensure API messages containing binary data or used for file transfer are scanned against malicious payloads or malware. |
SC-17: Public Key Infrastructure Certificates | Endpoints exposed to external public or partner trust domains utilise trusted 3rd party Certificate Authority. Endpoints exposed to internal domain may use internal private Certificate Authority. |
SC-26: Decoys | Expose APIs from honeypot microservices to detect malicious behaviour or attempts to use credentials stolen or compromised. |
SC-36: Distributed Processing and Storage | Support backend scaling of immutable microservices as additional mitigation to Denial of Service attacks. |
Control list: API Lifecycle
Control Objective | Control Description |
---|---|
CM-02: Baseline Configuration | Ensure standard deployment of microservices to each environment using approved CI/CD orchestration tooling. |
IA-02: Identification and Authentication (organizational Users) | Uniquely identify all developers accessing API Developer Portals or other lifecycle tooling. Remove any shared accounts. |
IA-08: Identification and Authentication (non-organizational Users) | Uniquely identify all developers from external or partner organisations accessing API developer portals or other lifecycle tooling. |
RA-02: Security Categorization | API Developer portals are able to query microservice metadata for approved endpoints and security categorisations. |
SC-02: Separation of System and User Functionality | Limit access to system functions and portals for API lifecycle management versus access provided to API developer portals. |
SC-08: Transmission Confidentiality and Integrity | Ensure access to API lifecycle management tooling and API developer portal occurs across encrypted channels. |
SC-11: Trusted Path | Ensure API registration and deployments to environments occur through appropriate CI/CD tooling. |
SC-13: Cryptographic Protection | Sensitive authentication data such as API keys or credentials managed under secrets management. Registration for access to APIs are also exchange sensitive authentication data via secrets management (rather than exposing via developer portals). |
SI-02: Flaw Remediation | Any microservice detected with security defects identifying in test environments are not permitted onto further deployment phases. |
Appendix A – References
Please see below links to external sites for further reading
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf
- https://microservices.io/patterns/microservices.html
- http://bogdan.bynapse.com/azure/azure-api-management-security-concerns/
- https://stackoverflow.com/questions/34754012/securing-registration-restful-api-against-registering-many-users
- https://www.owasp.org/index.php/REST_Security_Cheat_Sheet