Top 5 API Security Threats Faced By Developers And How To Avoid Them

Security is one of the most essential and foremost concerns of any API. The software security market is overgrowing year upon year — with the total estimated value reaching $153.16 billion as of 2020.

Whether you’re just beginning to develop an API or are looking to improve your existing APIs, there is a lot you can do to ensure that your software is secure and protected from cyber-attacks. API security threats should be considered in the design process from the very beginning to avoid possible attack vectors later on in the development cycle.

The world’s most skilled hackers are constantly inventing many API security threats. These API security threats have affected many companies worldwide, crashing their APIs and stealing their data. In this article, I will be discussing the five biggest ones out there and how to avoid them.

How safe are web APIs?

APIs are shaping the future, and there is no doubt in that. They provide significant advantages for both consumers and providers.

An API spares developers a lot of time from implementing a feature that may not be related to their main product but improves user experience. Thus, the creators have more free time to innovate their products.

As a company, an API can increase your employees’ productivity if you use it internally, and several benefits if you make it public: more business opportunities and customers, additional profit, etc.

It would be a real challenge to tell you a list of substantial disadvantages of APIs. As years go by, providers find better ways to make their APIs reliable and safe. Unfortunately, so do hackers when it comes to compromising them and their data.

APIs provide direct access to data by their design, meaning increased transparency compared to a web application and a tempting target for hackers. Developers reveal vital details even from the API documentation, but keeping them hidden would affect API consumers. The responsibility is higher when you consider the fact that your API is the backdoor of many applications.

The biggest threats your APIs might face

The first step in improving your API security is analyzing the risks of the data exposed to consumers and the API’s architecture under extreme conditions. Good knowledge of security best practices is beneficial at this point, but there are big chances that you will need additional custom measures.

API vulnerabilities became pretty usual, and this is why the Open Web Application Security Project (OWASP) created a list of 10 most encountered and dangerous attacks on APIs.

1. Missing authorization

Authorization is a complex mechanism of defining what operations a user is allowed to do and what data to access. A poor implementation can easily lead to higher privileges for an ill-intended user or sensitive data leaks.

Whenever an object is accessible through the API, there is a potential security risk as their unique identifier (ID) is exposed, so authorization at this level becomes a serious concern.

Another critical level comes in the form of administrative versus regular functions. If there is no clear distinction between these, attackers could gain unauthorized privileges and access the admin functions.

Solution

A good solution is implementing object-level authorization checks to allow access only to those with valid credentials.

Standardizing user creation and maintenance could be more easily achieved via different tools available. With their help, the access tokens would carry more data, so user-specific restrictions appear in the equation.

2. Broken authentication

Like authorization, authentication is a vital feature of an API that assigns an identity to the new consumers. Knowing who your users are can determine what they can and what they cannot access.

Over time, authentication flows got more complex to prevent credentials theft, but many APIs are still missing some essential features:

• strong password complexity
• password history
• lockout policy (limited number of failed login attempts)

A bad authentication implementation can result in attackers being able to log in as other users by compromising authentication tokens or exploiting other flaws.

Solution

There are a variety of solutions to prevent troubling authentication mechanisms. A very straightforward first step is to inspect every single way to authenticate the API closely and enforce a strong password policy.

Singular API keys with OAuth flows are not always enough. Short-lived access tokens can improve security and significantly reduce authentication risks.

3. No rate limiting

A rate-limiting mechanism is a restriction set on specific endpoints that apply for failed attempts (in the case of inputs that contain credentials), concurrent calls, request payload, etc.

In the absence of one, a hacker can use brute force and enumeration to guess the user’s credentials and bypass the authentication.

Suppose it is not focused on individual users. In that case, the attacker can initiate a Denial of Service (DoS) attack that will overload the API’s resources and make it completely unavailable, exposing the system.

Solution

There are multiple ways to implement a rate-limiter behavior to prevent these situations. You may need just one, or maybe all of them.

For a brute force attack, when the client exceeds the allowed failed attempts limit, the API can reject all further requests with a 429 code error (Too Many Requests) or significantly slow down the response times.

In the case of DoS attacks, the request payload should be filtered along the way and ensured that it does not exceed the API’s resources. For example, if an endpoint provides data in a paginated form, an attacker can request a page of size 2,000,000, which far exceeds the API’s capacity.

4. Data attacks

It may sound weird, but yes, hackers will use data to steal data. This implies a straightforward but perseverent technique: sniffing the API’s traffic to find any sensitive data accidentally released.

But how do you “accidentally” reveal sensitive data? Sadly, the API sends the data and relies on the client to filter it and display to the end-user what is useful. On the other hand, there is a good intention behind this practice, as API developers want to generalize the data source.

Another technique that belongs in this section is an old-school trick, the Injection. Most commonly known as Structured Query Language (SQL) injection, it assumes that the hacker simply sends data to the API. The “magic” is that the data sent is actually a SQL command, which tricks the interpreter into executing it.

Solution

For the prevention of these types of attacks, the keyword is sanitizing the input. Implement constraints for the kind of input the endpoint accepts and blacklist everything that doesn’t match. For example, if your API has a function that updates the phone number, you should reject anything that is not part of that formula.

On the matter of the data sent as a response to the client, the best way to go is by making a rigorous business analysis and limiting as much as possible the response’s content.

In both situations, it is essential not to rely on the client. Either it’s about sanitizing the input or filtering the response, developers must double-check the data’s validity within the API.

5. Misconfigurations

This section includes insecure default configurations, outdated or poorly written APIs documentation, misconfigured HTTP headers, and insufficient logging and monitoring. They may seem harmless and easy to overlook, but a skilled hacker will exploit every little detail if they get the chance.

Default settings may offer sensitive information, like an error stack trace that reveals the API implementation details. A forgotten HTTP header configuration can make the API over permissive to Cross-Origin Resource Sharing (CORS).

Finally, not enough logging does not directly help the attacker but hinders the API developers, as it slows them down from discovering the leak’s source. It gives the hackers plenty of time to get familiar with the architecture by going from exploit to exploit.

Solution

There is no rocket science for these issues, as they can be prevented by solid analysis of API’s activity and establishing a baseline. Writing tests that enforce a specific response’s structure and updating the API’s documentation in the same rhythm with its development can also score significant points in maintaining the API’s security.

Prevention is the best medicine

Web APIs are a powerful tool, that’s for sure. Flexible, customizable, and easy to integrate with any application, they are the dream of every developer. But as a wise man said, with great power comes great responsibility.

In a data-driven world, the API’s security is as important as the API’s architecture and functionality. Having your data stolen can cost you a lot more, in terms of money and your customers’ trust, than investing effort in a safe API.

I hope this article gave you a clear insight into how you can significantly improve your API’s security. If you are not well informed about your API’s architecture or simply want to learn more about them, I recommend this detailed comparison between REST and SOAP APIs.