Redirection with cookie installation is a way to verify the user of a website or mobile application. It is used mainly for bot protection.

The first time a user visits a site, the user's application (e.g., browser or mobile app) receives a 401 Unauthorized status and a page with JavaScript code that collects data about the digital fingerprint of the user's environment and sends it to the Qrator Labs server as a response. If this server detects the environment as a legitimate browser, it assigns a tracking cookie to the user. The user can then browse the site for a while without additional validation, with Qrator Labs automatically extending the validity of the cookie each time. If, however, the Qrator Labs server identifies the user as a bot, it does not set a cookie, but returns an 403 Forbidden error instead of page content.

For different addresses, you can set how Qrator Labs responds to a user without a tracking cookie: either responding with 401 Unauthorized with an environment check code, or responding with 403 Forbidden.

The advantage of a digital fingerprint-based solution is that the bot's activity is stopped instantly, preventing it from completing even the first request. This distinguishes this approach from blocking after activity analysis has been completed, which is possible only after several requests.

Integration examples

Protecting your website using cookies

Assume that all pages on your site are meant to be viewed in a browser. In that case, you can set up Qrator Labs protection so that both validation and issuance of a tracking cookie can take place on any page.

The user starts browsing from any page and on the first visit, Qrator Labs performs a validation and sets a cookie. If the cookie expires, the next time the site is accessed, it will be validated again. At the same time, bots will fail the validation and get an 401 Unauthorized error on any page.

This approach is as transparent to users as possible, but it requires that they always use JavaScript-enabled browsers.

Mobile API protection using cookie

Suppose you have an application that makes requests to your API gateway and can process data received from it, but cannot process an HTML page with JavaScript code. This is a common case, e.g. for mobile apps.

In such a situation, it's recommended to install and check the tracking cookie on different pages:

1. Add a URL to the quick reference card intended to be visited from the browser environment.
2. Enable fingerprint verification with subsequent issuance of a tracking cookie for that page in your Qrator Labs dashboard.
3. In your application client code, add access to this URL through a browser. For example, the application might display the HTML page from the server in the WebView component as a loading screen, and then retrieve the received cookie from the WebView repository. When the cookie expires, you must redisplay that page.
4. The application must use the received cookie in subsequent requests to the API gateway.

Mobile API protection using hash

For some mobile apps, the [cookie protection method] might not be suitable, as it requires a tracking cookie to be received via a web page.

For such apps, you can use hash verification, which uses HTTP request headers and a secret key known only to you and Qrator Labs:

1. In your Qrator Labs dashboard, set the Accept Only with Cookies rule for all pages that should be protected.

   With this setting, the Qrator Labs server will consider visitors with either the correct cookie or the correct hash in the HTTP headers as legitimate.

2. At the app building phase, add an obfuscated key to it.

   Before each request to the API gateway, use that key to calculate the header hash, and add a header with that hash to the request.

Bots that don't have the key won't be able to add the correct hash to requests. Qrator Labs will not send such requests to the API gateway.