As all applications need to be both secured and fast, the industry moves towards mitigating bad bots. As nearly 25% of all web traffic is generated by bad bots, we have to be sure we can detect and block them. Of course, this ratio depends on your market – for example, gambling companies and airlines have approximately 54% and 44% of their traffic coming from bad bots, respectively.

Another question you would probably have in mind would be: “Can I detect and mitigate bad bots very early in the process?”

AWS Builder Community Hub

Securing applications without impact

As you probably already faced, going on the internet isn’t as easy as it was few years ago. Many security solutions expect active actions from clients, such as using CAPTCHA, selecting animals of a given name, choosing multiple images with common criteria, etc.

Asking clients for active actions can’t be impact-less, as frustrating them usually results in losing revenue. Stanford University conducted different studies which showed that approximately 15% of users will abort their web visit if they are faced with a CAPTCHA challenge.

[You might also like: CAPTCHA Limitations of Bot Mitigation]

If we also have a look into when this challenge comes, we see that it’s late in the process.

Usually we can access the website, then browse some pages and usually it’s either on registration or login pages you will have this challenge.

So instead of blocking only bad bots, you may have false positives seeing clients going to competitors due to CAPTCHA.

In case CAPTCHA is based on source IP, there is another risk. When you surf on the internet, you go out with a single public IP. In case your network is a corporate one and you have multiple devices, they will share the same public IP. So, if one device answers the CAPTCHA, all devices will be allowed as they come from the same IP.

Overcoming the limitation with fingerprint technology

As we know that nothing is better than transparent solutions, we see lot of “new” solutions in airports (fingerprint verification, retinal controls), highways (ETC for Electronic Toll Collection), and more.

[You might also like: Web Application Security in a Digitally Connected World]

When we have to stand in line wasting precious minutes, we always think that next time we’ll use a faster mechanism.

Why would you think differently for your application protection?

One of the advanced protections is to identify a client based on a fingerprint instead of any “classic” information available by default in HTTP requests. This fingerprint will be generated on the first request, allowing these security solutions to detect and mitigate bad bots at the very first step of web browsing.

Unlike some CAPTCHA based on IP, fingerprints will be unique and linked to the client’s machine. So even if multiple clients come from the same public IP, they will be identified as different clients.

Of course, we can still act badly after sending our fingerprint. In case we do so, this fingerprint can be used to mitigate our attacks and later block our access to the website due to too many attacks. This subject will be covered in an upcoming article: Access to applications based on a “driving license” model.

Read the “2018 C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts” to learn more.

Download Now