Reblaze does not limit its traffic analysis to the user environment and client session. It also performs extensive, continual analysis of the user’s behavior.

Every HTTP request that Reblaze receives is anonymized and then analyzed according to numerous factors, including (partial list):

• Device and software data (the user’s hardware, its screen resolution and orientation, the software used, battery level, stack trace, fronts and extensions, emulator detection, window size, hidden iframes, etc.)

• User interface and events (mouse/pointer movements, clicks, taps, zooms, scrolls, keystrokes, speed of entry, etc.)

• Session data (requests sent, IPs used, timing, frequency, etc.)

• Consumption analytics (pages viewed, time spent, resources requested, etc.)

• Application-specific events (and other results of user actions.)

Reblaze understands the patterns, typical values, and common relationships of these metrics for legitimate users of each protected application and API. The amount of data that Reblaze processes (over four billion requests per day) is far beyond the capability of human analysts. Therefore, cloud-based compute resources are used, applying Machine Learning in order to recognize patterns that analysts could not have identified on their own, or for which they might not have thought to look.

Reblaze performs this analysis to an extremely granular level: not only per app, but even down to individual pages, screens, and so on. This reveals patterns of behavior unique to that particular context.

Reblaze continually analyzes the activities and behaviors of every requestor in every session. By definition, every hostile user (whether human or bot), must, at some point, deviate from the behavior of a legitimate user. As soon as this occurs, Reblaze blocks that requestor.

Using this approach, Reblaze’s bot detection accuracy is not only high, it is also robust and resistant to reverse-engineering by threat actors. Behavioral profiles are constructed based on private analytics data, and threat actors have no realistic way of obtaining this information.

For mobile/native applications, Reblaze authenticates the client itself and all communication with it.

At Reblaze, we provide an SDK (for both Android and iOS) to our customers, who rebuild and publish their applications with the SDK embedded. In use, it signs the application, authenticates the device, and verifies user identity.

All communications occur over TLS and include an HMAC signature (a cryptographic identity mechanism on the client side) to harden communications between the mobile/native application and the microservice/API endpoint. The signatures are non-reproducible, non-guessable, non-repeating (they are unique per session and per request), and are based on dozens of parameters (time-based, location-based, environment-based, and more). They provide a reliable, secure mechanism to verify that the packets are originating from a legitimate user, and not from an emulator or other bot.

Instructions and code samples for the Reblaze Mobile SDK are available here:

Most hostile bot activity involves headless browsers and mobile phone emulators. To detect these bots, most web security solutions rely on Javascript injection to detect the browser environment.

Unfortunately, these detection methods have become increasingly ineffective. The latest generations of bots use sophisticated software stacks, and they are able to masquerade as humans using normal browser environments.

To identify hostile bots, the Reblaze platform uses a variety of methods, collectively known as Reblaze Client Side Inspection (RCSI). Although Javascript plays a role within it, RCSI as a whole is unlike any other Javascript challenge in use today. RCSI is effective for protecting web applications, services/APIs, and mobile/native applications. (Some of the implementation details differ, depending on the context.)

RCSI detects bots via a multi-layered approach, described on the following pages:

When a new user session is initiated, RCSI detects and verifies the authenticity of the environment.

1. The user’s browser is subjected to several dozen tests, verifying the features known to be supported by that browser. This includes hidden canvases, video and audio in various formats, WebRTC and other advanced networking protocols, screen resolution, and more.

2. The browser is subjected to an invisible “attack”: subtle errors are injected into the environment, and the browser engine’s reactions are captured and analyzed. Reblaze verifies that the exceptions and error messages are those which should be generated, if the browser is what it claims to be. (It is very difficult for threat actors to spoof this behavior using headless browsers and emulators, since there is an infinite number of possible errors to which any browser can be subjected, and threat actors need to replicate the actual reactions for each possible input.)

3. The above process only takes milliseconds, and it is completely transparent to the end user.

4. Once a browser has passed these tests, Reblaze signs it cryptographically. This signature accompanies all subsequent activity.