Security Pattern – API based Microservices

Overview

The following security pattern describes the security architecture for enabling applications exposing Restful API’s.

This pattern will focus on applications deployed as a microservices architecture. Microservices are 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 HTTPS.

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 with establishing a microservices architecture and the typical methods of deployment.

Typically Challenges

Tracking, managing and enforcing access controls for APIs that expose data held in internal backend databases, repositories and data storage.
The decoupled nature of microservice applications increases the risk of inadvertently exposing internal functionality and components. Threats can target weaknesses within those microservices by directly communicating across exposed API interfaces on the network.
API-based microservices typically form a broader ecosystem of interactions for multiple consumers. API endpoints exposed may be consumed by a blend of internal, public or partner API clients with different security postures. These models also break down traditional perimeter-based network segregation (DMZ) for securing web application services.
Microservices architecture allows for faster and more agile development cycles, but subsequently can allow for broader logic flaws to occur due to the additional complexity of managing distributed systems.

Scope

The scope of this document is to address the security threats that relate to

ID	Description	Example
01	Deployment and execution of restful API-based Service	Node.js microservice application
02	Consumption of API Service 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, XML-structured communications or web sockets.	These services require additional considerations to threat modelling and web app security.
02	Application development environments and tooling	Covered under broader security patterns such as Source Code Management and CI/CD Pipelines.

Dependencies

ID	Description	Impact from dependency not met
01	The security control objectives using in this pattern have been referenced from NIST SP 800-53 Rev. 5 - Security and Privacy Controls for Information Systems and Organizations

Assumptions

ID	Description	Impact if assumption is false
01	Design decisions assume API Service conforms to standard practices in Restful API design.	Non-conformance to best practise for Restful API will require separate considerations to controls.
02	Design decisions assume API Service is deployed as an autonomous web application (such as a microservice).	Different threat modelling is required for other platform hosting and orchestration services.

Assets at Risk

The following section provides a list of assets affected by the problem statement:

Asset Title	Asset Description
API Service	Represents a web application that exposes one or more APIs (Application Programming Interface) that provide a set of operations for consuming, processing or transforming data.
API Gateway	Primary function of the API gateway is to route inbound API requests to the correct API Service. It can be used as a front-door and enforcement point when exposing API to various consumers (such as external, partners and or internal developers).
API Lifecycle Manager	Allow developers to register, publish, promote and manage API Services exposed via the API Gateway. This includes developer portals for searching and discovering published API’s associated with specific API Service. This also typically integrates into CI/CD tooling used for deployments.

The following assets are also referenced within the pattern but not in scope

Identity Provider – Referenced in this pattern to describe services used to authenticate clients.
Secure Token Service – Referenced in this pattern to describe services used for issuing access tokens for authentication and authorisation.
CI/CD tooling – Required to deploy API Service into target hosting platform and 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 web applications have increased exposure to flaws in workflows and processes due to their distributed nature. Security controls implemented for upstream components could be skipped or bypassed by directly accessing downstream components (confused deputy scenario). A microservice may be restricted from accessing sensitive processes, data or information but can still gain access by forwarding requests via other intermediary or downstream microservices with approved access.
TE-24: Identity theft or impersonation	API Services rely on passing identity and context within each request to communicate with other API Service or backend data services. 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	Web applications exposing API services are vulnerable to application flaws, misconfiguration for backend data flows or misconfiguration of TLS settings. The API Service could be compromised if these flaws are exploited or data is unintentionally exposure
TE-29: Web application attacks or code injection attack	Web applications exposing API services remain vulnerable to web application attacks and susceptible to command injection, encoding or serialisation 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 web 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.

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 API Services for connectivity between security 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 API Services
3. Assume context at your peril.	Controls defined in this security pattern is 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 Services
5. All devices must be capable of maintaining their security policy on an un-trusted network.	API Services 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 Services via API Gateways
7. Mutual trust assurance levels must be determinable.	Apply mutual trust between API Gateway and API Services
8. Authentication, authorisation, and accountability must interoperate/exchange outside your locus/area of control.	Apply authentication and authorisation for internal, partner and public clients.
9. Access to data is controlled by security attributes of the data itself.	Maintain security attributes for API Services
10. Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges.	Apply access restrictions to API Service 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 Services

Solution Overview

The enforcement of segmentation for API Services is reliant on API Gateway. API Services establish mutual trust with API Gateway to allow delegation to enforce security controls. This includes maintaining segregation for flows between environments and different flows.

The consumption of API Services can be summarised into three main interactions. These interactions are separated into inbound, outbound and internal flows across trust boundaries.

Flow Direction	Description
Inbound Flows	These flows represent various clients consuming API Services using the API Gateway as a broker.
Outbound Flows	These flows represent API Service consuming other internal or external services.
Internal Flows	These flows represent API Service consuming other API Services exposed using the API Gateway as a broker.

These interactions have different implications for how security controls are applied. The following further describes the security model for each flow.

Inbound Flows

The following diagram represents inbound flows from different client types to API Services.

Regardless of location (internal, public or partner) all inbound flows from various client types are strongly authenticated. The below summary list of client types is 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 practices at the time of writing. Please also refer to the latest documentation from OpenID Connect and OAuth standards regarding best practices for authentication and authorisation for specific implementations.

Outbound Flows

The following diagram represents outbound flows from API Service 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 allowlist connectivity to partners where controls are not applicable (e.g. web content filtering)
API Service 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 if 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 Service to another API Service.

Additional Notes

API Service to API Service communications occurs via API Gateway as an intermediary proxy.
The API Gateway is responsible for maintaining boundaries between API Services.

Design Principles

The following design principles are applied for this pattern based on the requirements.

API Gateway is an enforcement point for inbound, outbound and internal flows.
API Gateway enforces flow segregation 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 Services using controls within both network security and identity and access management.
API Services 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 API Services typically via native or browser client types
Public API consumers (B2C)	External public consumer or anonymous access to API Services
Partner API consumers (B2B)	External partners or supplier access to API Services
API Developers	Application developers for building, compiling and deploying API Services.
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 Test Environment	Non-production and pre-production environment for API testing and release
Application Production Environment	Production environment for deploying and publishing APIs that have passed all testing stage gates

Sequencing

The pattern is designed within the following sequences.

Stage gate	Description
Build time	Development and Build stage gate for API Services
Deploy time	Deploy and release stage gates for API Services
Run time	Execution stage gate for API Services

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	API Service 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	API Service 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	API Service 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	API Service	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 Service

Control list: API Service

Control Objective	Control Description
AC-03: Access Enforcement	Access to APIs is authenticated using access tokens, i.e. JSON Web Tokens.
AC-04: Information Flow Enforcement	Enforce access to API Service via API Gateway by validating requests
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 API Service.
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 API Service.
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 API Service 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 weaknesses 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 exposed APIs is only initiated via the API Gateway.
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 the authenticity of the access token (expiry and signature) for all API requests.
SC-26: Decoys	Honeypot API Services are deployed to detect malicious activity or the use of compromised credentials.
SC-32: System Partitioning	API Service deployments are partitioned and segregated between environments (Production, Non-Production and Development)
SI-02: Flaw Remediation	Security testing is applied for API Services within Application Non-Production Environment. This may include Static Source Code Analysis, Software Component Analysis 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).
AC-04: Information Flow Enforcement	Ensure API requests to backend services may only occur via the API Gateway.
AC-14: Permitted Actions Without Identification or Authentication	Anonymous public APIs do not require authentication or authorisation. Exposure of these APIs is separated from authenticated endpoints.
AC-24: Access Control Decisions	Resource level access controls are validated within API Gateway, based on access tokens. Fine-Grained access controls are validated within API Service based on claims held in the access token or lookup from a trusted identity provider.
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 a trusted allowlist of identity providers.
RA-05: Vulnerability Monitoring and Scanning	Regularly apply vulnerability scanning across endpoints exposed by API Gateways to identify potential weaknesses or flaws in TLS or HTTP configuration.
SC-05: Denial of Service Protection	Denial of Service and Distributed Denial of Service Protection are implemented for protection against network and HTTP protocol abuse.
SC-06: Resource Availability	Apply performance counters, thresholds and rate limitations to protect the availability of APIs and backend 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 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 the external public or partner trust domains utilise trusted 3^rd party Certificate Authority. Endpoints exposed to the 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 an additional mitigation to Denial of Service attacks.

Control list: API Lifecycle

Control Objective	Control Description
CM-02: Baseline Configuration	Ensure standard deployment of API Service to each environment using approved orchestration and automation 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 can query API Service 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.
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 (rather than exposing them to developers in clear text).
SI-02: Flaw Remediation	Any API Service detected with security defects identified in test environments cannot deploy to production.

Appendix A – References

Please see below links to external sites for further reading

Appendix B - Disclosure Notice

This document is published as independent research only and is without warrenty. It does not represent any publication from National Institute of Standards and Technology (NIST) or other associated US government entities.