9 Major API Vulnerabilities and How You Can Stop Them

APIs have become a major strategic asset for any tech company. They facilitate communication between applications, bridge the integration gap, and help speed up product development in rapidly evolving industries. However, there is a key challenge when it comes to leveraging these strategic advantages: security. 

APIs are challenging to protect, and attackers know this. Plus, according to Gartner’s latest report on API security, “unmanaged and unsecured APIs create vulnerabilities that could accelerate multimillion-dollar security incidents.” Companies can’t afford to ignore these vulnerabilities and should instead have a robust strategy for managing the gaps. 

Beyond its infamous list of Top 10 Web Application Security Risks, the Open Web Application Security Project (OWASP) has also created a dedicated list of API Security Risks. These indicate just how complex it is to secure APIs, given their ongoing evolution and the fact that traditional DevSecOps models don’t cover all the bases. Here, we’re taking a look at nine of the major API vulnerabilities and giving you the tactics you need to secure them.

9 Top API Vulnerabilities

1. Broken Authorization at Object and Function Levels

Ensuring authorization — that users have the right access permissions to the right systems — at various levels is an important function of API security. This ensures that no one has access to more information than they need to depending on their role. 

There are two key areas where authorization should be ensured. Object level authorization validates a user’s ability to access a given object, and these checks aren’t always implemented by developers. Broken function level authorization, meanwhile, opens API functions to exploitation from attackers. 

Getting access via these vulnerabilities could allow bad actors to manipulate data and bypass other important security measures. 

2. Broken User Authentication 

Oftentimes, authentication mechanisms are implemented incorrectly, and this allows attackers to exploit authentication tokens and leverage implementation flaws to assume the identity of authenticated users. This allows them to access sensitive data and use it for nefarious activity.

3. Excessive Data Exposure

Since APIs are often used as data sources, developers tend to use a generic implementation approach that doesn’t always consider the sensitivity of the data being used. As such, when it comes to data exposure, given how different APIs are from one another, there needs to be a more considerate approach in how data is available.

4. Lack of Resources and Rate Limiting 

To date, most APIs haven’t imposed any restrictions on the size or the number of resources that can be requested by a user. This has a couple of potential effects: it can impact API server performance, leading to Denial of Service (DoS) and can also make it easier for attackers to implement authentication attacks such as brute force. 

5. Mass Assignment 

Also referred to as autobinding or object injection vulnerabilities, mass assignment occurs when developers use functions that automatically bind input from the client into code variables and internal objects to help simplify development. Attackers can use this to their advantage by updating or overwriting properties of sensitive objects that were never meant to be exposed. 

6. Security Misconfiguration

Security misconfigurations can happen for a number of reasons: unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, overly permissive Cross-Origin resource sharing (CORS), or verbose error messages containing sensitive information. Attackers often keep their eyes out for these as they are fairly common and easy to exploit.

7. Injection

Injection flaws — such as SQL, NoSQL, Command Injection, etc. — happen when untrusted data is sent to an interpreter as part of a command or query. Attackers can use this by sending malicious data that tricks the interpreter into executing unintended commands or accessing data without the right authorization.

8. Improper Asset Management

Compared to traditional web applications, APIs usually expose more endpoints. This makes having proper and up-to-date documentation indispensable. Having an outdated or incomplete inventory can result in unknown gaps in the API attack surface. Similarly, inaccurate documentation can unknowingly expose sensitive data and make it much harder to identify what vulnerabilities need to be mitigated. 

9. Insufficient Logging and Monitoring

Many APIs don’t have enough logging and monitoring capabilities to identify potential attacks or vulnerabilities. As such, if an attacker gets access, they can have more time than they should to further compromise the system.

How to Stay Ahead of the Threats 

With all these different areas to be aware of, it can feel like a game of whack-a-mole to try and address each area separately. This is why teams need to build a robust API security strategy that covers as many bases as possible. 

When it comes to the earlier stages of the product lifecycle, development and testing, there are a number of steps that can be taken to embody a culture of security: 

• ● Promoting secure API design and development that follow the highest standards in the industry. 
• ● Reducing exposure of sensitive information by minimizing the amount of data that’s shared to client apps. 
• ● Conducting design reviews that include business logic considerations.
• ● Documenting APIs and how they are built or integrated so there is a consistent understanding.
• ● Using machine format for documentation so the specs can be used for basic testing and protection.
• ● Maintaining an accurate API inventory with an automated API discovery that includes REST, GraphQL, and other formats.
• ● Using security testing tools that identify configuration issues or vulnerabilities.

The efforts shouldn’t stop there, however. APIs also have vulnerabilities once they’re live and in production. For this stage in the lifecycle, engineering teams should consider the following: 

• ● Using logging and monitoring systems to help identify attacks and respond to incidents while APIs are in runtime. 
• ● Mediating APIs with API gateways to improve visibility and security. 
• ● Identifying API drift with automated platforms that compare documentation against runtime behavior.
• ● Choosing the right network security controls that are dedicated to ensuring API security. 
• ● Implementing continuous authentication and authorization with the right tools to support it. 
• ● Deploying runtime protection so that it can identify configuration issues in API infrastructure.

To be the most effective, this strategy should be paired with a dedicated platform that was built exclusively for API security. As noted by Salt Security, “securing APIs offers unique challenges” when compared to other product elements. “Security solutions including web application firewalls, API gateways, API management tools, and identity and access management (IAM) tools weren’t designed to prevent attacks on APIs.” Attempting to leverage other security solutions that weren’t designed for APIs is only going to offer vulnerabilities that are easy for attackers to exploit. 

About Author:

Ali Cameron is a content marketer that specializes in the cybersecurity and B2B SaaS space. Besides writing for Tripwire's State of Security blog, she's also written for brands including Okta, Salesforce, and Microsoft. Taking an unusual route into the world of content, Ali started her career as a management consultant at PwC where she sparked her interest in making complex concepts easy to understand. She blends this interest with a passion for storytelling, a combination that's well suited for writing in the cybersecurity space.  She is also a regular writer at Bora.