5 Tips for Native Developers to Optimize API Security

In case you missed it, we’re living in the age of API insecurity. Gartner predicts that API breaches will become the leading attack vector in 2022. You don’t need to look far to read about how an API security flaw led to massive attacks against organizations like LinkedIn, Parler and Clubhouse. As APIs are becoming the de-facto standards for information exchange between parties and applications, attackers are compromising APIs not only to steal data from big-name organizations like Peloton and LinkedIn, but also as a vector for taking over cloud resources in order to perform malicious activities such as “cryptojacking” attacks, which can cost victims enormous financial resources.

That’s the bad news. The good news is that it’s possible to staunch the API attacks — and doing so doesn’t require developers to rethink their approach to security from the ground up. Instead, it involves deploying the right API security protections so that developers can build secure cloud native apps, without worrying about API security risks within those apps.

Specifically, here are the top API security defenses that cloud native developers should deploy when building and deploying software.

1. Distributed Authorization and Authentication

First, cloud native applications require distributed authorization and authentication controls for their APIs. A distributed API access control system is one that uses a granular architecture to grant access to individual resources on a per-service (or per-microservice) basis, instead of allowing access to all resources and services once a request is authenticated and authorized at the ingress of the application.

This is important because APIs are the keys to the kingdom in cloud native applications, so to speak. Without distributed authorization and authentication controls, you give anyone who can get through the front door access to your entire environment. But with distributed access controls in place, it becomes much harder for an attacker to escalate an initial API breach into a full-scale attack.

2. API Request and Response Handling

Second, developers need to know how their applications should deal with API requests, especially those that involve incorrect parameters. This is important because attackers could pass incorrect parameters in an API request to execute a buffer overflow breach, for example, or even crash the application.

On the response side — especially when responses generate an error — developers must know if an API response header or payload gives away information about backend systems, which attackers could leverage to find weak points in their environments or capitalize on known vulnerabilities, for instance.

The bottom line here is that developers need to know what their APIs are sending and receiving so that APIs don’t become a way for attackers to bring down the application or gain information they should not have access to.

3. Sensitive Data Handling

Although allowing attackers to access unauthorized data via APIs is problematic, it’s especially risky if that data is considered sensitive — which it is if it contains personally identifiable information (PII), protected health care information (PHI), payment card information (PCI) or other types of data that, if it falls into malicious hands, could expose the business to regulatory compliance violations or cause major reputational harm.

To mitigate these risks, developers need to be aware of what sensitive data their applications exchange via API calls. Examining traffic at the surface level isn’t enough because that doesn’t reveal what sensitive information is contained in the packets. Instead, developers must examine individual packets to parse and understand the protocol at play at the API level (such as REST/JSON, gRPC, Kafka or MySQL) and which types of sensitive data is being transmitted — as opposed to performing blind pattern matching based on network traffic.

This information plays a key role in helping to distinguish standard API requests from those that handle sensitive data and are therefore susceptible to data exfiltration, data sovereignty issues and/or compliance exposures.

4. API Egress Protection

Most attacks originate from external sources. It may seem natural, then, to focus on identifying and blocking malicious requests that flow into your application environment by examining only your ingress traffic.

That’s part of the equation for API security. However, it’s equally important to protect egress — meaning the traffic flowing out of your application — too. Why? Because egress is how sensitive data is exfiltrated from your environment. It could also allow malware to enter into your application as it talks to malicious third-party sites and/or bad actors who already have breached your application to communicate with their command-and-control sites. Examining egress provides a second line of defense against attacks that you might have failed to detect at the ingress, or that have infiltrated your environment through advanced persistent threats (APTs) and supply chain attacks.

Keep in mind, too, that egress traffic is typically multipoint (unlike ingress, which usually flows through only a handful of specific entry points, such as API gateway). To maximize their visibility into potential API risks, developers need to know which traffic is leaving their environment and which external endpoints it is traveling to.

5. Security Testing and Shifting Left

The more API security tests developers perform, and the earlier they perform them in the software development lifecycle, the better. That’s true not only because developers should strive to detect API security risks before they enter production environments, but also because problems typically require less effort and cost to fix when they are detected early.

For this reason, systematic, automated API security tests should be a core feature of every stage of the development and CI/CD process. As soon as you create the API specification, start validating, linting and performing static and dynamic security tests on it. Continue those tests as your API spec and code flow down the software delivery pipeline.

Conclusion: Toward Hands-Free API Security

The above is certainly not a comprehensive list of API security protections. We haven’t touched on other considerations, such as the importance of documenting all APIs (both internal and external ones) to keep track of where risks may lie or maintaining the ability to set distributed (i.e., per service) API rate control limits to make it harder for attackers to perform API DDoS fan-outs. But we have discussed what are arguably the most important API security defenses for developers to build into their software delivery pipelines and deployment environments today.

If building the API security protections described above sounds daunting, keep in mind that these defenses can be implemented without touching the application source code. Developers can instead rely on API security tools to enforce distributed access controls, inspect API requests and responses, drive security testing and much more — regardless of which type of application or API requests they are protecting.

In a world where API security risks are poised only to grow worse, having the ability to secure API requests easily, for any application, will become increasingly critical. Smart cloud native developers are getting ahead of the curve by establishing strong API security protections now before their organizations become the subject of the next API security breach headline.