Top 7 REST API Security Threats

Internet security is a topic that has been discussed increasingly quite often by technology blogs and forums and with valid reason: the numerous high profile security breaches have grown up significantly in recent years. Security is of great importance, especially in the world of REST APIs.

API security is the single biggest challenge organizations want to see solved in the years ahead, and solving the security challenge is expected to be a catalyst for growth in the API world.

According to the 2018 State of API integration report by Jitterbit:

APIs are Transforming Business

An impressive 64 percent of organizations are creating APIs today for use in either internal or external use cases. While a quarter of the respondents are not creating APIs at all today, 40 percent are leveraging APIs in both internal and external use cases.

API Creation and Management Is Falling to Developers

A majority of organizations leveraging APIs today rely on their developers to both write and manage these APIs. While 33 percent use dedicated technology to manage their APIs, 90 percent of respondents lean on their development teams or outside resources to code APIs from scratch.

Already burdened with coding integrations between an increasing number of new cloud applications, organizations are placing additional demands on their developers to create and manage APIs for the business.

Security of REST API

Security issues must be an important aspect to consider any time a REST API is being designed, tested, and deployed. With the mind-blowing development of REST APIs, the security levels, most times, are underestimated in the design and development of the API. Security of sensitive data, be it organizational or personal information, is an important factor troubling developers nowadays. REST APIs are not an exception, being part of essential systems that require protection against security threats and breaches.

According to the 2018 Postman community report (survey), more developers are paying attention to REST API security and have higher confidence than the year before:

In this post, I will cover the top 7 REST API security threats in today’s IT world in order to get everyone's attention and assist in being aware of the security threats that have the capability to reflect on the performance of REST APIs.

Security concerns with REST.

REST typically uses HTTP as its underlying protocol, which brings forth the usual set of security concerns:

• A potential attacker has full control over every single bit of an HTTP request or HTTP response. Since REST APIs are commonly used in order to exchange information that is saved and possibly executed in many servers, it could lead to many unseen breaches and information leaks.
• The attacker could be at the client side (the consumer of your REST API and, where the victim is the REST API server) or at the server side (the attacker gained control over your REST API server) where he creates a rogue, malicious app. The victim, in this case, is the application consuming resources from your remote REST API services.
• For an application using REST as client or server, the other side typically has full control on the resource representation and could inject any payload to attack resource handling (gaining arbitrary Java code or system command execution, for example).

In a REST architecture, end-to-end processing implies a sequence of potentially vulnerable operations:

• During the mapping from/to the HTTP message and resource URL (controller mapping).
• When the object representing the target resource is instantiated and the requested operation is invoked (calling the services from the controller).
• When producing state representation for the target resources (the services specific function).
• When accessing/modifying the data in the backend systems that host the resource state (saving into the DB or storage).

The layered sequence of transformations in REST frameworks means that a single weak link in the chain could make your application vulnerable.

The Top 7 REST API Security Threats

1. Injection Attacks

In an injection attack, a dangerous code is embedded into an unsecured software program to stage an attack, most notably SQL injection and cross-site scripting. This exposure could, in fact, be manipulated by transferring untrusted data into the API as part of a query or command. The input is subsequently implemented by the interpreter which can result in an attacker obtaining unauthorized access to information or carry out other damages.

The most effective way to stop or deny an injection attack is by adding input validation, here are the most crucial guidelines:

• Validate input: length/range/format and type
• Achieve an implicit input parameters validation by using strong types like numbers, booleans, dates, times or fixed data ranges in API parameters
• Constrain string inputs with regex
• Define an appropriate request size limit and reject requests exceeding the limit with HTTP response status 413 Request Entity Too Large

2. DoS Attacks

In a Denial of Service (DoS) attack, the attacker in most cases pushes enormous messages requesting the server or network to establish requests consisting of invalid return addresses. The attack is capable of rendering a RESTful API into a non-functional situation if the appropriate security precautions are not adopted. In recent times, whether your API is exposed or not, it could possibly be accessible by other people (attackers inclusive).

As these API DoS attacks become more common, and as organizations increasingly rely on APIs for their business needs, security professionals should proactively plan to deal with such attacks. Even if an API key (or access token) used for application authentication is disabled, a key can easily be reacquired through a standard browser request. Therefore, invalidating a current access token is not a long-term solution. If a DoS attack is traced back to a specific IP address, then blacklisting that IP address isn't a long-term solution either, because the attacker can easily acquire a new one.

That's why multiple access control methods are necessary. For non-sensitive information, the use of API keys might be sufficient. However, to better prevent a DoS attack, the use of HTTPS and more robust authentication mechanisms, including OAuth, mutual (two-way) TLS (transport layer security) authentication, or SAML (security assertion markup language) tokens, are necessary.

To prevent a massive amount of API requests that can cause a DDoS attack or other misuses of the API service, apply a limit to the number of requests in a given time interval for each API (also called spike arrest). When the rate is exceeded, block access from the API key at least temporarily, and return the 429 (too many requests) HTTP error code.

In case you are starting to build your new REST API, check for web servers that have many security-oriented features.

3. Broken Authentication

These particular problems can make an attacker to either bypass or take control of the authentication methods made use of by a web program. Missing or inadequate authentication can result in attack whereby JSON web tokens, API keys, passwords, etc. can be compromised. The aim of the attack is usually to take charge of several accounts, not to mention the attacker getting the equal privileges as the attacked user. Solely authenticated users should be given access to the APIs.

The APIs authorization and authentication requirements could very well be taken care of using OpenId/OAuth tokens, PKI, API key. It would be wise never to send credentials over connections that are not encrusted, also don’t reveal session ID in the Web URL.

4. Sensitive Data Exposure

Exposure of sensitive data caused by lack of encryption in transit or at rest may result in an attack. Sensitive Data Exposure happens whenever an application is unable to properly secure sensitive data. The information can differ from private health information to credit card information, session tokens, passwords and a lot more tend to be venerable to attack. Sensitive data requires high security which includes encryption at rest or in transit, in addition to extraordinary safe practices when exchanged with the browser.

In order to avoid exposing sensitive data, you must use an SSL.
Today, you can get a free certificate with Let's Encrypt. SSL and TLS go a long way in removing basic API vulnerabilities with almost minimal effort.

To get an excellent report on how good your implementation is, run your URL against the Qualys SSL server test. Here is ours:

5. Broken Access Control

Access control, in some cases known as authorization, is how a web software allows access to functions and contents to certain people rather than everybody. Missing or inadequate access control can permit the attacker to gain control of other users accounts, alter access privileges, change data etc.

Company application access tends to attack when operational level accessibility is not configured properly by developers leading to access vulnerabilities. Declined access is the best-known consequence of broken access controls and exploitation of access control is the main craft of attackers.

Access control is detectable making use of manual means, or even via automation for the lack of access controls in some frameworks. Access control is usually productive if implemented in reliable server-less or server-side API, whereby the attacker won't be able to alter the access control metadata.

6. Parameter Tampering

It’s an attack that is based on the manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc. Usually, this information is stored in cookies, hidden form fields, or URL query strings and is used to increase application functionality and control.

This happens when a harmful website, program, instant message, blog, or e-mail makes a user’s internet browser to carry out an unnecessary action on an authorized site. It allows an attacker to makes the targeted system to carry out a function using the target's web browser, unknowingly to the attacked user, perhaps until the not authorized transaction has been carried out.

The attack success depends on integrity and logic validation mechanism errors, and its exploitation can result in other consequences including XSS, SQL Injection, file inclusion, and path disclosure attacks.

You should carefully validate URL parameters received to ensure the data represents a valid request from the user. Invalid requests can be used to attack the API directly or targeting the application and systems behind the API. Put validators on the application and try to use API Signing for the requests sent to the REST API. It is also good to create automatic security tests for your API in order to see that no parameter tampering affects your REST API.

7. Man-In-The-Middle-Attack (MITM)

It’s when an attacker is secretly altering, intercepting, or relaying communications between two interacting systems and intercepts the private and confidential data passed between them. MITM attacks occur in two stages: interception and decryption.

HTTP and Lack of TLS

The absence of a Transport Layer Security (TLS) in an API is practically equivalent to handing out open invitations to hackers. Transport layer encryption is one of the most elementary ‘must-haves’ in a secure API. Unless a TLS is used, risks of the fairly common ‘Man-In-The-Middle’ attacks remain very high. Use both SSL and TLS in your APIs, especially if you are going public with your APIs.

Summary

When developing a REST API, you have to pay attention to security from the start. Consider using an existing API framework that has many of the security features built in. At RestCase, we are using SugoiJS API Framework that we also contribute to its codebase along with testing and security guiding. In this way, security is uniformly built in and developers can focus on the application logic.

After all that, don’t neglect to allocate resources to test the security of the APIs. Make sure to test all the security threats mentioned in this post.