In this app-driven world, APIs provide highways for ensuring smoother transport of sensitive data. Insecure APIs add to web applications’ top security issues 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 an API security checklist that can be used as a primary benchmark before the release. It also includes examples and recommendations on controlling the REST API security threats that are useful during the security design process. Before, during or after production, continuous identification and mitigation of API vulnerabilities are essential in this ‘shifting left’ SDLC process.
Google research suggests that three out of four organizations continued their digital transformation investments during the pandemic. Digital transformation relies on how best software can be leveraged to deliver effective business transformation. APIs are how software communicates with other software & services.
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 road intersections. Any incidents at the meeting would impact all connecting roads to that junction. Similarly, any error defects in API would affect every application that relies on that API. This could impact internal and external organizations at an enterprise level depending on the REST API use. You cannot let the internal team perform functional testing, work on the findings and live with the process. Simulating threat actor threats, tactics & techniques (TTP) is vital to determine how an API would behave in a particular situation. REST 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 analyze and minimize the risk.
Based on the famous state of API 2021 report by Postman, 56% of respondents cited Security as a development priority.
Old habits die hard
A REST API uses a representational state transfer (REST) architecture. This style uses stateless HTTP to request access and process data for integration with RESTful web services.
Gartner says, by 2022, APIs exploitation will be the most common attack vector for data breaches. A good developer keeps a threat profile in mind even if there are no defined security processes in their organization. Unfortunately, with most developers coming from web design backgrounds and lacking certain coding practices and skill-set, development turns a blind eye to API threats that are different from traditional web applications. There are other 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:
- Broken Object-Level Authorization (BOLA/IDOR) Vulnerability in Facebook’s GraphQL API
- Shopify security incident notice
- Authentication bypass – Google cloud service account
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 organization must have base pillars supporting software security across the estate. These include fast 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 a culture for secure software development. REST API attack prevention strategy is all about first understanding the complexity, business logic and process of REST API development and using reverse mentality to include the prevention measures. Read OWASP Top 10 web application vulnerabilities to understand the commonalities between web application and REST 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 threats
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, and 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 unauthorized 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 used 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 REST API endpoint, data exposure 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 minor 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 by utilizing free SSL server test sites on the internet.
Insufficient Logging and monitoring
Logging and monitoring are essential to continuously protect REST 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 organization 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 REST API endpoints. Deploy a monitoring solution to monitor logs for REST 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 to obtain the user’s account access from his computer. It may lead to a threat actor gaining access to a user account that may include personal details and installing malware or other malicious actions. 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: 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 utilizing 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 with traffic
- Replays – protection against a threat actor replaying requests
- Authentication of hosts with certificates or users with client certificates
Ensure TLS configuration is in line with acceptable security practices to avoid any data transmission security threats.
Lack of resources and rate-limiting (DoS Attacks)
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 causes an erroneous situation, it would render the service unavailable to legitimate users. Threat actors seek 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 rate limits on the total number of items in a request, implementing a size limit would help control API endpoints’ abuse. Similarly, mobile applications should be tested against top 10 mobile security risks.
Broken Authentication
Due to API endpoints’ inherent nature, publicly exposed APIs are often an attractive target for attackers. Most authentication vulnerabilities occur due to insecure or missing protection mechanisms that are 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, and authentication token validation. OAuth has been the de facto standard for securing APIs for both authentication and authorization 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.
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, and privilege escalations are associated with authentication and authorization mechanisms.
Authn vs authz (Authentication vs authorization)
Authn is abbreviated from authentication and authz is an authorization. Authentication vs authorization is a popular topic and equally important concept when it comes to verifying the identity of a user and enforcing the specific permissions to access particular information.
Authentication and authorization are both processes that protect information and systems. Authentication is the process of verifying a user’s or system’s identity, while authorization is the process of determining what level of access a user or system has.
These are the pillars of a security system that work closely in today’s internet applications defining who can access and what access is available. Let’s see what authentication and authorization terms are:
- Authentication – who you are (e.g. you require a username password to log in). A broken user authentication flaw is a relevant example in the security context.
- Authorization – what you can do (e.g. you are authorized to make changes, or delete users in an application). Broken object-level authorization or broken function-level authorization 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.
- 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.
- Sensitive information (base64 data) is sent repeatedly with each request to authenticate user requests adds to a large attack surface.
- 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, application frameworks should consider more robust and secure authentication methods.
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 a bearer authentication token is shown in the HTTP header below:
POST /target?item=pui-123 HTTP/1.1 Host: sample-site.com Authorisation: Bearer ZyXwVu123456Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0
status=confirmed
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 special 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
jsSdeS.0EdiMlskfEFjedfjeDSdfje-SfjeSF
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 part of the request’s body.
This threat alone is big enough because stolen keys can be shared around and misused, and because it has no expiration, they can be used repeatedly unless revoked by the owner. Due to the lack of Authorization feature in this method, there are better approaches.
OAuth (2.0)
OAuth combines authentication and authorization methods, 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 authorization 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 quora.com 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 is a popular choice for authentication and authorization 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 authorization 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 authorization 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 authorization 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 OAuth 2.0 as mentioned above. This means an id token and an access token are used to ensure authentication and authorization 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 to 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. It is largely due to the lack of strict authorization controls implementation or no authorization controls. Lack of this API attack prevention leads to data disclosures up to full account takeovers.
Security considerations around authorization servers
The above concepts in authentication and some bits around Authorization 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 authorization server:
- Phishing Attacks
- Clickjacking
- Redirect URL Manipulation (Covert redirects)
Overall, OWASP API’s top 10 security risks is an excellent consideration to be kept in mind before API projects go live. This ensures that the organisation considers all security threats, including OWASP API top 10, to reduce the attack surface.
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 toward securing APIs. Skill-set, business context and continuous validation are the critical ingredients for businesses to know their attack surface. A business’s ultimate goal should 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.
