Are your APIs really secure? Are you sure?
Authors: D. Fett and Dima Postnikov.
We have noticed a recurring confusion in many industry discussions recently. Various participants seem to make statements about the level of security of their APIs, and they often base it on assumptions that have nothing to do with security of their APIs. This prompted us to write a short article in an attempt to clarify some of the confusion.
Let’s have a look at some of these statements:
“My APIs have been live for a long time. They must be secure, right?”
If you currently have APIs in production, it doesn’t mean they are secure. There are a lot of insecure APIs in the industry, especially in custom point-to-point integrations.
Here is just one example: The APIsecurity.io newsletter, one of many similar sources, mentions one or more API vulnerabilities each week. Your organisation might have been lucky until now if it didn’t get the attention of numerous threat actors, but this cannot be considered as a protection for future attacks.
If an API security specification is older than a year or so then it most likely doesn’t follow the latest best practices. Just like web security, API security is a constantly evolving space, with input both from practice and academic research. OWASP has launched the API Security Top 10 project to highlight some of the vulnerabilities found in insecure API implementations.
“My data is encrypted at-rest and in-transit. My APIs are secure, right?”
If your data is encrypted at-rest and in-transit, it doesn’t mean your APIs exposing this data are secure. Your data can be encrypted at rest and in transit and without API authentication, it can still be exposed to anyone.
In other words, the threats against which encryption and proper API authentication/authorization protect are very different and both have to be covered in your design and testing.
“I have SOC2 certification. This means my APIs are secure, right?”
If you have security certification like SOC or PCI-DSS, it doesn’t mean your APIs are secure. These certifications focus on other important controls and processes that don’t cover API security.
“Is my system more secure if I don’t use APIs at all?”
NO is a very simple answer here.
If you don’t use APIs for integration, it is hard to consistently enforce authentication and authorization, hard to achieve reasonable levels of security, traceability, data minimisation, privacy and customer control. A clean API architecture decouples authentication and authorization, which allows, for example, timely updates to authentication and authorization policies to react to new vulnerabilities and to adapt to new regulatory requirements.
“We use OAuth standards. This guarantees API security, right?”
If you use OAuth, it doesn’t mean that your APIs are secure. These are broad specifications that need to be profiled to be secure. Have a look at how many revisions OAuth 2.0 Security Best Current Practice document got in the last couple of years: Do you understand these documents and the threats they describe and do you keep your implementation up-to-date?
Many vulnerabilities in OAuth and OpenID Connect implementations can be traced back to the same root causes, for example:
- Insufficient checking of redirect URIs, enabling an attacker to learn authorization codes and access tokens.
- The use of symmetric credentials (like API keys or client secrets) when these get exposed in data breaches.
- Insufficient use and checking of security parameters, often caused by home-grown implementations.
- The lack of a second layer of defence: If any of the aforementioned vulnerabilities is exploited, a binding of authorization codes and access tokens to a specific client can help to prevent replay attacks, for example, using PKCE, mTLS, and DPoP.
Why is it important now?
According to Akamai, API traffic accounts for at least 83% of web traffic in 2019. API usage will grow significantly in the future because of increasing numbers of:
- Enterprises and government agencies that integrate with each other via APIs as a part of their digital transformation agenda.
- Compliance projects like open banking, open finance, and open data that force companies (often with no API integration experience) to expose APIs.
- Web applications and native apps moving to API-based architectures.
It’s great that there is a lot of focus on new APIs and their security. The unfortunate reality of the API industry is that a large number of APIs are live already with custom or no security profile at all. A lot of organizations don’t have full visibility of what APIs they are exposing.
And it’s not a secret anymore. Gartner predicts that by 2022, application programming interface (API) attacks will become the most-frequent attack vector, causing data breaches for enterprise web applications. Already, many well-publicized API security vulnerabilities affected a wide range of organizations.” Salt Security’s State of API Security Report found that “the amount of attack traffic targeting APIs is growing more than three times faster than the rate of regular API traffic” (Computing article).
So what do we do?
The main takeaway from this article is that making APIs secure requires more than just making sure that you use OAuth, certifying SOC2 or encrypting your data in-transit.
Creating a secure API ecosystem requires an end-to-end profile that covers responsibilities of all participants, on-boarding and off-boarding, all interactions between all participants and an end-to-end threat model.
FAPI, the Financial-grade API Security Profile, is a profile for OAuth 2.0 and OpenID Connect that implements state-of-the-art security best practices with multiple layers of defence. You don’t have to use FAPI as your API security profile, but if you choose to use a custom profile, you need to build a threat / attacker model and show that your profile is secure against these threats.
This is not easy and far from quick. Research (for example, this paper on an older version of FAPI) has shown that attacks can be subtle and easily be overlooked, even by experts.
Besides the security benefits, a standardized profile ensures you can use existing, battle-proven implementations (libraries, client and server software) to save money and time, and to avoid the security risks associated with custom implementations.
