There’s no way around it -- 2020 was the year of digital transformation. Recent research from IDC shows that spending on digital transformation was poised to grow by 10.4% in 2020 and reach $1.3 trillion, as organizations from every industry began to realize that the benefits of a digital operation are simply too compelling to ignore.
Application Programming Interfaces (APIs) are one of the major enablers of digital transformation. These innovative software tools speed up the development process by empowering developers to quickly add both internal (microservices) and external (3rd party) capabilities to their products using a simple set of commands. According to Akamai, API traffic accounts for an astounding 83% of web traffic these days.
But not everything is rainbows in the world of APIs. Hackers have jumped on the API bandwagon, using them as a gateway to penetrate apps and steal sensitive information. In fact, 2019 saw one in five organizations reporting daily API attacks in the form of access violation and denial of service attacks.
The tools of the trade
To meet this challenge, enterprises implement a variety of tools that provide security measures for APIs. These tools support various security-oriented efforts, ranging from gaining knowledge of the APIs delivered and consumed through inventorying, through managing access and permissions, to providing various threat protections to detect and block attacks.
The cornerstones of API security are API Gateways and Identity Access Management (IAM) tools. Used to manage an organization’s APIs, API Gateways are essentially the point of entry for API requests. They generally use API key creation and management to block APIs from malicious data requests and other improper requests, as well as Denial of Service attacks. Access management is often used by admin teams to designate login and authorization policies that limit OAuth scope to certain devices, specific networks or group membership.
Common API security approaches
While it may be hard to believe, perhaps the most common way API security is dealt with today is by doing nothing. Unfortunately, some organizations take a ‘security through obscurity’ approach to API security, falsely believing that as APIs are uncrawlable and that hackers are unaware of their existence. The reality is that it takes an experienced developer just a few minutes to verify APIs within an app and understand which data it’s using.
Static and dynamic security checks focus on the message data sent via the API. Static security checks validate against predefined rules so that message data that doesn’t conform is blocked. Dynamic security checks focus more on changing variables like number of call requests and access token validation.
Authentication and authorization are two distinct approaches that focus on the identity and privileges to ensure security. Authentication identifies each unique user by using security technology like JWT, OAuth 2.0 and certificates. Authorization ensures that only users with specific predefined access rights can log in to use different resources within an app.
Quotas and throttling limit the number and rate of calls for an API. These methods secure APIs from spikes and Denial-of-Service attacks while ensuring that attackers cannot access unlimited data should they succeed in penetrating the API.
Web Application Firewalls (WAFs) are used in conjunction with other security measures to provide a holistic defense against a wide spectrum of attacks. By filtering and monitoring HTTP traffic and ingesting the API schema (see next bullet), WAFs can validate and enforce routine traffic and support threat protection through detection of various malicious actions, such as SQL injections.
Swagger files are machine-readable interface files that map out an API’s inner workings in great detail. They provide a myriad of security measures including the removal of obsolete functions, clarity of data return/exposure and authentication requirements. They also enable auditing and automated analysis.
Business logic -- the missing link
These approaches are like pieces of a puzzle, that even if you combine all and get the best of their advantages, they still provide general protection rather than individual, API-specific protection. This means that their protective measures hardly adapt according to the API, yet function in a similar manner regardless of the specific API they’re protecting. This general approach may safeguard some of attacks, but unfortunately they still leave cracks in the defences.
They all guard who can access, but provide very limited protection against what the user does while inside. APIs, having a specific business logic and purpose, are particularly vulnerable to functionality attacks targeting bugs in the expected usage of the endpoints.