Application Programming Interface (API) Vulnerabilities and Associated Security Best Practices

• by Ellie Hurst
• Advent IM Blog

This is an insightful and helpful post penned by Advent IM Consultant, Jon Carpenter.

Introduction
APIs are the fundamental building blocks of software applications, allowing diverse systems to interconnect and function in unison, understanding and addressing common API security vulnerabilities is essential. An API vulnerability is a flaw that allows attackers to bypass security, leading to potential data breaches or system compromises.
This blog will look at a number of recent data breaches where API vulnerabilities have been exploited by threat actors and will conclude with best practices to mitigate against this threat.

Dell, Facebook, Twitter and Trello data breaches
In April 2024, it is reported that 49 million Dell customer records were retrieved by a threat actor known as Menelik using a partner portal API they accessed as a fake company. In April 2024, the records which included customer order data, warranty information, service tags, customer names, installed locations, customer numbers and order numbers were offered for sale on a hacking forum.
Menelik is reported to have accessed the data after discovering a Dell portal for partners that could be used to look up order information and by registering multiple accounts under fake company names he had access without verification.
The portal reportedly did not include any rate limiting, therefore, the Menelik was able to harvest the information of 49 million customer records by generating 5,000 requests per minute for three weeks, without Dell blocking the attempts.
In 2021, threat actors abused a Facebook API bug to link phone numbers to over 500 million accounts. This data was leaked almost for free on a hacking forum, only requiring an account and paying $2 to download it.
In 2022, threat actors exploited a Twitter API bug to link millions of phone numbers and email addresses to Twitter accounts, which were then sold on hacking forums.
Easy-to-access APIs have become a huge weakness for companies in recent years, with threat actors abusing them to access sensitive data to sell them on for profit. All of these incidents involved collection of data, they were allowed due to the ease of access to APIs and the lack of proper rate limiting for the number of requests that can be made per second from the same host.

API Vulnerability Mitigation – Best Practice
Use a Gateway
API gateways centralise traffic features and apply them to every request that hits your API. These features may be security-related, like rate limiting, blocking malicious clients, and proper logging. Or, they may be more practical and business-related, like path and headers rewriting, gathering business metrics.
Not having these controls could result in serious security vulnerabilities. Without a gateway, API providers would have to reinforce each endpoint with these features one-by-one. An API gateway eases the process of adding or fixing these features.

Always Use a Central OAuth Server
Do not let your APIs or gateways issue access or refresh tokens. A centralised Open Authorisation (OAuth) server should always issue such tokens. Issuing tokens requires many complex processes which require access to different data, such as client information or the preferred authentication mechanism. Furthermore, if many entities issue and sign tokens, it becomes increasingly challenging to manage all the credentials used for signing. Only an OAuth server can safely handle these processes.

Only Use JSON Web Tokens Internally
When APIs are concerned, using JSON Web Tokens (JWTs) as access and refresh tokens is a best practice. Services that receive JWTs can leverage claim information to make informed business decisions: Is the caller allowed to access this resource? What data can the caller retrieve?

Use Scopes for Coarse-Grained Access Control
OAuth scopes limit the capabilities of an access token. If stolen client credentials have limited scopes, an attacker will have much less power. Therefore, you should always issue tokens with limited capabilities. Verification of token scopes can be done at the API gateway to limit the malicious traffic reaching your API. You should use scopes during coarse-grained access control.

Use Controls for Fine-Grained Access Control at the API Level
You should always implement fine-grained access control at the API level. This access control complements any control done at the API gateway level, and should be architected so that even if a malicious request slips through the gateway, the API will still reject it. This practice safeguards against situations in which attackers bypass the gateway.

Trust No One
Zero-trust is not just a buzzword, your API should limit trust to incoming traffic. One of the steps toward building zero-trust is using HTTPS for all API traffic. If possible, use HTTPS internally so that traffic between services cannot be observed.
Zero-trust also means that your services should deny access by default. Then use claims-based access control to allow access to requests that satisfy access control policies.

Create or Reuse Libraries for JWT Validation
Proper JWT validation is crucial for the security of your APIs, create a company-wide solution for JWT validation. Standardising a company-wide JWT validation process will help guarantee the same level of security across all your endpoints. When issues arise, teams can resolve them more quickly.

Do Not Mix Authentication Methods
Do not mix authentication methods for the same resources. Authentication methods can have different security levels, e.g. consider basic authentication versus multi-factor authentication. If you have a resource secured with a higher level of trust, like a JWT with limited scopes, but allow access with a lower level of trust, this can lead to API abuse. In some cases, this could be a significant security risk.

Protect All APIs
Do not leave any of your APIs unprotected. Even internal APIs should have protections implemented. This way, you’re sure that the API is protected from any threat from inside your organization.

Issue JWTs for Internal Clients Inside Your Network
If you have internal clients operating only inside your network, you can have your OAuth server issue JWTs for such clients instead of opaque tokens. This will avoid unnecessary token translations. However, you should only apply this strategy if the JWTs do not leave your network. If you have external clients, or if the tokens are used externally, you should hide them behind an opaque token, as noted before.

Use JSON Web Key Sets for Key Distribution
To verify a JWT’s integrity, an API must access a public key. You can accomplish this in a couple of ways: you can hardcode the key’s value or query some endpoint at your service start-up and cache the result.
The recommended method is to obtain a key from a JSON Web Key Set (JWKS) endpoint exposed by the OAuth server. The API should cache the downloaded key to limit unnecessary traffic but should query the JWKS endpoint again whenever it finds a signing key it doesn’t know.

Always Audit
Maintaining high standards for your APIs, both from a security and design point of view, is not a trivial task. Therefore, consider splitting responsibility between different groups of people and having other teams audit your APIs.

Abuse Doesn’t Have to Be a Breach
Just because your API security isn’t breached doesn’t mean that everything is fine. You should gather metrics and log usage of your API to catch any unwanted behaviour. Watch out for requests iterating over your IDs, requests with unexpected headers or data, customers creating many clients to circumvent rate limits, and other suspicious cues. Losing data due to API abuse can be just as harmful to your business as a hacker breaking through the security.

Conclusion
Securing an API with high-standard security is paramount. As seen above, there are many technical strategies to consider. By following these suggested measures, you can help to safeguard APIs and deny unwanted behaviour.