Top ten vulnerabilities that threaten your API, how to identify them, and how to prevent them
You’ve probably heard of the OWASP top ten or the top ten vulnerabilities that threaten web applications. OWASP also periodically selects a list of top ten vulnerabilities that threaten APIs, called the OWASP API top ten.
The current API top ten are Broken Object Level Authorization, Broken User Authentication, Excessive Data Exposure, Lack of Resources & Rate Limiting, Broken Function Level Authorization, Mass Assignment, Security Misconfiguration, Injection, Improper Assets Management, and Insufficient Logging & Monitoring.
Today, let’s go through each of these vulnerabilities to understand how they happen, how to identify them, and how to prevent them. Let’s start with API #1, Broken Object Level Authorization.
API #1: Broken Object-Level Authorization
APIs often expose object identifiers used to access resources. Broken object-level authorization happens when access control is not properly implemented on these endpoints. Attackers can then view or operate on resources that they should not have access to.
https://api.example.com/v1.1/users/payment_methods/show?user_id=1237962
Using broken object-level authorization vulnerabilities, attackers might be able to read, update, delete or create data objects without permission. If a critical object like users’ PII and credentials are exposed, the bug could cause a data breach or the compromise of the application. For instance, if user information of an online shopping site is exposed, attackers might be able to harvest millions of bank accounts, credit card numbers, and addresses. If this vulnerability was found on a banking site, attackers could leak everyone’s credit information and tax forms! I talk about some examples of this vulnerability, its impact, and how to prevent them in my post here.
API #2: Broken User Authentication
The next vulnerability OWASP selected is broken user authentication. This vulnerability refers to when authentication mechanisms are misconfigured in an API. These issues can be devastating because a single mistake can enable attackers to take over users’ accounts and access restricted data and functionality. But why is this issue particularly common for API implementations?
Authentication is hard for APIs. Often, prompting for user credentials or using multi-factor authentication is not feasible during API calls. So authentication in API systems is often implemented using access tokens: tokens embedded into individual API calls to authenticate the user. Many things can go wrong with access tokens: the token might not be generated or invalidated properly, or the token might be leaked via another vulnerability. If these issues happen, attackers can exploit these misconfigurations to masquerade as someone else. Learn about specific instances of broken user authentication and how to do it properly here.
API #3: Excessive Data Exposure
Excessive data exposure happens when applications reveal more information than necessary to the user via an API response. Some application developers assume that if they do not display the sensitive information on a webpage, users cannot see it. So they send sensitive information in API responses to the user’s browser without filtering out the sensitive info first and rely on client-side code to filter out the private information. In this case, anyone can intercept this API response and extract the sensitive data!
This is one of the most common vulnerabilities I find in real-life applications and API implementations. I talk about how I hunt for excessive data exposure and how you can prevent them in this post.
API #4: Lack of Resources & Rate Limiting
Lack of resources and rate limiting is when the API does not restrict the number or frequency of requests from a particular API client. So an API client can make thousands or even more API calls per second, or request hundred or thousands of data records at once, and the server will still try to fulfill these requests.
A lack of rate-limiting can impact the performance of the API servers and allow attackers to launch DoS attacks. When a single client or multiple clients makes too many requests at once, requests from those clients can overwhelm the server’s ability to process requests, and in turn, make the service slow or unavailable for other users. Another issue is that a lack of rate-limiting can lead to brute-forcing attacks on authentication endpoints. For instance, if there is no limit on how many times a user can submit login requests, malicious attackers can brute-force users’ passwords by trying to log in with different passwords until they succeed. To prevent these issues from happening, you need to restrict users’ access to resources!
API #5: Broken Function-Level Authorization
Broken function-level authorization is when applications fail to limit sensitive functions to the authorized users. Unlike broken object-level authorization, this flaw refers specifically to when unauthorized users can access sensitive or restricted functions they should not have access to.
For instance, when one user can modify another user’s account or when a regular user can access admin functionalities on a site. These issues are caused by missing or misconfigured access controls. They can manifest themselves in many ways, here are some instances I’ve found during penetration tests and what attackers can do with a broken function-level authorization flaw.
API #6: Mass Assignment
“Mass assignment” refers to the practice of assigning values to multiple variables or object properties all at once. But this feature sometimes allows attackers to overwrite, modify, or create new program variables or object properties at will. Using this flaw, attackers might be able to overwrite data that they shouldn’t have access to, or otherwise influence application logic. Learn how these attacks work in detail here.
API #7: Security Misconfiguration
Security misconfiguration is a catch-all name for a wide range of issues, like verbose error messages, misconfigured HTTP headers, unnecessary services or HTTP methods, insecure default configurations, and many, many other configuration issues. They are a constant security threat against both APIs and non-API applications alike. Here is a list of the most common security misconfigurations that can threaten your API or application, and how to eliminate them.
API #8: Injection
Injection is the underlying issue for a large number of vulnerabilities, such as SQL injection, OS command injection, and XML injection. Together, injections account for a huge percentage of vulnerabilities found in real-world applications and APIs.
This vulnerability happens when an application cannot properly distinguish between untrusted user data and code. If the application does not properly process untrusted user data before inserting it into a command or query, the program’s interpreter will confuse the user input as a part of a command or a query. In this case, attackers can send data to an application in a way that will change the meaning of its commands.
In a SQL injection attack, for example, the attacker injects data to manipulate SQL commands. And in a command injection attack, the attacker injects data that manipulates the logic of OS system commands on the hosting server. You can prevent injection issues by implementing input validation, parameterization, and escaping.
API #9: Improper Assets Management
Although “improper assets management” sounds complicated, it’s essentially this: not keeping track of your API endpoints. This can either be due to incomplete API documentation, or a complete lack of API documentation.
An API usually has many different versions, functionalities, endpoints, and a lot of parameters that affects the behavior of that endpoint. And if you don’t keep track on all of this functionality, you become unaware of the security vulnerabilities hiding within the unknown endpoints. You cannot secure what you don’t know about.
Besides incomplete or missing documentation, inaccurate documentation is also a security issue. Even if you have documentation detailing the API endpoints, does it tell you what each endpoint does? Are there any behaviors of the endpoint that are not documented in the docs, such as accepting alternate HTTP methods? Are there any undocumented parameters that can affect the endpoint’s functionality? Inaccurate documentation can make you think that the endpoint is secure, when it is not really behaving the way you think it is.
Some examples of how not having good documentation is a vulnerability, and how you can secure your API here.
API #10: Insufficient Logging & Monitoring
Many organizations only conduct infrastructure logging like logging network events and server logins, and lack API or application specific monitoring infrastructure. If this is you, this means that you do not have insight into the malicious activities going on with your API.
You need an API logging system that would be responsible for monitoring for abnormal API usage. You can log events such as input validation failures, authentication and authorization success and failures, application errors, and any other API events that deals with sensitive functionality like payment, account settings, and so on. Over time, you will be able to understand what normal usage of the API looks like, and detect suspicious activity that could be an attack.
Once you set up logging and monitoring, make sure that you have an effective alert system in place in case of a security incident. After all, a monitoring system is only useful if its results could be delivered in time and to the right people. This way, your team can resolve the incident as soon as possible and limit the damage to your systems.
And that wraps up our overview of the OWASP API top ten! Which one of the OWASP API top ten do you see the most in your work? What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.
Want to learn more about application security? Take our free OWASP top ten courses here: https://www.shiftleft.io/learn/.
Top comments (0)