Businesses of all sorts are increasingly relying on APIs to interact with customers in smartphone apps, but they have their own unique set of vulnerabilities.
API Security- As cyberattackers continue to take advantage of vulnerable people, processes, and technology, they are also expanding their operations beyond the usual targets. Nothing appears to be outside of their jurisdiction, and no one is 100% safe from their malicious campaigns. Although organizations are making progress in protecting themselves, as soon as one attack vector is thwarted, another quickly becomes exposed.
Today’s adversaries are focusing on APIs in particular, which are quickly becoming the new attack frontier. Recent reports suggest that by 2022, API abuses will be the vector most responsible for data breaches within enterprise web applications. This is primarily due to the extensive growth of API implementations worldwide, providing a new target that hasn’t been widely exploited yet. With this, protecting APIs is becoming more important.
Although the concepts of API security are somewhat new, the attacks that can be performed through them are not. Most organizations have been experiencing similar threats targeting their networks and Internet-facing applications for years. Now, they must focus their efforts on mobile apps, APIs, and back-end servers being targeted by similar methods as seen in the past. Before discussing the risks associated with today’s APIs, we must first understand exactly what makes them unique and vulnerable.
API-Based Apps vs. Traditional Apps
API-based apps are significantly different from traditional applications. In the past, users/visitors would access a web server via a browser, for example, and most of the “data processing” was performed on the server itself. As client devices became more varied and increasingly powerful — with faster CPUs, extensive memory, more bandwidth, etc. — much of the logic moved away from being performed on back-end servers to the front end (that is, on the client device itself) as highlighted in the graphic below.
In the modern application at the bottom of this graphic, the downstream server acts more like a proxy for the data consumed by the API-based app. The rendering component in this instance is the client that consumes the raw data, not the server itself.
Many will remember the early days of using smartphones and traditional websites when trying to reserve a flight, for example. People would open a browser on their phone and attempt to use an airline website that was designed for a large computer monitor, not a small smartphone screen. This didn’t work too well, and companies began to update their websites by making them more smartphone-friendly. Although this improved the customer experience, navigating a website and completing an airline reservation was still quite cumbersome.