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
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
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.
HTTPS resources can be protected using this mechanism only under certain conditions:
Forced enabling of HTTPS must be done using reverse HTTP proxy redirects.
HTTP cookies are not available when working via HTTPS and vice versa. Therefore, for bot protection to work correctly, it is necessary that the redirection using the correct protocol is performed before the analysis of the digital fingerprint and installation of cookies.
HTTPS proxying with key disclosure must be configured.
Otherwise, the Qrator Labs reverse HTTP proxy will not be able to check or set HTTP headers, which is necessary to handle cookies.
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.
Mobile API protection using cookie
In such a situation, it's recommended to install and check the tracking cookie on different pages:
- Add a URL to the quick reference card intended to be visited from the browser environment.
- Enable fingerprint verification with subsequent issuance of a tracking cookie for that page in your Qrator Labs dashboard.
- 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.
- 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:
In your Qrator Labs dashboard, set the
Accept Only with Cookiesrule 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.
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.