From the attacker’s perspective, one of the most time-consuming parts of planning a network attack is the reconnaissance required to find potential network attack vectors. Since application programming interfaces (APIs) must be exposed to the public, the amount of time the attacker spends finding attack vectors into the API’s network is greatly reduced, making APIs an easier target for potential breaches. The use of APIs can increase the attack surface of a network, and, if not designed correctly, they can result in significant security issues.

The rise in implementing microservice architectures in place of monolithic software architectures now makes APIs more common than ever. To facilitate implementation of a zero trust strategy in a network, this pervasiveness requires a focused effort to identify API-specific vulnerabilities. In this blog post, which is excerpted from a recently published paper, I present three top API security risks along with recommendations for mitigating them.

Before delving into the top API risks, it is important to understand how they are built.

API Endpoints

An API provides a programmed entry point into an application. If the application is designed to interact with other applications, then an API is put into place to enable that interaction. Within each API, there are multiple application connection points called endpoints.

Each endpoint serves a different purpose, but they are all connected to the same application. The following are a few examples of how an API endpoint might be used:

• logins (The necessary inputs for that endpoint are a username and password.)
• password resets (The required input might only be an email, so a password reset link can be sent.)
• administrators changing application settings (The required input for access might be a username and password.)
• enabling interaction between microservices (The required inputs might be user IDs or other user information, product or order information, or whole data structure objects.)

Microservice Architectures

Over the past decade, microservice architectures have become more popular for newly designed systems compared to the previously dominant monolithic architectures.

Microservice architectures focus on creating many small, loosely coupled micro applications to produce a larger application. For example, a company might have a product descriptions microservice, a payment processing microservice, and a login microservice. Each of these microservices can be executed and deployed independently of the others. Each microservice has its own API and endpoints for client-to-microservice or microservice-to-microservice interactions.

The distributed, loosely coupled design of these microservice architectures allow them to have greater scalability, flexibility, and continuous deployments when compared to monolithic architectures. According to National Institute of Standards and Technology (NIST) special publication (SP) 800-204, “Microservices generally communicate with each other using Application Programming Interfaces (APIs), which require several core features to support complex interactions between a substantial number of components.” There are often support structures that also help API ecosystems by offering solutions, such as API gateways and service meshes. While this blog post and the paper from which this was excerpted only discuss APIs, the use and configuration of supporting structures (e.g., identity access management [IAM] servers, API gateways, service meshes) are also important to overall API security.

The remainder of this post will outline three API security risks (third-party software integrations, cascading failures, and increased network attack surface) and provide recommendations for mitigating them.

Third-Party Software Integrations

Description. Often when creating new software, including APIs, existing software packages and libraries are used to make the design and implementation process faster and easier. However, integrating third-party software means introducing all the possible vulnerabilities of that software into the new API that is being built. Even the highest quality code can have up to 600 defects per million lines of code while average quality code has around 6,000 defects per million lines of code. Many of these defects can result in vulnerabilities.

Example. Log4J is a critical vulnerability in the Java-based logging library that was discovered in 2022. It allows remote code execution and the complete takeover of the victim’s machine. Any system that has Log4j integrated into its software is vulnerable to attack until the vulnerability is patched.

Recommendations. The following recommendations apply to this risk.

1. Perform risk assessments on all third-party software that might be used in a new API to prevent introducing additional API vulnerabilities.
2. Stay informed about the latest vulnerabilities in all third-party software that is integrated into currently deployed APIs.
3. Use automated vulnerability scanners on third-party software if possible.
4. Consider implementing a software bill of materials framework to help secure the supply chain and mitigate the risks of using third-party software.

Cascading Failures

Description. As previously mentioned, APIs are closely tied to microservices, which are small applications designed to perform a specific function. These microservices should be loosely coupled with high cohesion, which means that each of them works independently or mostly independently from other microservices. Designing the microservice architecture with independent applications prevents the entire API ecosystem from shutting down if a single microservice becomes broken or nonfunctional.

Designing the microservice architecture with loosely coupled components reduces the risk of API shut downs if a single microservice becomes broken or nonfunctional. When one microservice’s inoperability causes issues with other microservices, it is called cascading failures, and it should be avoided to reduce the risk of DoS attacks on the API.

Example. As illustrated in figure 1 below, assume a sales information API must call a product description API to complete a client request it receives from the API gateway, but also assume that the product description API goes down. In this case, the sales information microservice can no longer complete its request. As a result, the sales information application cannot be used because another application it relies on is down.

Recommendations. The following recommendations apply to this risk.

1. Design APIs with the goal of loose coupling in mind, including deployment coupling, temporal coupling, and implementational coupling.
2. Create API documentation that clearly shows which APIs are coupled and the communication flow that happens between coupled microservices. This documentation will be useful for testing and troubleshooting if there are issues with the API after deployment.
3. Conduct unit testing, integration testing, and end-to-end testing to confirm the correct functionality of the microservice architecture according to the documented design.
4. Strive to prevent single points of failure in the API network by adding redundancy measures in authentication and authorization points and other network structures.

Increased Network Attack Surface

Description. Microservice architectures that heavily use APIs have many structural differences when compared to monolithic architectures. Those differences can often increase the overall network attack surface. Many non-microservice architectures have a web server in a demilitarized zone (DMZ) with a backend service one layer behind it that contains the database the API is accessing one layer behind that. This structure provides more defense in depth compared to microservices that can collapse this layered approach, which leads to more exposure.

Monolithic API architectures expose fewer IP-addressable remote procedure calls compared to microservice architectures. The result is that these microservice architectures often have a larger attack surface as noted here. There are also many support structures, like the service discovery mechanism, needed to create a secure microservice system that creates more avenues for potential compromise if they are tampered with. Microservice architectures are generally more complex than monolithic architectures, which increases the likelihood of missed checks and misconfigurations that lead to vulnerabilities.

Example. Assume a microservice architecture currently has 10 API endpoints supported by one API gateway with a transactions per second (TPS) rate limit of 100 per second. If 10 more API endpoints are added with the same TPS rate limit, that means the same number of clients as before can now produce twice as many transactions in the same amount of time among the APIs. This could lead to delays in the API gateway processing the increased number of transactions, resulting in decreased customer service.

Recommendations. The following recommendations apply to this risk.

1. Carefully plan API versioning and deployments. Be strategic about adding new APIs so the maintenance and inventory of the existing APIs do not become overwhelming.
2. Add redundancy measures to prevent overload from API use in support structures, such as the API gateway and authentication servers.
3. Maintain a thorough inventory of all APIs, preferably through auto-generated documentation for uniformity and searchability.
4. Configure thorough logging and monitoring efforts for all API activity, including logging all authentication and input failures.

Future Work: API Best Practices

APIs are increasingly common, and they are often designed and implemented in a way that creates security risks. This blog post, and the report from which it was excerpted, summarized three risks associated with APIs and provided recommendations about fixing or reducing their impact. Some of the most common recommendations include the following:

• having a standard API documentation process
• using automated testing throughout the development process
• ensuring the identity and access management system is secure

Future work could extend the findings in this report to (1) explore integrating zero trust measures into the design of APIs and the development process and (2) create a set of rules and recommendations for API best practices.