APIs form the chassis for modern applications. They enable developers to obtain valuable information from other software components and integrate it into their applications – for example embedding Google Maps in a rideshare app or YouTube videos in a web page.
In fact, APIs are now key components at every stage of a user’s interaction with an app, from logging in to leaving feedback.
Nowadays, real time API responsiveness – which we define as processing an API call end-to-end in under 30ms – is becoming business-critical. The rise of 5G is only likely to make the need for speed even more essential.
Like all things created with good intentions, the prominent use of APIs has its downside – it provides bad actors motivated by bad intentions with a new avenue for exploiting applications. As a case in point, Gartner recently predicted that, by 2022, API abuses will be the most frequent attack vector against enterprise web applications.
Why are cyber criminals interested in APIs?
There are many reasons APIs are such rich targets for security attacks. One of the biggest problems is failure to set appropriate access permissions. Because they are not intended for direct access by users, APIs are often granted access to all data within the application environment. Access is then controlled by granting specific permissions to the users making the initial requests that are translated into API calls, and having the API inherit only those permissions. This works fine until an attacker manages to bypass the user authentication process and access the downstream app directly via the API. Because the API has unrestricted access, the attacker gets visibility into everything.
Like basic HTTP web requests, API calls incorporate URIs, methods, headers, and other parameters. All of these can be abused in an attack. Unfortunately, most typical web attacks, such as injection, credential brute force, parameter tampering, and session snooping work surprisingly well on APIs.
How can businesses secure their APIs
During the design and development stages, engineers need to build in the logic required for integrating with all the tools that will secure the API as it’s delivered in development, testing, and production environments. They then need to deploy those technologies to protect the API during delivery. This should include:
- Web Application Firewalls. A WAF recognizes requests that are in fact illegitimate, designed not to exercise the API’s intended functionality but to exploit vulnerabilities in application code that allow attackers to steal information or execute malicious code. At the very least, it is crucial that any WAF protects against the most common attack types.
If possible it is worth exploring a solution like NGINX App Protect. Optimized for CI/CD and DevOps workflows, it supports XML, JSON, text, and HTML request and response payloads. Its advanced API protection profiles protect against attacks with parsing and structure enforcement, attack signatures, method enforcement, and path enforcement.
- Bot protection. HTTP APIs can be subject to bot and other forms of malicious or unwanted automation based traffic.
- API Management. Among other functions, API management solutions provide the interface for defining security policies which the API gateway then applies as it processes API calls.
- API Gateway. An API gateway will secure API calls for the following key functions:
- Authentication and Authorization. Authentication is the process of verifying user identity. Authorization is what comes next – determining which actions a particular user is entitled to perform and conveying that information to the server.
API authentication is about allowing access only to recognized clients – those that can prove they are who they claim to be. Because authentication is not core to what an API does, it makes sense to perform it outside the application code. This frees API developers from having to write their own authentication code and means you can centrally manage authentication for all APIs while still making authentication requirements flexible. For example, you might allow unauthenticated use of the API that returns game scores at a sports website, but you definitely need to authenticate the people who use an API to edit the content.
- Rate Limits. Rate limits control how frequently a given client can make an API call. They have two main purposes: protecting backend services from being overloaded and ensuring fair use for clients. An example of rate limiting might be to allow 100 transactions per second during periods of heavy demand. Rate limits can be applied to individual usernames, specific IP addresses or ranges, or to all users (for example, during peak traffic times).
- Input Validation. Input validation is verifying that input supplied by a user or application is correct: consists of the right type of characters (digits, letters, punctuation), is the right size, is one of a predefined set of acceptable values, is consistent with another value being provided, and so on. For example, you might check that the zip code matches the supplied address, or that a birthdate is not in the future. Input validation prevents improperly formed data from entering an information system and threatening its integrity. It’s also an important way to detect malicious users, who can then be blocked from making further requests.
APIs are clearly becoming a strategic necessity for unlocking the speed and agility required in today’s business environment. However, as the costs of security breaches continue to rise, all organizations must ensure that exposing their data via APIs does not create unnecessary security risks. Those that drop the ball in this respect are more likely than not to take some big financial (and reputational) hits.
Rajiv Kapoor, Senior NGINX Product Marketing Manager, F5