Companies of all sizes are struggling to keep their APIs safe, as evidenced by the many recent hacks, leaks, and exploits. While the traditional approach to API security largely focuses on technical aspects, like managing Denial of Service attacks and preventing code injections, it turns out that a growing number of hacks are actually caused by poor management of API permissions or flaws in business logic.

Today, we walk through five of the most common API vulnerabilities. We’ve included both traditional flaws and some more recent ones. Let’s see how to recognize them and rectify such vulnerabilities before they cause series issues.

1. Denial of Service

Denial of Service attacks are one of the most rudimentary ways a hacker can harm your API. The idea is simple: the hacker sends a large number of bogus requests to your API, thereby drowning out and slowing down any legitimate requests.

Most API gateways are armed with rate-limiting features to control the number of requests that actually reach your servers. Unfortunately, hackers have adapted and instead look to slow down your API by making fewer requests, but for much, much larger payloads. For example, they might exploit a search feature in your API which returns thousands (or millions) of results at once, thus hampering your servers’ ability to respond to other requests.

How to Fix It: Thankfully, there’s an easy fix for this vulnerability, known as pagination. Pagination divides single responses into multiple parts, ensuring no payloads are oversized. While there are a lot of nuances in how you might implement pagination, Amjad says that the most important thing is to include some kind of upper limit on how many results your API can return at once.

2. Code Injections

Another classic web vulnerability is the code injection. Examples include both SQL injections and cross-site scripting (XSS).

In an SQL injection, the hacker adds SQL statements to one of the entry fields on your API or application, ultimately telling the database server to perform some unintended action. An example of how this might be used maliciously is by telling the database to display sensitive data which would otherwise remain hidden.

In cross-site scripting, the hacker places a client-side script on a web page accessed by other users. Whenever a user visits that page, the script is executed, again carrying out some unintended action — like sending users’ cookies to the hacker.

How to Fix It: Preventing SQL injections is surprisingly easy: just make sure you use parameterized statements in SQL queries. With parameterized statements, the user can only enter data of a certain type into individual parameters — which are then combined to form the final query — preventing them from inputting entire SQL statements.

To prevent cross-site scripting, ensure input validation takes place on the server-side since input validation on the client-side can be easily bypassed. Also, encode any input data before sending a response back to the browser.

3. RBAC Privilege Escalation

In APIs with role-based access control (RBAC), a common vulnerability is privilege escalation. Privilege escalation is when a hacker gains access to resources that should be protected, and it’s common with RBAC since changes to endpoints are often made without due concern for who can access them.

A relatively recent example of this took place in November 2018 with Google Plus. Google updated its People:get endpoint which was previously used to expose basic user information to third-party developers. After the update, the endpoint allowed developers to view sensitive data for all user profiles. As a result of this, account records for more than 50 million users were leaked within the three days it took Google to fix the bug.

How to Fix It: Unfortunately, traditional security scanning solutions can’t catch these issues, since they take the form of completely legitimate API requests. Instead, the solution is to conduct a continuous assessment of all API endpoints and how they map to various roles. Amjad mentions they have a tool to automate this process at FX Labs.

4. No ABAC Validation

In APIs with attribute-based access control (ABAC), there are similar vulnerabilities to those described above. In this case, regressions can allow users to gain access to objects or actions (such as viewing, updating, or deleting) which should only be available to the API owner.

For this, Amjad gives the example of Citi, which was hacked into just a few years ago. While parameter tampering was also used to facilitate the hack, Amjad says that the root cause was a lack of ABAC validation. This allowed the hacker to access the resources of other users just by guessing their account numbers (which, conveniently, had predictable patterns).

How to Fix It: Once again, traditional solutions just won’t cut it for catching these vulnerabilities. While it is difficult to keep track of all the policies that control access to your API’s resources, continuous assessment is the only way to ensure you can protect against this.

5. Flaws in Business Logic

Finally, many API vulnerabilities are associated with flaws in business logic. This allows hackers to use legitimate workflows in a malicious way, thereby triggering some unintended action which really depends on the nature of the workflow.

This might mean locking some users out, as has been the case with some online auction platforms. As Amjad explains, hackers could outbid other users by performing repeated login attempts on fellow bidders’ accounts, thus causing the application to log users out.

How to Fix It: To prevent this, Amjad once again recommends you continuously audit your API, considering how workflows might be used against you. As a general rule of thumb, he also recommends exposing as little information as needed; in the example of the auction platform, it was exposing bidders’ usernames that allowed the exploit.

Final Thoughts

Although code injections and DoS attacks are still very important, many API owners overlook the importance of having solid business logic and closely controlled permissions. While the technical issues — like DoS attacks and code injections — come with technical solutions, the remaining three API vulnerabilities we discussed fall into a grey area between business and tech, and need to be monitored continuously to stay secure.