In the wake of a breach involving 37 million T-Mobile accounts, there is, for the moment, a lot more focus on application programming interface (API) security. APIs are the foundation upon which data is shared, especially in the age of the digital economy, so there are now millions of APIs being employed. Unfortunately, securing those APIs has been an afterthought that is now come to a head.
T-Mobile is reporting that while the API that was compromised provided access to customer data, customer payment card information (PCI), social security numbers/tax IDs, driver’s license or other government ID numbers, passwords/personal identification numbers (PINs) or other financial account information were not exposed. In other words, things could have been a lot worse.
The issue many organizations are encountering when it comes to API security is that it’s not always clear who is responsible for it. Developers routinely create APIs to share data. The bulks of those APIs are based on REST architecture, but other types of APIs based on, for example, GraphQL, are now gaining traction as well. The core problem is that developers that create these APIs don’t have a lot of cybersecurity expertise so there’s plenty of opportunity for mistakes to be made that enable cybercriminals to exfiltrate data.
Cybersecurity teams, alas, don’t tend to have much visibility into how these APIs are being created and deployed. As a result, all these APIs are, in effect, unsecured endpoints. Fortunately, most of these APIs are internally facing, so the immediate crux of the issue is the security of the APIs that are externally accessible. While there are fewer of these APIs, cybersecurity teams should not overlook the security of internally facing APIs. It doesn’t take much for development teams to make internal APIs accessible to external users, so what may seem secure enough today can tomorrow become a very big issue when some business unit decides to, for whatever reason, make an existing API accessible to some entity outside the company.
In theory, at least, developers are assuming more responsibility for API security as part of the general shift left of responsibility for application security via the adoption of best DevSecOps practices. However, the number of APIs that have already been created measures in the millions. There is also an untold number of “Zombie APIs” that have been abandoned by development teams that still provide access to data. It’s still generally going to be the responsibility of the cybersecurity teams to find and secure all the API endpoints that have been created.
Regardless of who in an organization is ultimately responsible for API security, it’s clear not enough attention is being paid. The same cybersecurity issues that have plagued Web applications for years also affect APIs. The problem is there are orders of magnitude more insecure APIs than there are Web applications. Cybersecurity teams today don’t have a lot of API security expertise so the probability most organizations will experience an API security issue in 2023 is, sadly, a lot higher than anyone might care to admit.
