Ivan Centamori

EN IT

The art (and science) of Browser Fingerprinting

Have you ever wondered how the internet knows who you are even after you've cleared your cache, deleted your cookies, and activated the infamous "incognito mode"?

As developers, we spend our days making clients and servers talk to each other. Yet, we often take for granted the fundamental mechanisms that allow this conversation to have a logical flow. For decades, we relied on cookies to remember if a user had logged in or what they had placed in their shopping cart. But what happens when cookies are blocked? How do ad-tracking companies, or the sophisticated anti-fraud systems of banks, recognize a device that is doing everything it can to hide?

The answer lies in metadata and the tiny, invisible differences in the hardware and software we use. In this article, we will explore the history of tracking, the laws that govern it, and, most importantly, how to implement a hybrid fingerprinting system (Client + Server), taking an in-depth look at a library I wrote for the Laravel ecosystem: centamiv/advanced-fingerprint.

Stateless vs Stateful

Before diving into fingerprinting, we need to clarify a fundamental concept of web architecture that is sometimes taken for granted. We often hear that the web is a stateless environment, but what does that actually mean in contrast to stateful?

Imagine the HTTP protocol (the thing that makes the web work) as an interlocutor suffering from a severe form of short-term amnesia—a sort of digital goldfish. Every time the client makes a new request, the server has completely forgotten the previous request.

The most famous trick is the Cookie. It works like a name tag (a unique identifier, like a session ID) that the server hands to the browser upon the first visit. In subsequent requests, the browser "wears" this tag by automatically attaching it to the HTTP requests. This way, the server reads the tag, looks in its database, and says: "Ah, welcome back Mario, here is your dashboard!".

Fingerprinting comes into play when this tag is torn up, rejected, or forged.

What is fingerprinting?

Let’s go back to the previous analogy. If a cookie is a name tag, Fingerprinting (or device fingerprinting) is the equivalent of a detective watching you without asking for your ID.

The detective doesn't have your tag, but they take notes: "This person is 1.80m tall, has green eyes, a Milanese accent, wears size 43 red sneakers, and has a small scratch on their watch." Taken individually, none of these characteristics identify you uniquely (there are many people with green eyes). But the exact combination of all these variables creates a profile that, statistically, almost certainly corresponds only to you.

In the digital world, fingerprinting is an identification technique that saves nothing on the user's device. It simply queries the browser, collecting dozens of parameters: "What operating system do you use? How many cores does your CPU have? How do you render fonts? What is your time zone? What extensions do you have installed?".

By putting these small clues together, they are passed through a hashing algorithm (such as SHA-256) to obtain an alphanumeric string: your Device Signature.

The history of tracking

The web has been the stage for a true "arms race" between those who wanted to track users (for analytical, advertising, or security purposes) and those who wanted to protect their privacy. This evolution helps us understand why current technologies are so complex.

Cookies (1990s - 2000s)

It all started in 1994, when Lou Montulli, an engineer at Netscape Communications, invented the "Magic Cookie." The goal was noble: to allow the nascent e-commerce site to remember the shopping cart created by the user. The mechanism, as we've seen, relied on trust. But soon, advertising networks realized they could use Third-Party Cookies. By placing a small banner or an invisible pixel on thousands of different sites, an advertising company could assign you a unique cookie and track exactly which sites you visited, building an incredibly detailed profile of your interests.

ETag and LSO (2005 - 2015)

As tech-savvy users began to catch on, they started regularly deleting their cookies. The tracking industry responded with more devious and aggressive methods. This gave birth to the concept of the Evercookie (or zombie cookie): scripts designed to hide identifiers in every remote and persistent corner of the browser.

Today

With the arrival of HTML5 and the death of Flash (thankfully), modern browsers have started taking privacy seriously, and tracking has become much more complex. Apple introduced ITP (Intelligent Tracking Prevention) in Safari, Firefox released ETP (Enhanced Tracking Protection), and other browsers have deprecated third-party cookies and are isolating the cache.

Today, you can no longer reliably save a state without the user's explicit permission. This is where Browser Fingerprinting has become the undisputed king. Since an ID can no longer be stored, identity must be "guessed" by calculating it on the fly every time.

Implementing fingerprinting

To implement robust fingerprinting that identifies the user almost uniquely, we must rely on many methods of deduction. These are divided into two distinct categories, each with its own pros and cons: Server-Side and Client-Side.

Server-Side fingerprinting

This approach is defined as "passive" because the server does not execute any code on the user's device. It merely inspects the information that the browser sends voluntarily and automatically in the HTTP request headers.

Client-Side fingerprinting

This is where we get serious! Using JavaScript scripts sent to the browser, we actively query Web APIs to extract information deeply tied to the underlying hardware. For example:

Canvas fingerprinting

Canvas Fingerprinting exploits the tiny imperfections and architectural differences in the way different operating systems and different graphics cards (GPUs) render two-dimensional graphics.

But how does it work technically?

  1. Via JS, we create an HTML5 <canvas> element. We keep it invisible to the user.
  2. We draw a complex scene: text with overlapping fonts, emojis, Bezier curves, and color gradients.
  3. We ask the browser to export this drawing as an array of raw pixels or a Base64 image (via canvas.toDataURL()).

Why does it work? Because Windows uses a technology called ClearType to smooth font edges (anti-aliasing), while macOS uses its Core Graphics engine. An NVIDIA dedicated graphics card will calculate the color interpolation of a gradient slightly differently than a modest Intel integrated GPU. To the naked eye, the two images look identical, but at the single-pixel level (and therefore the resulting cryptographic Hash), the image generated by PC "A" will be different from the image generated by PC "B." This identifier persists even if you use incognito mode or clear your cache, because your computer's hardware doesn't change!

AudioContext Fingerprinting

Similar to Canvas, this technique doesn't draw images but "plays" invisible audio. It uses the Web Audio API to generate a sine wave, passes it through a dynamic compressor and various mathematical filters, and then analyzes the result. Because floating-point calculation processing varies slightly across different CPU architectures and sound cards, the output will generate a unique signature.

At this point, many developers fall into a dangerous logical trap: "I'm not saving any cookies, so the privacy banner and GDPR don't apply to me." Absolutely False.

In Europe, we operate under two major regulatory umbrellas:

  1. The ePrivacy Directive (the "Cookie Law"): This directive was written intentionally broad. It doesn't just talk about cookies; it prohibits the use of any technology that stores information or accesses information already stored in a user's terminal device without consent. Querying the GPU to perform canvas fingerprinting is, for all intents and purposes, "accessing terminal information." It falls squarely under Article 5(3).
  2. GDPR: The moment you use these techniques to distinguish one user from another over time, you are creating personal data (an online identifier). You need a legal basis to process it.

When can it be used without asking permission? There is a fundamental exemption. If the purpose of fingerprinting is strictly necessary for providing the service requested by the user, or for security and fraud prevention reasons, you can proceed under "Legitimate Interest" without blocking the user with a preemptive banner (you must still declare it in your Privacy Policy).

My library centamiv/advanced-fingerprint

While working on Laravel applications that required high security standards, I ran into a problem: there was no native package that elegantly combined both the server-side analysis of modern Client Hints and a clean client-side Canvas Fingerprinting implementation.

So I wrote centamiv/advanced-fingerprint.

Architecture

The strength of this library lies in its "Dual-Layer" approach. Calculating the hardware hash via Canvas requires the webpage to load and JavaScript to execute. This creates a delay.

To solve this problem, the library generates two signatures:

  1. Server Hash (Immediate): Calculated in PHP at the exact moment the HTTP request hits the server, before the view is even rendered. It uses IP, Client Hints, and Accept-Language. It is perfect for implementing very granular rate limiting (e.g., "block this device if it makes more than 10 login attempts," even if it changes IPs behind the same VPN).
  2. Client Hash (Delayed but Accurate): Via a @fingerprintScript Blade directive, a minimal JS script is injected that performs Canvas Fingerprinting and examines system APIs. The result is then sent back to the backend asynchronously.

Flexible Configuration

As developers, we need control. You decide the level of "entropy" (how precise the fingerprint should be). By modifying the published config/fingerprint.php file, you can enable or disable individual sensors.

Want a system that recognizes the user even if they switch from home Wi-Fi to a mobile connection? Just set 'ip' => false. This way, the fingerprint will be based solely on hardware and software, ignoring the network.

A real-world use case: preventing Session Hijacking

Session hijacking occurs when an attacker steals a legitimate user's session cookie (perhaps through an XSS vulnerability on an insecure form) and sets it in their own browser. To a standard server, the requests will appear to come from the original user.

With advanced-fingerprint, we can stop this. At the time of login, we save the user's "Signature":

use Centamiv\AdvancedFingerprint\Facades\Fingerprint;
use Illuminate\Support\Facades\Auth;

public function login(Request $request) {
   // ... credential validation ...

   // Generate the device fingerprint at the time of login
   $signature = Fingerprint::generate();

   // Save the fingerprint associated with the user in the database
   Auth::user()->update(['last_device_signature' => $signature]);

   return redirect('/dashboard');
}

Then, we create a custom Middleware to apply to protected routes. This middleware will verify on every critical request whether the device using the session matches the one that logged in:

namespace App\Http\Middleware;

use Closure;
use Centamiv\AdvancedFingerprint\Facades\Fingerprint;
use Illuminate\Support\Facades\Auth;

class PreventSessionHijacking
{
   public function handle($request, Closure $next)
   {
       // Recalculate the signature with every interaction
       $currentSignature = Fingerprint::generate();
       $userSignature = Auth::user()->last_device_signature;

       if ($currentSignature !== $userSignature) {
           // Red alert! The session token is valid,
           // but the hardware or browser has changed radically.
           // Someone might have stolen the session cookie.

           Auth::logout();
           return redirect('/login')->withErrors('An anomalous device change was detected. For your security, please log in again.');
       }

       return $next($request);
   }
}

To conclude

Browser Fingerprinting is a fascinating but inherently double-edged technology. In the hands of advertising agencies or data brokers, it represents the ultimate tool for eroding anonymity on the web—to the point that browsers like Brave or the Tor Project dedicate significant resources to creating "random noise" (Canvas Randomization) in an attempt to spoof these fingerprints.

However, in the hands of software engineers developing enterprise applications, financial platforms, or critical authentication systems, it is a formidable shield. It allows us to defend our users from automated botnet attacks, session theft, and cyber fraud.

Deeply understanding these mechanics—knowing what Client Hints are, how Canvas entropy works, or managing state in a stateless protocol—doesn't just make us more capable programmers; it gives us the awareness necessary to make technical and ethical decisions about the architecture of the systems we build every day.