• 
The first article in this series (API Security, Part 1) discussed some of the challenges in protecting APIs from hostile traffic, and gave an overview of Curiefense’s approach. The second article (API Security, Part 2) discussed these security mechanisms:
In this third and final article, we’ll discuss these additional mechanisms:
Most APIs have a natural, organic flow to them. For legitimate users, there will usually be some calls that occur early in a session, then others will occur afterwards. Many calls will have a specific sequence to them.
For example, a mobile app might begin with a lot of GET calls, as it initializes and retrieves data. Then once initialization is complete, it might send a POST call containing the user’s login details.
Often, attackers will not follow this sequence. For example, a hostile bot might attempt an ATO (account takeover) by jumping straight into a series of POST calls as part of a credential stuffing attack.
Curiefense can block out-of-sequence calls to an API. The screenshot above shows an example that will not permit a POST call unless it was preceded by a GET to /login.html, followed by a GET to /static/login-form.js.
In a later release, Curiefense will not only allow admins to define flow control sequences, it will also analyze past behavior and recommend new sequences for enforcement.
Curiefense has optional modules that use Machine Learning (ML) and UEBA (User and Entity Behavioral Analytics) to learn behavioral patterns and other biometric characteristics of legitimate users. Attempts at anomalous usage can be blocked, or merely flagged for monitoring.
After an initial period of learning and accumulation of usage data/metrics, Curiefense’s ML-based UEBA can detect complex, application-specific attacks: everything from inventory denial attacks on travel and ecommerce applications to SMS spam being sent through telecom APIs.
Curiefense admins can set up security policies that define acceptable content for API calls (their headers, payloads, etc.).
These policies are flexible. Admins can ban calls with defined characteristics, or allow calls with defined characteristics, or require calls to have defined characteristics, or any combination of the above across an API.
Content filtering can be used for API schema enforcement. In the current version of Curiefense, partial semantic schema validation is available by creating PCRE definitions for parameter properties.
A later release of Curiefense will offer full validation via cloud functions: custom Lua code that can be executed during processing.
Many traditional security solutions offer bot management only as an add-on module, if it is available at all. We believe this is unfortunate, because almost all web attacks today involve bot activity in one form or another.
So, when designing Curiefense, we wanted bot management and hostile bot detection to be inherent capabilities of the platform.
Curiefense allows users to exempt specific bots (e.g., search engine spiders) from filtering if desired. It also includes features for detecting hostile automated traffic, such as consumption of data feeds containing geolocations and IPs known to be used by malicious bots.
One of our design goals was to provide human detection that doesn’t require users to do anything (like solving a CAPTCHA puzzle, for example). As a result, Curiefense includes challenge mechanisms to invisibly recognize bots which are using headless browsers or emulators, and they take only a few milliseconds to accomplish at the beginning of a session.
Behavioral profiling and API abuse prevention (which were described earlier) also play a large role in bot detection, since most attacks today involve bots to varying degrees.
Along with everything else described so far, Curiefense includes—of course!—a WAF.
This defends against injection attempts (of SQL, code, and commands), XSS, out-of-limit arguments, malicious payloads, protocol exploits, cookie and session poisoning, and more. Basically, everything that a WAF should defend against.
Out of the box, Curiefense includes an extensive database of threat signatures. In addition to this, users can also construct custom API filters to allow or block requests based on their content (as described earlier), and then assign these filters to various scopes (from globally across the API down to specific destination endpoints).
Automation features include regular updates to the threat signature database, and a default security profile that protects every path/endpoint which hasn’t been explicitly configured.
More info: the Curiefense WAF.
API security is simultaneously one of the most challenging and most important tasks in cybersecurity today. Today’s threat environment includes a wide variety of methods for compromising systems via their APIs; meanwhile, legacy security solutions often rely on techniques (such as browser environment identification) which are not applicable to APIs.
We designed Curiefense from the ground up to provide APIs with robust protection. It offers the same range of security technologies to services and microservices as it does to sites and apps, and it offers additional API-specific mechanisms as well.
We believe that Curiefense already offers API security that is at least equal to, and often better than, most solutions available today. However, we aren’t done yet; as mentioned above, there are more features coming.
Please feel free to send us your ideas, feedback, and feature requests. We’d love to hear from you!
