Application programming interfaces (APIs) make everything a bit easier - from data sharing to system connectivity to delivery of critical features and functionality - but they also make it much easier for the bad actors (and the bad bots they deploy). 

Here are the top five API vulnerabilities that get exploited by hackers, including some tips to help close those gaps.  

 

1. Too easy to discover

When I’m in hacker mode, the first thing I do is identify as many APIs as possible. I start by using the target application as expected. Web applications get opened in a browser; mobile apps are download and installed. All the while, I monitor the communications with an intercept proxy. 

The intercept proxy catches all the requests my browser or mobile app makes to the backend webservers, allowing me to catalog all the API endpoints available. For instance, most APIs have /API/V1/login as an authentication endpoint. 

If the target is also a mobile app, I take the application package apart and look at the API calls available inside the application. With all the possible activity in view, I can search for common misconfigurations or APIs that don’t protect user data correctly.

Finally, I look for API documentation. Some organizations publish API documents for 3rd parties but use the same API endpoints for all users. 

With a decent inventory of the endpoints, I can test both standard user behavior and abnormal behavior testing. You can find interesting vulnerabilities through both methods.   

The Fix: To make the discovery of your APIs more difficult, ensure your API documentation is gated and controlled with entitlements that only allow access to valid users. While pinning the certificate on a mobile application doesn’t completely hide the API endpoints and isn’t perfect, it does add an extra step. API requests to the web server should be as obfuscated and controlled as possible.

 

2. Too verbose

Lately, we’ve been watching Account Take Over attempts increase at customers. These types of attacks are made easier by error messages that are too wordy for their own good. Having a verbose error message guides the attacker to learn what they need to change to make the request work. APIs, designed for high-speed transactions with low load, enable attackers to use high-performance systems to figure out valid accounts and then attempt to login and change the passwords for their benefit.

The Fix: Don’t tell me what I did wrong; even if it seems like good user experience, it’s bad for security. I shouldn’t be able to send in a bad username or bad password and have that system tell me which information is wrong (i.e., Account not found or Password incorrect). The same goes for error messages for queries of the data; if the query/search isn’t formed correctly or cannot be performed for whatever reason, “OOPS, Something Went Wrong” should be the only information provided.

 

3. Too many parameters

As attackers iterate through API calls to attack systems, they have to figure out what they can send in to get data out. Attackers are counting on the fact that complex systems have more places for failure. Once an attacker identifies an API, they’ll catalog the parameters and then attempt to access the data of an administrator (vertical privilege escalation) or another user (horizontal privilege escalation) to gather additional data. Often, too many unnecessary parameters get exposed to users.

In a recent research project, an API call to a target service sent me back a massive amount of data. Many of the data elements weren’t needed, like the processor key for a payment gateway and the discounts available and shouldn’t bleed through. These bonus elements provide a better understanding of the context and the syntax for those API calls. You don’t need much imagination to figure out what to do next; these extra parameters give the attacker rich data sets to attack.

The Fix: If you limit what the user can see to only what’s necessary, limit transmission of critical data, and keep the data query structure unknown, you’ll make it far harder for an attacker to brute force requests to parameters they know exist.

 

4. Too much data

Along the same lines as too many parameters available, the concept of gathering data becomes an obvious next step. Many organizations make their systems available for anonymous connections and tend to leak data the average user doesn’t need. In addition, many organizations tend to store data that can be accessed directly.

Security professionals struggle with the challenge that API requests often reveal data store locations. For instance, when I look at videos from my security camera, I can see the information comes from an Amazon S3 bucket. Often those S3 buckets are not secured correctly, and anyone’s data can be retrieved.

Another common data challenge is that organizations tend to be packrats, storing much more data than is needed. While data about clients who are no longer clients, or old case notes with sensitive information, may no longer provide business value to your organization, they could be very embarrassing and harmful if breached.  

The Fix: Thorough data reviews are a must for any organization that stores any data, not just PII or PHI. After reviewing the data that’s stored, data access requirements should be put in place and tested. Make sure that the data that is accessed anonymously is data that should be accessed by everyone.   

 

5. Too little design for security

Application design almost always considers functionality and usability but, all too rarely, security. We’ve heard from CISOs that API security, in particular, gets left out of the design process entirely. Instead, they let developers build and deploy and then look for issues once the API is in production and vulnerable.  Security, including API security, needs to be part of the design and should be implemented as one of the first considerations, not bolted on later.

The Fix: If you haven’t reviewed the security architecture of your application, it’s a significant first step to moving toward a secure system. Remember, APIs make attackers more efficient as well as make the use of your system more efficient. The goal of designing for security is to change the bias to just building efficiency for your users, not your attackers.

 

I know I’ve only provided a small view of the common API vulnerabilities. The important thing is to have security come up in discussions early in the development process. Small changes can yield significant benefits, or at the very least, shield you from financial losses and humiliation resulting from API breaches.

 

This article originally ran in Today’s Cybersecurity Leader, a monthly cybersecurity-focused eNewsletter for security end users, brought to you by Security Magazine. Subscribe here.