REST API Security Vulnerabilities

Simple, schematic, faster to develop, and quick deployments make APIs so popular and widely used. So, naturally, it brings various challenges to maintain its implementations and keep them secured from various threats, such as Man-in-the-Middle attacks, lack of XML encryptions, insecure endpoints, API URL parameters, and so on.

REST API has similar vulnerabilities as a web application. In this article, we will present a few common API vulnerabilities that every developer should be aware of and on the lookout for in their code.

API Exposing Sensitive Data and Protection

Personal information, credit card information, health records, financial information, business information, and many other categories of personal information need protection, so we need to evaluate and determine the types of data being transmitted or stored and ensure critical data is protected with appropriate encryption algorithms and security measures. Some of the dos and don'ts of REST API security best practices are as follows:

• Classification of data and apply controls according to these classifications
• Do not store sensitive information unless necessary and discard it as soon as possible. Use tokenization and truncation methods to prevent the exposure of sensitive data
• Encryption is a necessary and crucial protection measure
• Do not implement a cache for sensitive data (or disable cache for sensitive data transactions)
• Use salts and adaptive (configurable number of iterations) hashing methodologies for passwords

Authentication Attacks

Authentication attacks are processes with which a hacker attempts to exploit the authentication process and gain unauthorized access. Bypass attack, brute-force attack (for passwords), verify impersonation, and reflection attack are a few types of authentication attacks. Basic authentication, authorization with default keys, and authorization with credentials are a few protection measures to safeguard our APIs. 

Cross-Site Scripts

Cross-site scripts, also known as an XSS attack, is the process of injecting malicious code as part of the input to web services, usually through the browser to a different end-user. The malicious script, once injected, can access any cookies, session tokens, or sensitive information retained by the browser, or even it can masquerade the whole content of the rendered pages, XSS categorizes into server-side XSS and client-side XSS. Traditionally, XSS consist of three types; they are Reflected XSS, Stored XSS, and DOM XSS. 

Cross-Site Request Forgery

Cross-site request forgery, also known as CSRF, sea-surf, or XSRF, is a vulnerability that web applications expose a possibility of the end user forced (by forged links, emails, HTML pages) to execute unwanted actions on a currently authenticated session. Synchronize token pattern, cookie-to-header token, double submit cookie, and client-side safeguards are common CSRF prevention methodologies.

Denial-of-Service (DoS) Attack

The Denial of Service is an attack intends to make the targeted machine reach its maximum load (capacity to serve the requests) quickly by sending numerous falsify requests, and so, the target system denies further genuine requests.

Injection Attack

The attacker supplies an untrusted input to the application, which gets executed/processed as a part of command or query, thus, this results in the partial or complete discourse of the application behavior and leads to consequences such as data theft, data loss, loss of data-integrity, DoS, and even leads to full system compromise.

Insecure Direct Object References

Insecure Direct Object References, or simply IDOR, is an equally harmful top API vulnerability; it occurs when an application exposes direct access to internal objects based on user inputs, such as Id, filename, and so on. You might have observed that many REST URIs expose some sort of IDs, especially for fetching resources. Let's take an example scenario to make it clear for the readers — say Bob is using an API client and he needs to get his file with ID 1001. He would need to use https://myapi.server.com/browse/file/id/1001, but assume he is trying Alice's file (1003), which he not supposed to, i.e. Bob tries to use the URL https://myapi.server.com/browse/file/id/1003, so he should be denied access. If not, then the API is exposed to the IDOR vulnerability.

Man-in-the-Middle (MITM) Attack

A Man-in-the-Middle attack is an attack from a perpetrator place in the middle of the network or communication between a genuine user and an application server. It intends to steal, eavesdrop, impersonate, and secretly relay, intercept, or alter communications including API messages between two communicating parties, besides appear as if a normal exchange of information is underway.

Replay Attacks and Spoofing

Replay attacks and spoofing, aka playback attacks, are network attacks in which a valid data transmissions (supposed to be only one time) being repeated many times (maliciously) by the attacker who spoofed the valid transaction and replays it as many times as they would like. While the server is expecting a valid transaction, it will not have any doubts as those requests is a valid transaction as per the server. However, it is a masqueraded request and leads to catastrophic effects for the clients.

The protection measures include a one-time password with session identifiers, TTL (Time-To-Live) measures MAC implementation at the client side, and including the timestamps in the request along with secure protocol such as Kerberos protocol prevention, secure routing, and Challenge-Handshake Authentication Protocol (CHAP).