The modern IT landscape is API-driven. We expect the same functionality and data to be accessible from any device. At the same time, once you make APIs publicly available, they are immediately subject to a variety of attacks. Securing APIs individually is a difficult, time-consuming endeavor, and runs the additional risk of inconsistent security between APIs. Moreover, it hampers your ability to adapt your security posture to defend against emerging threats. This is where an API gateway becomes a valuable tool in API defense. This article will discuss how to protect your APIs using webMethods API Gateway policies.
Attack vectors
API attackers will use a variety of vectors, depending on the intent of the attack. Do they simply want to render your API inaccessible? They may use the classic DDOS - distributed denial of service attack. They could also overload your API with a massively oversized payload, or perhaps send a too-deeply nested JSON or XML document. Maybe they just want to scrape your data for resale or, even better, just encrypt it? Then they might inject SQL to breach your database. Or they may embed some sort of virus or ransomware in the request payload.
Of course, we also have to contend with the classics, like the old Man-in-the-Middle and request sniffing attacks. Sometimes, the attack may not even look like an attack. Consider an API that takes a record identifier as input. A hacker may be able to breach your data by simply incrementing the record identifier in a looping call, thanks to insufficient authorization checks. Pagination attacks are also becoming more common, where a hacker repeatedly calls an API that returns lists of data and pages through them, essentially harvesting information that can later be used for targeted spear-phishing or social engineering attacks.
On top of all the known threats we have to contend with, there are new threats constantly emerging. Attackers are constantly working to find new methods to bypass your existing defenses. So, your API security implementation approach needs to be agile enough to rapidly detect and counteract new threats as they arise.
API Gateway to the rescue
The first step is to force your API clients to access your APIs strictly through the gateway. This is easily accomplished by configuring your firewall to only allow access to your API endpoints from your gateway or gateway cluster. Forcing all API calls to come through the gateway provides a consistent security layer across APIs, along with centralized monitoring. So, let’s take a deeper look at the types of defenses the webMethods API gateway can offer you.
API Gateway policies
Threat protection policies form the primary defense layer of the webMethods API Gateway. Requests are assessed by these policies prior to accessing the API itself. Threat protection policies are configured at the Gateway level and can be used to protect any APIs defined on the gateway. Let’s take a closer look at the available policies.
Global Denial of Service
First up is the Global Denial of Service policy, which is used to block access to APIs for some time if too many requests flood the API. This policy triggers when more requests than the specified maximum are received within the configured number of seconds, or when the maximum requests in-progress limit is exceeded. This policy then blocks all requests for a configurable number of minutes. Optionally, you can specify a list of trusted IP addresses; requests from these IPs will not be blocked. Bear in mind that this policy applies to the Gateway as a whole, so the configured limits should support expected transaction volumes across all APIs.
Denial of Service by IP
Next up is the Denial of Service by IP policy. Similar to the global DoS policy, this policy applies across all APIs. On the other hand, the source IP is also considered. So, this policy only triggers when the request limits are exceeded from a single source IP address. This policy also has the additional option to either block requests from that IP for a time, or to automatically add it to the Denied IPs list. While you cannot manually add addresses to the Denied IPs list, you can remove addresses from the list to allow them again. Like with its global counterpart, you can also configure a list of trusted IP addresses, which will bypass this policy.
Rules
The last set of available Threat Protection Policies are known as Rules. Rules are applied in order from top to bottom, and the order is customizable. You can apply a rule to all request types, or you can specify either REST, SOAP, invoke, or a list of custom resource paths. These last 2 options are more applicable to on-premises or private cloud deployments. Each rule has a set of filters, and, if a request matches any of the configured filters, the rule is considered to have been violated, triggering an alert and optionally denying the request. Rules can filter based on the following criteria:
- Message size in MB
- Missing OAUTH header
- Device type and mobile application name
- Presence of either generic or DB-specific SQL in the payload
- Detection of malware by an external virus scanner
- JSON payload attributes (object count, container depth, max array size, and length of object names or values)
- XML Payload attributes (namespaces per element, child count, attributes per element, node depth, and the lengths of attribute names or values, element names, text, comments, processing instruction target, and processing instruction data)
- Custom filter, which filters based on the response of an IS service
Additional security
Of course, there are limits to what the API Gateway can do on its own. That’s why we have partnered with some specialized security solution providers. These solutions can do things like analyze traffic patterns using artificial intelligence to detect attacks such as data scraping. The analyzed traffic information can then be used to trigger actions in, for example, a ticketing system, and fed back into the gateway for creating or updating your security policies.
Some also can receive data form other sources, such as DNS servers or firewalls, to detect what we call shadow APIs. These are APIs that may have been deployed outside of your primary IT organization or even simply forgotten about. This detection then allows you to bring them under the protection of your gateway. For these types of specialized defenses, we have partnered with some well-known companies in the security space, like Cequence Security, No-Name Security and SALT. You can visit these links for more information on their offerings.
Cequence Blog: What are you doing about API security? | Software AG
Noname Blog: APIs under attack: upgrade your security now | Software AG
Salt Blog: API security: Shield your APIs from attackers | Software AG
More to learn
If you would like to learn more about threat protection policies, our YouTube channel has a walkthrough of the policy types and there is also an on-demand webinar for an even deeper dive and demo of these policies in action. If you’d like to try out our API Gateway on your own, sign up for a fully functional free trial. See for yourself why Software AG has been named a Leader in the 2022 Gartner® Magic Quadrant™ for Full Life Cycle API Management for the fifth consecutive year.