Understanding API security: Best practices and opportunities for improvement

Forrester dubbed API Insecurity "the lurking threat in your software." Understanding API security-specific risks is key to protecting your API. New ways of thinking about API security are emerging.

API security: The challenges and latest developments

Using external services through APIs is routinely done to speed up development cycles in today’s microservices architecture. Unfortunately, this potentially creates additional exposure for the application. When calling external services or data from an enterprise application, penetration vectors cloaked in these external sources might expose databases or the application back-end to attacks. 

What is API security?

API security is the process of securing the application against importing vulnerabilities from external services through REST calls, REST, OpenAPI, gRPC, graphQL, and ad-hoc interfaces. Regardless of the architecture used, Gartner identifies API security as a new attack surface potentially leading to data breaches. So, in this post, we will focus on API security across all platforms, and not on Kubernetes as we usually do.

What are the 6 main challenges to API security?

Tackling API security risks requires an understanding of what the specific security challenges they face are. Here are six OSWAP most critical challenges, listed in order of decreasing importance:

• Visibility: Visibility is key to all things security. During the development process there is a lack of visibility. Shadow and Zombie APIs are commonly hidden from SecOps sights and are left undiscovered leading to API abuse, which according to Gartner will be the most frequent attack vector by 2022.
• Broken Object Level Authorization: Level Access Control is susceptible to breaches through endpoints handling object identifiers exposed by APIs. Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions. This risk exposing sensitive data such as PII, user data, credentials, and more. Every function accessing a data source emanating from a user input requires object-level authorization checks.
• Broken User Authentication: Incorrect implementation of authentication mechanisms opens the door to attackers attempting to compromise authentication tokens or exploit implementation flaws to temporarily or permanently hijack users' identities. Failing to configure the ability to systematically identify the client/user puts the overall API security at risk.
• Excessive Data Exposure: Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. This is especially relevant when clients are mobile apps as mobile clients’ APIs are different from web clients’. For example:
  • Many different sessions come from similar IP addresses corresponding to carriers’ output gateways.
  • A single session can change IPs frequently and drop the connection when switching between cells/hotspots.
  • The client-side includes non-browser environments, lacking cookies, and with custom protocols and encodings, various sockets, etc.
  • The range of client devices is extensive, from cheap Android phones to the latest smartphone generation, complicating proof of work tasks and other CPU-memory-based tests.
• Lack of Resources & Rate Limiting: As APIs are typically fielding users and external program requests to perform required functions, an excessive number of concomitant requests influx might exceed the API computing resources. Failure to configure rate limiting and resource access might lead to the API’s reduced performance on high traffic days and makes them vulnerable to DDoS attacks. Even worse, it opens the door to brute force attacks attempting to identify authentication flaws.
• Broken Function Level Authorization: Unlike user-initiated interactions where one data field is presented at a time, APIs are often more complex and need to transmit more structured data in a single call. This necessitates building custom data encoding protocols because of the custom application business logic. Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.

Accessing external resources or services through third-party APIs generates a risk of exposing critical information through these external providers' APIs’ vulnerability. These might provide entry vectors for malicious actors to infiltrate the application, leading to potential information leaks or application service disruption.

The current approach to API security

Currently API security is rigid, with a one directional hierarchical flow that lets developers use whatever API is most convenient to them.. As feature development high velocity is a core requirement for developers, they tend to focus more on delivering fast than on dwelling on security aspects. To make matters worse, API qualifications are often unclear, further diminishing the odds that developers will take the time to fully understand the API security implications of the feature they are developing. 

So, API security is more of an afterthought, taken into account only when SecOps enters the picture and try to assess if the APIs used by the developer are high or low risk. This is a highly manual process, both time-consuming and prone to error. Hidden and/or zombie APIs are often missed and image libraries with vulnerabilities are overlooked. CISOs are responsible for all the applications in your environment. They need visibility, one of the pillars of API security, and this system does not offer it.

5 API security best practices

We will discuss further API security developments shortly, but in the interim implementing the recommended API security best practices below is a good starting point.

1. Vulnerability identification

API vulnerabilities are complex to spot as they might originate in application logic flaws, so it is critical to take into account the entire API’s lifecycle and identify the insecure parts. Vulnerabilities need to be identified both for internal and external APIs. 

Internal APIs connect an organization's disparate backend system to enable seamless communication for individual lines of business needing access to specific data silos. Identifying and closing vulnerabilities in internal APIs is key to preventing lateral escalation in case of a breach. 

External APIs are the interface between the application and external clients, providing services or data. As applications are increasingly assembled with these external services and data, and the quality and security of remote services and databases is oftentimes unknown, the organization’s customer data might be at risk when using a third-party service. Identifying vulnerabilities from third-party providers might be tricky, especially as telemetry API security evaluation is typically not available before runtime, complicating the identification of vulnerability from external services during the CI/CD cycle. With the absence of full control on vulnerability identification for external APIs, the additional methods listed below are especially critical.

2. Encrypt data

Use methods such as TLS (Transport Layer Security) to encrypt data and require signature from a privileged few authorized to decrypt and modify data. This is particularly crucial for PIDs.

3. Authenticate all communication

API keys provide both project identification and authorization. As such, they are useful to block anonymous traffic and to control and monitor calls to your API, but not to secure traffic to and from your API as they can easily be stolen. To avoid unwanted use of API keys, use secret keys with unique temporary access tokens. Maintain a strict credential discipline to prevent exposing secret/password both to client and server.

4. Secure both internal and external APIs

Segmentation is key to prevent lateral escalation. This requires creating a strict schema establishing what are the system’s permissible incoming data. All incoming data need to be validated before gaining entry, limiting the odds that they might be harmful.

5. Continuously monitor

Log all traffic information and monitor API traffic and consumption.

These API security best practices provide increased security, but existing methods are still inefficient in evaluating vulnerabilities inherited from third-party service providers in real-time and provide an automated response to changing third-party service provider risk factor.

New avenues to improve API security

Forrester's October 2020 report on API Insecurity identified the shift away from SOAP APIs to OpenAPI and gRPC, graphQL, and ad-hoc interfaces as one of the current API security exposure sources. 

Instead of access through two-way connection to SOAP APIs, REST APIs, OpenAPI,gRPC, graphQL, and ad-hoc interfaces are typically accessed through mobile apps or browsers. This opens applications to easy-to-obtain hacking tools and client-side inspection. The requirement for rapid development cycles makes it virtually impossible to eschew reliance on third-party providers. 

What is needed is an oracle that speaks to the risks enterprise applications run when interacting with such services. With an oracle capturing those risks in a “reputation score”, developers, SecOps (or a combination thereof), and CISOs can enable connectivity policies for interactions between the enterprise application and the third party service. The policies can reduce the exposure to API risks for enterprises using third party API services. 

To address API reputation scoring and the implications for enterprise applications and their security when using such services, a scoring mechanism for the API service reputation is necessary. This scoring mechanism needs to be able to be used in a DevSecOps environment when developing and hosting applications. Such a scoring system requires:

• Detecting and evaluating parameters such as:
• TLS used (if any),
• Types of certificates
• Host reputation - i.e., if listed as spreading malware, adware etc.
• Service operational location - useful to manage GDPR and other regulatory requirements
• Assigning a score based on information collected
• Continuously updating scores

A scoring system like the above would enable developers to evaluate the cost/risk-benefit of including a third-party API and adapting cybersecurity insurance costs to rise and fall in parallel to the third-party APIs scores. An integrated development system including scoring would also offer visibility to both SecOps and CISOs as to the APIs the developers are using and their risk levels. The security persona receives a list of dependencies with easy visibility into whether all of the used assets are high or low risk. It allows for compliance reports to be generated by a CISO quickly and easily. The CISO can then approach the customer with a list of vulnerabilities and a plan for a solution. There is continuous visibility and risk mitigation is simple by quarantining those API calls quickly and efficiently.

An integrated development system is the way forward. Best practices are invaluable guardrails, but unfortunately, mistakes happen during development so, even if all recommendations are applied, monitoring your application for runtime vulnerabilities still remains critical to ensure ongoing API security. 

Looking for an API security solution? Learn more about Panoptica, Cisco’s cloud application security solution.