Rest API Security Issues | Attack Remediations

Share on facebook
Share on twitter
Share on linkedin
Share on email
API security risks

Stay up to date

Stay up to date with the latest threat reports, articles & mistakes to avoid.

Simple, yet important content.
No salesy pitches and all that, promise!

In this app-driven world, APIs are the infrastructure providing highways for ensuring smoother transport of sensitive data. Insecure APIs add to top security issues faced by web applications and act as an easy invite for hackers. Just because APIs deal with data at the backend does not mean they are hidden from the plain view and are safe. This article provides you with an API security checklist that can be used as a basic benchmark before the release. It also includes examples and recommendations on how to control rest API security issues that are useful during security design process. Before, during or after production, continuous identification and mitigation of API vulnerabilities is an essential factor in this ‘shifting left’ SDLC processes.

Shift left Security

As it says on the tin, moving the security initiatives earlier during the development process eases out pains for later Sharing the highway code analogy, APIs are similar to a road intersection. Any incidents at the intersection would impact all connecting roads to that particular junction. Similarly, any errors, defects in API would affect every application that relies on that API. At an enterprise level, this could impact internal and external organisations depending on the API use. You cannot let the internal team perform functional testing, work on the findings and live with the process. It is vital to simulate threat actor threats, tactics & techniques (TTP) to determine how an API would behave in a particular situation. API penetration testing with external third-party security assessments adept at tailoring test cases in the context of the underlying endpoints. This exercise identifies API vulnerabilities affecting the underlying endpoints and applications, helping to analyse and minimise the risk.

Old habits die hard

Gartner says, by 2022, APIs exploitation will be the most common attack vector for data breaches. A good developer keeps a threat profile in his mind even if there are no defined security processes in their organisation. Unfortunately, with most developers coming from web design backgrounds and lacking secure coding practices skill-set, development turns blind eye to API threats that are different from traditional web applications. There are separate goals and approaches to secure web and API designs. API attack prevention measures in many cases are different from web application prevention strategies.

A few examples of API security vulnerabilities that led to high-risk incidents are listed below:

Right-sizing API security strategy

API security is not about fixing issues during functional and technical API security testing. It is about thinking through the secure SDLC lifecycle. An organisation must have base pillars on which software security is supported across the estate. These include secure coding guidance and policies to ensure standards are followed across applications, networks, data planes and metrics to track progress over time. It acts as a catalyst to secure culture for secure software development. API attack prevention strategy is all about first understanding the complexity, business logic and process of API development and using reverse mentality to include the prevention measures. Have a read of OWASP Top 10 web application vulnerabilities to understand the commonalities between web application and API vulnerabilities. A starting point for assessing your API security would be simulating what happens in the real world. Learning from real-world examples would prove how valuable API security testing is to the development practices.

Critical API security issues

The most common attack vectors linked to security attacks are parameter-based attacks, man-in-the-middle attacks or identity-based attacks. An API security checklist, at the minimum, should consist of the  OWASP top 10 vulnerabilities. Therefore, while scoping security assessments for web applications, API shouldn’t be considered just another add-on but assessed according to methods defined under an endpoint, functionalities and dynamic nature of requests contributing to data transfers. 

Injection Attacks

Similar to web applications, dangerous code submitted with the user input into an insecure application could lead to desired output for a threat actor. Most notable injection attacks such as SQL Injection,NoSQL, LDAP injections, Cross-Site Scripting, XXE (XML Entity ) are caused due to a lack of strict input validation where untrusted data is transferred into the API as part of the input query or command. This is subsequently implemented by the interpreter resulting in processing the malicious input submitted by the attacker. It could lead to unauthorised access, escalation of privileges, data leakages or other potentially high-risk scenarios.

Reliable avoidance of API injection attacks involves strict input validation of client-side data. Define implicit input parameter validation guidelines to ensure strong types are used in API parameters and strong error-handling practices are in use in case of error situations.

Sensitive Data Exposure

Due to the lack of threat modelling the information based on how data flows between client and API endpoint, data exposures issues are a common rest API security vulnerability. Insecure implementations or lack of data filtering implementation leads to unnecessary information exposures that may act as stepping stones for an attacker’s success. One small fix for data in transit or at rest related attacks would be using a valid and securely configured TLS certificate. You can always check the security of your website utilising free SSL server test sites on the internet.

Insufficient Logging and monitoring

Logging and monitoring is an essential aspect for continuous protection of APIs and the underlying data. Due to insufficient logging controls, security teams may miss the relevant events that must be logged to help incident response teams or for audit trail purposes. Additionally, due to the lack of analysis and alerting processes, an organisation may miss an ongoing attack because there was a lot of event logging and recorded data but no one to look for suspicious events and alert the security team. Review and ensure all necessary log levels are in place for all API endpoints. Deploy a monitoring solution to monitor logs for APIs and infrastructure continuously. 

Man In The Middle (MITM) Attacks

MiTM is a scenario where an attacker is positioned suitably between two parties to intercept or change communications. For instance, a threat actor between a user’s browser and an API issuing session tokens in an HTTP request could easily intercept the session and use it against obtaining the user’s account access from his computer. It may lead to a threat actor gaining access into a user account that may include personal details. These attacks are possible where applications do not use SSL/TLS securely or do not use HTTPS at all.

It leads us to another important point that the absence of HTTPS is an open invite to attackers. Simply put, HTTP is a stateless protocol and does not provide any safety of information exchanged between two parties. HTTPS ensures encryption of data transmitted between a browser and the server/application defined by the secure configuration of encryption methods supported by the server.

An application utilising TLS (Transport Layer Security) – when done correctly – provides the following security benefits:

  • Confidentiality – protection of the contents of data in transmission between two web points
  • Integrity – protection against tampering of traffic
  • Replays – protection against a threat actor replaying requests
  • Authentication of hosts with certificates or users with client certificates

Ensure TLS configuration in line with acceptable security practices to avoid any data transmission security threats.

Lack of resources and rate-limiting

Abuse of size and rate limits often leads to threat actors carrying out Denial of Service (DoS) attacks. This rest API security vulnerability is based on the concept that if an API consumes available resources in the form of a request processing loop or causing an erroneous situation, it would render the service unavailable to legitimate users. Threat actors seek such opportunities to target APIs such as public APIs where lack of authentication is confused with lack of security. It is also an issue that could be exploited using multiple attack vectors such as brute force attacks, credential stuffing attacks, user enumeration, or other fuzzing techniques.

By implementing limits such as rate limits on the total number of items in a request, implementing a size limit would help to control the abuse of API endpoints.

API security checklist

Broken Authentication

Due to the inherent nature of how API endpoints work, publicly exposed APIs are often an attractive target for attackers. The majority of the authentication vulnerabilities occur due to insecure or missing protection mechanisms easy to exploit, leading to sensitive data theft, account takeovers or user impersonations. Implement stricter protection including but not limited to factors such as strong credential encryption, failed login attempts limit, authentication token validation. OAuth has been the de facto standard for securing APIs for both authentication and authorisation mechanisms. For Java, using encrypted JWT tokens ensures identity and user characteristics are not readily susceptible to attacks. This topic has been detailed in-depth below.

Discuss your concerns today


Security risks with API Authentication Methods

This is one of the most important security challenges that require greater understanding. Multiple API vulnerabilities such as misconfigurations, broken access control, injection attacks, privilege escalations are associated with authentication and authorisation mechanisms.

Authentication and authorisation are the pillars of a security system. These two concepts work closely in today’s internet applications defining who can access and what access is available. Let’s see what authentication and authorisation terms are:

  • Authentication – who you are (e.g. you require a username, password to log in). In the security context, a broken user authentication flaw is a relevant example.
  • Authorisation – what you can do (e.g. you are authorised to make changes, delete users in an application). Broken object-level authorisation or broken function level authorisation allowing exploitation of horizontal or privilege escalation is an example

The following section covers in-depth content around the most used authentication methods and the security vulnerabilities involved with APIs.

HTTP Authentication (Basic & Bearer)  Methods

There are multiple HTTP authentication schemes as per HTTP Authentication Scheme Registry. We will look into the popular two authentication methods, i.e. Basic and Bearer authentication.
HTTP Basic Authentication

HTTP Basic Authentication is the most straightforward and the easiest method where a sender places a user:password into the request header. This information is encoded with base 64 format, converting the username and password into a set of 64 characters that are transmitted to the server. This method does not include other concepts such as a handshake, cookies, session tokens or other speciality solutions and all authentication information is part of a single HTTP header.

An example of a Basic Auth in a request header:

Authorization: Basic YXBpc2VjdXJpdHk6d2l0aG9ic2N1cml0eQ==

Base64 authentication is an encoding method that is often ‘mistaken’ as an encryption scheme. There are a few security flaws linked with Basic64 encoded data.

  1. Base64 encoded data transmitted over the network is not a secure transmission unless supported by encrypted channels such as HTTPS (configured with secure SSL/TLS settings). SSL/TLS encryption offers security against data in transit between the two points.
  2. Sensitive information (base64 data) is sent repeatedly with each request to authenticate user requests adds to a large attack surface.
  3. Moreover, this information is cached by the user browser, proxies and other solutions between the user browser and the server.

An attacker who has this information would recover the credentials by decoding the data with a trivial effort. Where possible, more robust and secure authentication methods offered by application frameworks should be considered.

Quite simply, your API would not only add to the risk surface, but it would also show up as security finding in the API penetration testing assessments as echoed in OWASP’ Weak HTTP Authentication Methods‘.

HTTP Bearer Authentication

As it says on the tin, ‘Bearer Authentication’ means ‘allow access to the bearer of this token’.

Also known as token authentication, bearer authentication is an HTTP authentication scheme that involves security tokens known as bearer tokens. Bearer auth was initially created as part of OAuth 2.0, however, it is also used on its own. An example of bearer authentication token is shown in the HTTP header below:

POST /target?item=pui-123 HTTP/1.1
Authorisation: Bearer ZyXwVu123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0


API Keys

API keys authentication was developed as more of a fix to the above-mentioned methods. This approach involves assigning a unique value to each first time user. This value acts as a marker, and when a user attempts to reaccess the system, the unique key generated earlier is used to prove they are the same user. This unique key is generated from a combination of information items belonging to users identity such as IP, browser info, etc. Once the key is removed, user access is also removed from the system. Due to its speed, API keys are the default approach by multiple API providers. Use cases for API keys could be filtering logs by API key, blocking unnecessary internet noise (anonymous traffic) or controlling the number of requests made to an API.

An example of an API key is


You guessed it right, now comes the security pep talk – security issues associated with API keys. Although it’s a fast, easily manageable method, API keys are easily accessible to clients. Sometimes, developers make it easy for attackers by passing API keys through GET methods in the URL bar. Any sensitive information should be submitted using POST request and be part of the body of the request.

This threat alone is big enough because stolen keys can be shared around, misused and because it has no expiration, keys can be used again and again unless revoked by the owner. Due to the lack of Authorisation feature in this method, there are better approaches.

OAuth (2.0)

OAuth combines authentication and authorisation methods together, fast becoming the de facto choice. This is a fairly secure and powerful approach when compared to the previous techniques explained in this article. It is an open-standard authorisation framework providing flexibility for applications to allow designated access for its users and the entities authenticating on the user’s behalf. For example, your Gmail account could ask you to grant permissions for to access your profile or use it for new user registration that would provide you with a new member account. The two most common types of tokens used are:

  • Access tokens that present the necessary information to access a resource directly within the set time window.
  • Refresh tokens that present the necessary information to get a new access token from an authentication server. Common use cases include getting new access tokens during first-time access or after old ones are expired. These have longer expiry dates compared to access tokens.

OAuth 2.0 Authentication Security

OAuth is a popular choice for authentication and authorisation mechanisms. OAuth 2.0 defines multiple types of flows, known as grant types, that are basically methods determining how an API client get an access token from the authentication server. These are authorisation code, implicit, resource owner password and client credentials. Security threats with using the implicit type are the leakage of access token through the URL and the injection of an access token, undetectable by the client. Therefore, any reliability on OAuth 2.0 for authentication purposes is a risk. As a mitigation to implicit type threats, the use of authorisation type and PKCE (Proof Key for Code Exchange) is a recommended method.

OpenID Connect (OIDC)

OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0 and is administered by OpenID Foundation. OpenID Connect is an identity layer added on top of the OAuth 2.0 allowing computers to verify the identity of an end-user based on the authentication performed by the authorisation server and necessary profile information in an interoperable and REST-like manner. OpenID Connect lets applications authenticate their users across websites and other apps without the responsibility of storing and managing passwords.

Why use OpenID connect instead of OAuth 2.0? OIDC works by adding an identity layer on top of OAuth 2.0 as mentioned above. This means an id token and an access token are used to ensure authentication and authorisation are well separated and accounted for different purposes. User ID information is part of the JWT (JSON Web Token), called ID token that stores information such as username, email, and so on. As this is signed by Identity Provider, this can be trusted by other apps looking to access the underlying applications.

From the security aspect, this public-key encryption-based authentication framework adds to the security of web users because user identity verification does not have to be redefined by developers, but relied upon as provided by expert service providers. To add protection around the data privacy aspect, OIDC identifies a set of personal information attributes that can be shared between the applications and Identity Providers only after the user gives consent for sharing his personal information.

Broken object-level authorization vulnerability, also known as Insecure Direct Object Reference (IDOR) vulnerability, is an example of API security threats due to a lack of stricter access control. This is largely due to the lack of strict authorisation controls implementation or no authorisation controls. Lack of this API attack prevention leads to data disclosures up to full account takeovers.

Discuss your concerns today


Security considerations around authorisation servers

The above concepts in authentication and some bits around Authorisation give us sneak-peak into why identity is at the heart of cyberattacks. The following are the most common security issues that must be taken into account while building an authorisation server:

  • Phishing Attacks
  • Clickjacking
  • Redirect URL Manipulation (Covert redirects)

Continuous API Security Testing is the way to go…

APIs are the go-to choice for the modern app-driven world. It has extended from traditional web applications to all-inclusive IT ecosystems with mobile and IoT (Internet of Things) devices. Potential risks associated with API endpoints and their exposures are different, thereby, demanding a dedicated approach towards securing APIs. Skill-set, business context and continuous validation are the critical ingredients for businesses to know their attack surface. A businesses’ ultimate goal should remain to secure user data by establishing a reliable API security program to provide continuous protection. If you aren’t sure where to begin, feel free to get in touch and schedule a free consultation where we would be happy to listen to your security concerns and advise accordingly.