How To Avoid Exposing Private Data By Securing APIs

In the digital economy our personal lives intertwine with data stored across cloud apps. We put a lot of trust into cloud app security to protect our personal data in exchange for convenience.

With millions of digital transactions performed daily, application programming interfaces (APIs) are the engines that power that convenience. Unseen to most users is a complex web of APIs that help exchange sensitive data including personally identifiable information (PII) and protected health information (PHI) .

When you use your health care app to access lab results, for example, APIs work behind the scene to obtain your PHI data sitting somewhere on a cloud database. This dance between private information and APIs applies as well to ecommerce transactions that allow purchases on smartphone apps that require a credit card number and home address.

This expands to countless ways that APIs are used to access our personal data every day.

The Security Problem With APIs

However, there is a problem in the way APIs are implemented: There is no standard way to develop APIs that can ensure a specific level of security. Every company’s software team will have a custom approach to creating APIs used to run cloud applications, integrate third-party partnerships, and enable smartphone apps.

Often in the race to develop new APIs, security vulnerabilities can be exposed that lead to the APIs being used in ways not originally intended. Cybercriminals can probe a company’s API gateway to hunt for irregularities in the way business logic has been written in the API code. If a cybercriminal discovers misconfigurations or a software vulnerability, a window of opportunity is opened to access sensitive information.

A poorly written API may allow for a BOLA (Broken Object Level Authorization) attack, where a cybercriminal exploits how an API handles object identifiers that can reveal sensitive data. An attacker can simply exchange the ID of a resource in an API call with an ID belonging to another user. In the absence of a proper authorization check, it enables the attacker to access the specified resource. For example, an attacker could substitute their own ID (mobile number or email address) from an Uber account with a victim’s ID, enabling the attacker to gain access to the account. Traditional security solutions are unable to see this attack underway and are unable to prevent it.

Considering Options for API Protection

Current security solutions that can be used to protect a company’s API infrastructure are varied and feature a widening degree of security protection.

Initially, the natural fallback for many organizations to secure their network was to rely on native API security capabilities that came with their API gateway, which can include rate-limiting and Access Control Lists (ACL) that prevent source IP ranges from accessing the gateway. These API gateways were part of API development deployed on software development cloud platforms such as MuleSoft, Apigee, and 3scale.

Web Application Firewalls

However, these security capabilities simply weren’t enough to protect against a new wave of attackers, and organizations started to redeploy their Web Application Firewall (WAF) technologies to protect API gateways. The thinking was that cybercriminals would simultaneously target web applications and API gateways looking for the most vulnerable entry points into an organization. The problem that security teams encountered was that security policies that worked well for web applications, such as those that protected against OWASP Top 10 attacks, didn’t always translate well when protecting an organization’s API gateway.

While WAF vendors responded with new variations of their existing WAF solutions to sell extra appliances,the door was still open for API-driven data breaches.

Anomaly Detection API Security

A number of API security startups emerged with a new approach: Machine learning (ML) tools that learn normal API behavior as accessed from API clients such as smartphones or third-party partners, They set about detecting anomalies that were outside the baseline API behavior. These generated security alerts but couldn’t block malicious behavior because the solutions weren’t inline.

Though a step-up from WAFs, ML-based security solutions needed time to learn new APIs as they were released. In companies with Agile development cycles, the rapid release of APIs could cause constant delays as the vendor’s machine learning algorithm studied the behavioral characteristics of each new API. The main drawback of this API security approach was that it could mean periods of false-positives generated until the API security solution learned the new set of APIs.

A New Approach to API Security

A new category of API security solutions is emerging that take an end-to-end approach to API security. It understands the big picture of every API transaction, from endpoint to the back end where sensitive data is stored.

By capturing the metadata of every touchpoint of every API transaction, a complete end-to-end picture can be developed that is built around the end user and pulls ahead of current API security solutions. Once built, this transaction model enables the accurate separation of malicious activity of cybercriminals from the benign normal activity of API clients.

Malicious activity is blocked, while legitimate API activity is processed as usual. This different approach to API security provides a deeper and more accurate picture than other security solutions.

Let’s look back at our BOLA attack example. Because of the system’s big picture awareness and capture of end-to-end transactions, it can reveal suspicious behavior, such as an API transaction in which a client ID is suddenly substituted with a victim’s ID during the same session. This security approach can determine that the normal behavior of end-clients utilizing this API should be a specific client ID that is authorized for access to a specific object for the duration of the transaction. A sudden substitution of a client ID can reveal a malicious intent and immediately trigger an alert.

This holistic design provides a more robust, data-driven approach to API security that can prevent simpler and more sophisticated data breaches from occurring while generating extremely few false-positives.

About the Author

Muzaffer Pasha is an application security specialist and regular contributor to The Inside Trace.

‍View a recorded demo of Traceable Defense AI.