Securing a REST API: 4 Tips to Make Sure Your REST API Is Secure

API security testing has always been critical for any organization that relies on APIs to connect its applications. But securing APIs is now more important than ever, given that API security attacks have surged by an astounding rate of 400 percent in recent months.

To help provide guidance on protecting APIs, this article walks through the essentials of REST API security. It explains why REST APIs can be vulnerable to attack, which types of harm REST API security breaches can cause, and best practices that developers should adopt to keep their REST APIs safe.

‍

REST API Security Vulnerabilities

REST APIs can be compromised through a variety of different types of vulnerabilities. The most common include:

• Broken Object Level Authorization (BOLA): BOLA API vulnerabilities occur when attackers are able to issue custom requests that cause the API to reveal information that should only be available to specific users, not the attackers. In essence, BOLA allows attackers to bypass authorization mechanisms that are supposed to be in place to protect sensitive data.
• Broken authentication: Attackers may also be able to defeat authentication controls by, for example, guessing passwords or stealing access tokens. In this case, they don't bypass security controls; they simply walk straight through them to access information that should be private.
• Lack of authentication: Sometimes, APIs lack any kind of authentication controls at all, making them vulnerable to abuse. This happens most often when developers build internal APIs and assume that third parties won't be using them, so there is no need to build in security controls. Unfortunately, if attackers do discover the API, there is nothing in place to prevent an attack.
• Injection attacks: APIs that accept user input without properly validating it can be subject to injection attacks, which allow malicious actors to inject code into an application by submitting it as part of an API request.
• Excessive data exposure: If an API provides more information than intended, it creates an excessive data exposure risk. This type of API vulnerability typically occurs when developers accidentally program an API to include more data in a response than necessary, enabling attackers to abuse the API in order to retrieve information that shouldn't be available to them.

‍

{{api-cta}} 

‍

Why Is It Important to Secure a REST API?

You probably don't need to be a seasoned cybersecurity expert to understand why REST API security risks like those described above pose a danger.

The main problem is that by taking advantage of these vulnerabilities, attackers can access data that should be private. They may be able to retrieve personal information about a company's customers or employees, for instance, by bypassing or defeating API security controls that are supposed to restrict who can access the data.

In certain cases, REST API security vulnerabilities can lead to other types of damage as well. Under the right conditions, attackers could use injection attacks to execute code of their choosing inside an application or database. They could also launch denial-of-service attacks by issuing high volumes of malicious requests to API servers, which can overwhelm the servers with traffic and cause them to fail.

So, if you want to keep your business's data secure and its operations flowing, you should secure and test your APIs.

‍

‍

Best Practices for Securing REST APIs

Now that we know the dangers of insecure REST APIs, let's look at techniques for protecting REST APIs.

1. Use UUIDs in API Requests

One of the most common ways in which attackers take advantage of BOLA vulnerabilities in REST APIs is by injecting user IDs into API requests. By making user IDs difficult to predict, developers can minimize the risk of BOLA exploits.

For example, imagine you have an app that serves requests at a URL like the following: app.com/userID/1234

Looking at this URL, an attacker could guess pretty easily that substituting a different number (like "2345") instead of "1234" in the URL would cause the API server to generate a response for a different user, because "1234" is a user ID number. If no other authorization or authentication controls are in place, this technique would enable the attacker to retrieve data about other users.

An easy way to prevent this type of attack is to replace the user ID number with a unique identifier that is impossible to guess. For instance, instead of "1234," you could use a UUID like "5eadffe4-fafc-11ed-be56-0242ac120002." That's a randomly generated string, and the chances of an attacker guessing a valid UUID to inject into a request are infinitesimally small.

‍

2. Require Authentication

Ensuring that you require authentication for your API server to respond to a request is another basic best practice for REST API security. This may seem obvious, but again, there are scenarios where developers may falsely assume that they don't need to bother implementing authentication because no untrusted party will be using their API. (This is a classic example of the fallacy of "security by obscurity.")

So, make sure you require clients to submit some kind of authentication credentials when issuing requests. You can do this using passwords and usernames, although token-based authentication is typically a better approach because tokens are more difficult for attackers to steal. In addition, tokens can be easily configured for temporary use, reducing the risk of a successful attack in the event that malicious actors do manage to steal a user's tokens.

‍

3. Validate API Request Input

Validating data that users include in an API request goes a long way toward helping to prevent injection attacks as well as requests designed to expose sensitive data.

The exact way to validate input will depend on which kind of input you're dealing with and which types of data constitute legitimate input. But in general, you'll want to write code that does the following:

• Determines whether a request includes any unexpected fields.
• Detects parts of a request that look like code.
• Examines requests to ensure they are properly structured and formatted.
• Detects requests that contain unusually long strings or fields.

Requests that meet at least one of these conditions should typically be blocked and result in an error response to the client. Although in many cases these requests may be caused by poor formatting, there is a chance that anomalous or unexpected data inside a request could be part of an effort by attackers to bypass API security controls.

‍

4. Throttle and Rate-Limit API Requests

API throttling and rate-limiting are techniques that restrict the number of requests that your API server will process in a given time period. These methods don't prevent REST API security attacks, but they help to minimize their impact by reducing the speed at which attackers can exfiltrate data. 

If you only allow an attacker to make, say, ten requests per minute, it will take much longer for the attacker to scrape data for thousands of users. It will also increase your chances of detecting and shutting down the attack before much data is lost, and it virtually eliminates the risk of API denial-of-service attacks.

Throttling and rate-limiting are typically implemented using API gateways rather than within APIs themselves. This means you don't need to make any changes to your API code; you just need to make sure your APIs are managed via a gateway that allows you to restrict the number of requests that are allowed in a given time period. With most gateways, you can restrict total requests from all users or endpoints as well as impose restrictions on repeated requests from the same user or endpoint.

‍

API Security Testing

Practices like those described above reduce the risk of successful attacks against REST APIs. But because there is no way to guarantee that flaws or oversights don't exist inside your APIs, you should also test your APIs on a continuous basis.

There are two main ways to perform security tests for REST APIs:

• Scanning the code behind APIs, as well as any application logic that helps to validate API input, to look for problems that might trigger a security vulnerability.
• Injecting input that is designed to mimic malicious requests into APIs in order to suss out any potential vulnerabilities.

Performing both types of API security tests on a regular basis creates a critical secondary layer of defense against potential API security flaws.

‍

Conclusion

Attackers are increasingly on the lookout for security vulnerabilities that allow them to abuse APIs in order to steal sensitive data or disrupt critical services. In response, developers must ensure that they design their APIs to be secure from the start while also performing regular API security tests that are capable of detecting weaknesses that attackers could exploit.