Detecting bots without cookies

Cookies are no help against bots. Automated clients don't keep them, and they start a fresh browser profile whenever it suits them. But bots still run in a browser, and browsers that are being driven by software tend to give themselves away. This guide covers the checks worth running and how to combine them with a visitor ID.

Why bots are hard to spot

Today's bots aren't simple HTTP scripts. They use:

• Headless browsers: full Chrome or Firefox engines with no visible window
• Automation frameworks such as Puppeteer, Playwright and Selenium, driving real browsers
• Anti-detect browsers built to imitate ordinary fingerprints
• Residential proxies, so traffic comes from home internet connections instead of data centers

They look more and more like real browsers, but rarely perfectly.

Automation markers

Browsers controlled through WebDriver are required by the specification to set navigator.webdriver, and several tools leave further traces:

function automationMarkers() {
  return {
    webdriver: navigator.webdriver === true,
    headlessUserAgent: navigator.userAgent.includes('HeadlessChrome'),
    seleniumGlobals: '_selenium' in window || 'callSelenium' in window,
    phantom: '_phantom' in window || 'callPhantom' in window,
  };
}

Sophisticated bots patch these values, so treat a clean result as "not obviously automated" rather than "human". A positive result, on the other hand, is a strong signal.

Inconsistencies

Patched environments are often internally inconsistent:

• A user agent that claims Windows, with WebGL reporting a GPU only found in Linux servers
• A "mobile" browser that reports no touch points
• Many supposedly different devices producing exactly the same canvas output

Each check is weak on its own; together they separate cheap automation from real visitors.

Behavior

Real people move the mouse along curved, uneven paths, scroll, and take time before clicking. Scripts often don't. Behavioral checks (no pointer movement before a click, perfectly regular timing, instant form fills) catch bots that pass every environment check, at the cost of collecting interaction data and handling users of keyboards and assistive technology fairly.

TraceTail doesn't collect behavior: its SDK adds no mouse or keyboard listeners. If you add behavioral checks, they're your own code and your own data.

Using a visitor ID

A visitor ID helps in two ways.

It flags automated browsers. With an API key, each identification includes isBot, TraceTail's verdict on whether the browser is automated (for example headless Chrome or WebDriver).

import { TraceTail } from '@tracetail/js';

const tracetail = new TraceTail({ apiKey: 'YOUR_API_KEY', endpoint: 'https://tracetail.io/api' });

// isBot is set when the identification is registered with your API key.
const { visitorId, isBot } = await tracetail.generateFingerprint();

It survives the tricks bots use to look new. Rotating IP addresses and clearing cookies doesn't change the visitor ID, so you can rate-limit by device instead of by IP. A bot has to change its browser itself, which is slower and more expensive.

Make the decision on your server: send the visitorId with the request you're protecting, and count requests per ID there.

Layer your defenses

1. Identify the device on pages where abuse costs you: signup, sign-in, checkout, search.
2. Check automation markers and the isBot flag.
3. Rate-limit by visitor ID as well as by IP address and account.
4. Challenge when unsure: a CAPTCHA or an email confirmation for borderline cases instead of a hard block.
5. Watch outcomes: when abuse gets through, check which layer should have caught it.

The arms race

Bot operators adapt. The goal isn't a perfect detector but making automation expensive: every extra signal they have to fake costs them time and throughput.

Read the docs to add TraceTail, or create a free account: 1,000 requests a month, with the automated-browser flag on every one.