Application Programming Interfaces (APIs) are the building blocks upon which many of the digital products and services we now consume are based. They have all but superseded web applications; however, their very popularity has proven to be a magnet to attackers. APIs are rapidly becoming the number one target for malicious use, with Gartner predicting that this year will see API attacks become the most frequent attack vector. So, what are businesses doing to protect themselves and is it sufficient?
APIs are prime targets for automated attacks and business logic abuse because they enable high speed communication to back-end systems, which means they provide fast track access to systems and data. Research carried out by Cequence between June to December 2021 showed the exposure of sensitive data such as payment card or Personally Identifiable Information (PII) had increased by 87% compared to the previous year.
Recognizing that APIs can provide rich pickings, many attackers are now upping their game and looking for APIs with coding errors like weak authentication or non-conformance with specifications that in turn enable data theft, or system compromise. Issues with the code may not have been picked up during development due to the rush to deploy the API or perhaps older versions have persisted on the network as new APIs were spun-up, creating so-called zombie or shadow APIs.
One of the biggest problems is knowing just how many APIs are in play, as few organizations keep an accurate inventory. This on top of the fact that APIs make it easier to execute automated attacks are key reasons why APIs are top of mind for any CxO. Traditional security offerings like web application firewalls and/or API gateways provide some level of protection, but lack the in-depth capabilities to detect, analyze and protect the continuous deployment of APIs.
Web application firewalls
Web application firewalls are engineered to monitor, filter and block malicious activity by looking at signatures within web traffic. They’re used to detect known vulnerabilities as described in the OWASP Web Application Top 10 Threats list and are great for preventing SQL injection, cross site scripting attack or remote code execution, for example, or to address PCI DSS section 6.6 requirements.
But if we look at the OWASP API Security Top 10 Threats, it’s a different story. These aren’t signature-based and include issues with the code itself, from broken object level authorization/user authentication/function level authorization to improperly implemented rate limiting, mass assignment and misconfiguration, to name but a few. In fact, the only cross-over are injection attacks. Moreover, because web application firewalls tend to be used to monitor specific systems such as CMS, their focus is narrow. They struggle to find and block attacks that to all intents and purposes appear legitimate.
API Gateways are designed to help organizations aggregate and manage APIs providing access control and basic security functions such as HTTPS termination, rate limiting and IP block lists. They are reactive in nature, requiring developers to register the APIs to be managed and are often deployed within the infrastructure, at a department level, or in a cloud environment. While they can help improve security between internal services, they have also been criticized because they create a single point of entry to the APIs and therefore a single point of failure.
While both provide some level of protection, they fail to meet many API security requirements. But there are steps you can take to significantly improve protection. Firstly, visibility is key. What you can’t see, you can’t secure, so conducting an inventory of public and internal APIs and keeping it up to date through continuous tracking is a must. You should also assess your risk and determine if your APIs have sensitive data handling or authentication coding errors and validate conformance to the API specification in use.
Thirdly, it is necessary to detect threats hiding in plain sight. Automated detection that utilizes machine learning and acts on threat intelligence on behaviors and malicious IP addresses etc. can enable the business to fight fire with fire.
Finally, we want to be able to respond at computing speed to prevent the attacker from scraping endpoints of sensitive data. So when selecting a vendor, ask if response options include blocking, rate limiting, geofencing, forwarding, and deception. That last point is particularly useful as it can be used to convince the attacker that they have been successful, deflecting the attack or at least delaying it.
To conclude, it’s important to note that both web application firewalls and API gateways can confer some level of protection on APIs but organization should be mindful of their limitations. Supplementing this provision with a runtime inventory, risk assessment, policy enforcement, threat detection and prevention can substantially improve security and help protect APIs against the barrage of persistent attacks they are increasingly being subjected to.