Security Pattern – API Services

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

Out of Scope 

Dependencies

Assumptions

Assets at Risk

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

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.

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.

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.

[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.

1. API Gateway is an enforcement point for inbound, outbound and internal flows.
2. API Gateway enforces flow segregation between Development, Non-Production and Production environments.
3. Apply ‘shift-left’ methodology for security controls in Non-Production and Pre-Production environments.
4. Maintain segmentation between API Services using controls within both network security and identity and access management.
5. API Services are deployed as immutable services within environments.

Actors

List the actors involved in this pattern.

Locations

This pattern is applied to any locations for assets being utilised.

Sequencing

The pattern is designed within the following sequences.

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).  

Security Pattern

Pattern View: API Services

Control list: API Service

Control list:  API Gateway

Control list:  API Lifecycle

Appendix A – References

Please see below links to external sites for further reading

• https://www.cyber.gov.au/acsc/view-all-content/ism
• https://microservices.io/patterns/microservices.html
• https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

Appendix B - Disclosure Notice

This document is published as independent research only and is without warrenty. It does not represent any publication from Australian Cyber Security Centre (ACSC), the Australian Signals Directorate (ASD) or other associated Australian government entities.