The application programming interface (API) is an unsung hero of the digital revolution. It provides the glue that sticks together diverse software components in order to create new user experiences. But in providing a direct path to back-end databases, APIs are also an attractive target for threat actors. It doesn’t help that they have exploded in number over recent years, leading many deployments to go undocumented and unsecured.
According to one recent study, 94% of global organizations have experienced API security problems in production over the past year with nearly a fifth (17%) suffering an API-related breach. It’s time to gain visibility and control of these digital building blocks.
How bad are API threats?
APIs are key to the composable enterprise: a Gartner concept in which organizations are encouraged to break their applications down into packaged business capabilities (PBCs). The idea is that assembling these smaller components in various ways enables enterprises to move more nimbly at greater speed – creating new functionality and experiences in response to rapidly evolving business needs. APIs are a critical component of PBCs whose use has surged of late with the increased adoption of microservices architectures.
Nearly all (97%) global IT leaders therefore now agree that successfully executing an API strategy is vital to future revenue and growth. But increasingly the sheer volume of APIs and their distribution across multiple architectures and teams is a source of concern. There may be tens or even hundreds of thousands of customer- and partner-facing APIs in a large enterprise. Even mid-sized organizations may be running thousands.
What is the impact on firms?
The threats are also far from theoretical. This year alone we’ve seen:
- T-Mobile USA admit that 37 million customers had their personal and account information accessed by a malicious actor via an API
- Misconfigured Open Authorization (OAuth) implementations on Booking.com which could have enabled serious user account takeover attacks on the site
It’s not just corporate reputation and the bottom line that’s at risk from API threats. They can also hold up important business projects. More than half (59%) of organizations claim that they’ve had to slow down the rollout of new apps because of API security concerns. That’s part of the reason why it is now a C-level discussion topic for half of boards.
Top three API risks
There are dozens of ways hackers can exploit an API, but OWASP is the go-to resource for those wanting to understand the biggest threats to their organization. Its OWASP API Security Top 10 2023 list details the following three main security risks:
- Broken Object Level Authorization (BOLA): API fails to verify whether a requester should have access to an object. This can lead to data theft, modification or deletion. Attackers need only be aware that the problem exists – no code hacks or stolen passwords are needed to exploit BOLA.
- Broken Authentication: Missing and/or mis-implemented authentication protections. API authentication can be “complex and confusing” for many developers, who may have misconceptions about how to implement it, OWASP warns. The authentication mechanism itself is also exposed to anyone, making it an attractive target. API endpoints responsible for authentication must be treated differently from others, with enhanced protection. And any authentication mechanism used must be appropriate to the relevant attack vector.
- Broken Object Property Level Authorization (BOPLA): Attackers are able to read or change the values of object properties they are not supposed to access. API endpoints are vulnerable if they expose the properties of an object that are considered sensitive (“excessive data exposure”); or if they allow a user to change, add/or delete the value of a sensitive object's property (“mass assignment”). Unauthorized access could result in data disclosure to unauthorized parties, data loss, or data manipulation.
It’s also important to remember that these vulnerabilities are not mutually exclusive. Some of the worst API-based data breaches have been caused by a combination of exploits such as BOLA and excessive data exposure.
How to mitigate API threats
Given what’s at stake, it’s vital that you build security into any API strategy from the start. That means understanding where all your APIs are, and layering up tools and techniques to manage endpoint authentication, secure network communication, mitigate common bugs and tackle the threat of bad bots.
Here are a few places to start:
- Improve API governance by following an API-centric app development model which allows you to gain visibility and control. In so doing, you’ll shift security left to apply controls early on in the software development lifecycle and automate them in the CI/CD pipeline
- Use API discovery tools to eliminate the number of shadow APIs already in the organization and understand where APIs are and if they contain vulnerabilities
- Deploy an API gateway which accepts client requests and routes them to the right backend services. This management tool will help you authenticate, control, monitor and secure API traffic
- Add a web application firewall (WAF) to enhance the security of your gateway, blocking malicious traffic including DDoS and exploitation attempts
- Encrypt all data (i.e., via TLS) travelling through APIs, so it can’t be intercepted in man-in-the-middle attacks
- Use OAuth for controlling API access to resources like websites without exposing user credentials
- Apply rate limiting to restrict how often your API can be called. This will mitigate the threat from DDoS attacks and other unwanted spikes
- Use a monitoring tool to log all security events and flag suspicious activity
- Consider a zero trust approach which posits that no users, assets or resources inside the perimeter can be trusted. Instead, you will need to demand proof of authentication and authorization for every operation
Digital transformation is the fuel powering sustainable growth for the modern enterprise. That puts APIs front and center of any new development project. They must be rigorously documented, developed with secure-by-design principles and protected in production with a multi-layered approach.