IP addresses and User-Agent strings are useful for detecting bots, but they are no longer enough.

A sophisticated bot can use a residential proxy, rotate IP addresses, and pretend to be a normal Chrome browser. From the server’s perspective, the request can look almost identical to a real user.

This is where browser fingerprinting becomes useful.

What is browser fingerprinting?

Every browser runs in a particular environment.

It has a combination of characteristics such as:

• Browser and operating system
• Screen resolution
• Timezone and language
• CPU information
• Touch capabilities
• Device pixel ratio
• WebGL/GPU information
• Browser APIs
• Automation indicators

A website can collect some of these characteristics using JavaScript and create a representation of the browser environment.

For example:

Browser: Chrome
OS: macOS
Screen: 1728 × 1117
Timezone: Asia/Kolkata
CPU: 10 cores
Touch: 0
WebGL: Apple GPU
WebDriver: false

None of these values individually tells us whether the visitor is a bot.

The value comes from looking at them together.

---

Why fingerprinting helps with bot detection

Consider a bot that rotates IP addresses:

Bot
 ├── IP 1
 ├── IP 2
 ├── IP 3
 ├── IP 4
 └── IP 5

An IP-based system may see five different visitors.

But if all five requests have a very similar browser environment:

Chrome
Linux
8 CPU cores
1920×1080
Same WebGL renderer
Same browser characteristics

we can start to see a relationship between them.

This is particularly useful for detecting automated traffic that tries to hide behind different IP addresses.

The important idea is:

IP tells us where the request came from. Fingerprinting tells us more about the environment generating it.

---

What signals can we collect?

We don’t need hundreds of signals to build a useful first version.

Browser

User-Agent
Client Hints
navigator.webdriver

Device

hardwareConcurrency
maxTouchPoints
screen dimensions
devicePixelRatio

Rendering

WebGL vendor
WebGL renderer
Canvas characteristics

Environment

Timezone
Language
Platform
Browser capabilities

These signals can then be combined with server-side information:

IP
ASN
Request rate
Cookies
Session
Referrer

The result is much more useful than any individual field.

---

The most important concept: consistency

Fingerprinting isn’t primarily about finding “bad” values.

It’s about finding values that don’t make sense together.

For example:

User-Agent:
iPhone Safari

maxTouchPoints:
0

Screen:
1920 × 1080

hardwareConcurrency:
32

None of these values is necessarily impossible on its own.

But together, they represent an unusual device profile.

Another example:

IP location: India
Timezone: America/Los_Angeles
Language: ja-JP
Platform: Windows
User-Agent: iPhone

Again, this doesn’t prove fraud.

The user could be traveling or using a VPN.

But the more inconsistencies we find, the more interesting the session becomes.

This gives us a powerful rule:

Bot detection should look for contradictions, not just anomalies.

---

---

Why one fingerprint signal isn’t enough

This is one of the biggest mistakes in bot detection.

For example:

WebGL renderer = SwiftShader

doesn’t necessarily mean:

Bot = true

A virtual machine or legitimate cloud environment may also use software rendering.

Similarly:

navigator.webdriver = false

doesn’t mean:

Human = true

A sophisticated bot can try to hide automation signals.

Therefore, fingerprinting works best as a risk-scoring system.

Think:

IP reputation
      +
Browser fingerprint
      +
Device consistency
      +
Automation signals
      +
Behavior
      ↓
   Risk Score

The more independent signals agree, the higher our confidence.

---

---

Where GIVT ends and SIVT begins

This also explains the difference between GIVT and SIVT.

Simple server-side rules can identify obvious traffic:

Known crawler
Known bot
Known invalid IP
Obvious automation
Extreme request rate

This is generally the easier GIVT layer.

Fingerprinting takes us one step further.

We can detect:

Browser inconsistencies
Automation characteristics
Device mismatches
Suspicious environments
Repeated browser fingerprints

But even fingerprinting has limits.

A sophisticated attacker can run a genuine browser on a genuine device through a residential network.

At that point, the fingerprint may look completely normal.

We need to look at:

Fingerprint
+
Network
+
Behavior
+
Historical activity
+
Cross-session relationships

That is where detection starts moving toward SIVT.

---

The key takeaway

Browser fingerprinting is not a magic bot detector.

It is another layer of evidence.

IP addresses tell us about the network.

Server logs tell us how the client interacts with our infrastructure.

Browser fingerprinting tells us about the browser and device environment.

Behavior tells us what that environment is actually doing.

When these signals are combined, we can move from simple bot detection toward sophisticated invalid-traffic detection.

The progression is:

Server logs → GIVT → Browser fingerprint → Consistency → Behavior → Cross-session analysis → SIVT

The goal isn’t to find one field that says “bot.”

The goal is to collect enough independent evidence to confidently distinguish a real user from an automated environment pretending to be one.