TNS
VOXPOP
Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
0%
No: TypeScript remains the best language for structuring large enterprise applications.
0%
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
0%
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
0%
I don’t know and I don’t care.
0%
API Management / Security

5 Tips for Native Developers to Optimize API Security

Aug 1st, 2022 10:00am by
Featued image for: 5 Tips for Native Developers to Optimize API Security
Feature image via Pixabay.

Pratik Roychowdhury
Pratik currently leads VMware's API strategy. He joins VMware through the acquisition of Mesh7 (a.k.a. Kavach), a cloud native API security company, which he founded. He brings over two decades of experience in applications, APIs, networking and security. Previously, he was head of product management at Juniper Networks' Cloud Software (Contrail) business unit. Prior to that, he was head of products at MediaMelon, an online video software company. He has MBA from Ross School of Business at University of Michigan, Ann Arbor and a B.S. in electrical engineering from the Indian Institute of Technology, Kharagpur, India.

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.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.