API usage in application development has become the trend of the year. Adoption of micro-services and server-less architectures have only accelerated this trend. Based on conversations with analysts and customers, we expect APIs to become the majority of web application front ends in next couple of years.
Due to increased public exposure and common API front end usage, APIs have become a new attack vector for cybercriminals and can make your applications and databases vulnerable to the full range of web application attacks.
With this rapid growth and increased risk, API security has become a topic of interest to developers and security professionals alike. While some API security challenges aren’t drastically different from traditional application security challenges, others are unique. Either way, mitigation approaches can vary and a web application firewall (WAF) needs to understand and address API nuances.
In this post, I discuss six common API security challenges and the necessary features a WAF should have to mitigate each.
One of the most common exploit methods used by hackers is to probe into application security defenses by tampering with input parameters (fields). With APIs, such tampering could be used to reverse engineer an API, cause a DDoS attack or simply expose a poorly written API to reveal more data.
You can protect against such attempts with a WAF capable of profiling APIs and checking any API call against the profiled API structure to ensure the input parameters (count, order, etc.) are consistent with the definition. Unlike apps, one can automatically build API profiles from a known schema without the need to learn over a period of time. Imperva SecureSphere WAF for example has a proprietary JSON structure and set of APIs that allow profiles to be easily created from popular definitions (see Figure 1).
_Figure 1: Imperva SecureSphere WAF automatically builds API profiles _
Netflix recently ran an experiment where they brought down a third of their network by DDoS-ing their key APIs using bots. API-fronted web applications are exposed to bot and DDoS abuse – a poorly written API could use up a lot of compute resources if it starts receiving invalid inputs. In general, a DDoS attack can cause quite a disruption to API-fronted web applications.
You can protect against such attacks with the effective use of rate limiting and malicious IP blocking along with anti-scraping policies. These policies when used along with API profiling provide robust protection for your APIs.
Attacks can attempt to tamper with cookies to either bypass security or to send false data to application servers. While session cookie tampering is a well-known channel for attacking traditional web applications, it is equally relevant for APIs.
A WAF should offer session cookie protection that extends to APIs as well and the ability for users to simply apply the same policies to an API.
An unencrypted connection between the API client and the API server can expose a lot of sensitive data to hackers. Since APIs are becoming a preferred vehicle for data exchange with the easy to use JSON format, an unsecured transmission is an open invitation for data theft.
Ensure your WAF can be configured to only allow HTTPS traffic, enforce transport layer security (TLS) versions and allow specific ciphers from the API client to API servers (Figure 2).
Figure 2: Enforcing SSL/TLS to stop man in the middle attacks
It’s possible for attackers to simply inject malicious content that could lead to exploits. Such technical attacks could include poisoning of JSON web tokens, attempts to light up traditional SQL injection or getting a malicious JS code to execute behind the scenes amongst many others.
A WAF which has multiple signatures to block such attacks is required. But the added ability to whitelist certain IPs, ports or content from well-known sources is a must-have to avoid false positives.
Most internet of things (IoT) devices are designed to communicate to their corresponding enterprise servers using the API channel. This allows stability and versioned definition of their operations. These IoT devices in some cases authenticate themselves at the API server using client certificates. If a hacker gets control over an API from the IoT endpoint, they could easily resequence the order of APIs and cause data leaks or undesired operations.
To protect against this threat, look for a WAF that can model API user behavior based on an authentication parameter. For an IoT device, the ability to model API behavior based on client certificates allows a security expert to quickly identify the proper and improper usage emanating from such devices.
You don’t want to tie the hands of DevOps, whose mission is to innovate, create and release code in a timely manner. But you also can’t overlook the risks of unsecured APIs used to develop apps. A WAF deployed in front of API resources protects core applications by validating and monitoring API traffic.
Contact us to learn more about API security from Imperva and see a demo of our WAF solutions.