Home Features API Risks: What Are They and How to Manage Them

API Risks: What Are They and How to Manage Them

APIs are everywhere. If software is eating the world, APIs are the teeth. Those who equip themselves to handle API risks will be better able to weather any cybersecurity storms ahead.

SHARE

Risk management is essential to every business. You can’t eliminate risk, but mitigation strategies will help lower the impact and likelihood of catastrophic events such as data breaches.

SPONSORED CONTENT

By Dan Gordon, DevSecOps Evangelist and Marketing Leader at Traceable.ai.

As more companies develop Application Programming Interfaces (APIs), those who manage risk need to understand what risks APIs introduce to the business. Those who equip themselves to handle API risks will be better able to weather any cybersecurity storms ahead.

Let’s break down three significant sources of risk in APIs and how you can reduce your exposure.

1. Coding Risks

The most basic risk is poor coding practices that lead to exploits by malicious actors. Poorly designed or written code could be a ticking time bomb hiding within your application.

Impact of Coding Mistakes

Vulnerable code can lead to account takeover, theft of personally identifiable information (PII), or denial of service.

Broken Object Level Authorization (BOLA) is a common API flaw with potentially catastrophic effects. Many APIs use unique identifiers to retrieve records. For example, an application might request your Facebook profile from an API by calling “facebook.com/api/profile/12345678”. The number on the end of the URL is a “resource identifier.” It uniquely identifies your profile.

BOLA can occur when changing the number at the end of the URL results in viewing someone else’s profile as that person. When something like this happens with sensitive information, such as in medical records or banking applications, a significant data breach could occur, costing millions to the offending company.

It’s not difficult to write the code to protect against vulnerabilities like these, but it sometimes is forgotten or pushed aside by developers for the sake of quick delivery of features.

How to Manage Coding Risks

Education is your best bet to manage coding risks. Your engineers need to know what pitfalls exist and how to avoid them. Automated security scanners have come a long way, but most still miss the big stuff. For example, BOLA will likely bypass web application firewalls and Runtime Application Self-Protection. These tools know that the URL should have an ID at the end, but they won’t know if it’s the wrong ID. The code must be written to protect against these types of business logic attacks.

The OWASP API Top 10 is an excellent way to educate software engineers on the most common API flaws. Work these risks into onboarding and security training. Task your brightest engineers to build frameworks and patterns into the codebase to help make secure code automatic.

Automation can help, but humans on the front line are the actual investment you need to protect against severe coding mistakes.

2. Asset Management

Do you know how many publicly available APIs your company deploys? Do you know all of their endpoints and how to access them?

Many companies are seeing the number of APIs exploding as they add more functionality to an application. It’s not uncommon to see hundreds of microservices deployed, each with an API endpoint used to communicate with other components.

“Shadow APIs,” or APIs created without proper oversight or approvals, are dangerous if no one knows they exist. Leftover testing endpoints and domains could be publicly available without anyone’s knowledge.

Impact of Poor Asset Management

Old endpoints that are still internet-facing could have outdated and insecure code. Several years ago, Facebook left an authentication endpoint exposed on beta.facebook.com and mbasic.beta.facebook.com. The APIs left on the two testing endpoints didn’t have rate limiting enabled and allowed an attacker to brute force password recovery tokens and take over any Facebook user’s account.

If an API endpoint is left available, but no one within the organization knows about it, it could be attacked without your knowledge. You could be leaving a back door unlocked with no guards or security cameras. People can come and go as they please.

From a financial standpoint, if these rogue APIs are running in cloud services, you could be wasting money paying for resources you don’t need or want.

How to Manage Asset Management Risks

An essential tool in asset management for APIs is API discovery. API discovery is automation that helps you find all exposed and vulnerable endpoints. You can then review and shut down unsafe or unwanted endpoints.

If unwanted endpoints are using cloud resources, you can use tools like Swabbie to find and shut down unused resources. Swabbie can find the endpoints no one uses but are still hanging around, costing you money.

3. Excessive Data Exposure

Data exposure occurs when APIs return too much data to the client. Each client should only receive the data they need to perform their function. Otherwise, another vulnerability could be compounded by exposing PII or other sensitive data.

Uber’s API had a vulnerability that led to excessive data exposure. An endpoint returned information about the user, including their email and physical address. Unfortunately, this endpoint was susceptible to a BOLA attack and produced another user’s record when the client used a different user’s ID. The API gladly spits out the personal information of any user in the system. The client only used a fraction of the data returned.

Impact of Excessive Data Exposure

Excessive data exposure can lead to account takeover and theft of PII. It often is chained to another vulnerability to steal data to impersonate someone to another service or steal their identity.

How to Manage Excessive Data Exposure

APIs shouldn’t serve data not used by the client. This practice reduces exposure and the chance that another vulnerability leads to a data breach.

Also, APIs that aren’t meant to collect or distribute sensitive data shouldn’t return it as part of a request. Microservices typically have a unique data store, and copying personal data into multiple places isn’t safe. Keep a close eye on where your data is stored and how someone can access it.

Tools exist that can find sensitive data. For example, Amazon Macie can scan what you have stored in your AWS S3 buckets for sensitive data, and Traceable AI can help detect sensitive data leakages at run-time. You can use this information to decide what you should store and where. AI-driven automation can make it easier to find and classify data, so you know what you’re exposing to the outside world.

Managing Risks in an API World

APIs are everywhere. If software is eating the world, APIs are the teeth.

APIs and microservices help companies become more agile. They help speed up the delivery of new products and features. They connect different services so business owners can automate almost everything.

But these new advancements bring new risks. Learn to identify and manage these risks so the APIs don’t end up eating you.


About the Author

Dan Gordon is a DevSecOps evangelist and marketing leader at Traceable.ai. He is an IT software and product leader from companies such as GitLab, Electric Cloud, HP, and Opsware with over 20 years of IT leadership and software experience including the ideation, product management, and positioning of multiple award-winning DevOps tools. He is guided by his “time in the trenches” as an application developer, system and network security administrator, systems architect, and IT leader. Dan also draws from his experience leading the software delivery and Agile transformations of several product organizations.

Disclaimer

Views expressed in this article are personal. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.