This is the first in a three-part series on REST APIs. You can read the entire series here.
For a while now, APIs have been considered a tactical tool in driving a broader business strategy. But in the evolving digital landscape they are now being increasingly considered as the very lynchpins of core business strategies – be it for the enterprise or consumer businesses. Technologically, this spans not only the emerging spectrum of cloud, mobile applications, (*)aaS and IoT, but even traditional enterprise software like relational databases. Business-wise, everyone from hospitality, travel, content, media, health to finance and manufacturing is dabbling with APIs.
There are many dynamics at play in this space – the eclipsing of XML, RSS and Atom by JSON and of legacy SOA architectures by REST. Twitter abandoned their XML based API in favor of JSON/REST. Oracle, a traditional SOA player, has espoused REST for their big data, NOSQL, and relational database offerings. Netflix API has been optimized to overcome shortcomings in their RESTful APIs.
Traditional, website-only businesses are also jumping on the API juggernaut exploring new ways of doing business, engaging internal and external developers, driving business through affiliate partners and streamlining their own business processes. APIs, especially JSON/REST are also considered to increase business agility.
REST, as an architectural style, was designed to solve many of the complexities and “heaviness” inherent in SOA architectures. Its design goals were to be lightweight, performant, cacheful and friendly to proxies. Modern web application programming frameworks such as node.js and Angular JS have further spurred the adoption of JSON/REST with the developer community.
While “API strategy” is becoming an important business mantra, there is a gaping hole in API security. Just as an API can boost business, an API breach can bring it crashing down.
Relaxed security in legacy internal-facing SOA services is ill equipped to face the hostile environment that is the Internet. Even if security was built into the internal services it is most likely obsoleted by newer threat vectors. Further, most enterprise backend systems comprise a dizzying array of incompatible legacy and acquired technologies. Re-architecting or retro-fitting security in such backends is often not viable, especially in the face of time-to-market pressures.
Irrespective of your motivations, technology or architectural preferences, technically, APIs are just another frontend to your core backend services. Your majority user base may now be reaching you through myriad apps exercising your APIs, rather than through browsers, but the backend services and their security requirements remain the same.
The evolution of APIs has ushered new paradigms of interactions over HTTP, which traditional security technologies like SOA gateways, IPS/IDS and web application scanners struggle to deal with. As an example, the use of JSON in HTTP requests presents new conduits of untrusted data to breach backend services or user’s browsers where it is consumed. Passing user inputs within the URL path (rather than URL query) with REST is another attack vector that breaks legacy security.
Another challenge with APIs is service availability. APIs are exercised programmatically and can be extremely chatty. Unanticipated usage levels or abusive partners can wreak havoc upon the API SLAs and even bring down the backend services, with severe financial implications.
While this post was a bird’s-eye view, in our next post we will get down to a worm’s-eye view to inspect some delicious details regarding API security.