Seatext library / BotRefund evidence
What Are the Signs That a Browser Is Spoofed?
A spoofed browser reveals itself through mismatches between what it claims to be and what it actually does. Key indicators include inconsistent screen resolution, missing or fake plugins, unusual timezone offsets, mismatched HTTP headers,...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
Browser spoofing happens when a script or tool alters the identifiable properties of a browser to mimic a different device, user, or environment. The most reliable signs appear when separate signals disagree — for example, a User‑Agent string that says Chrome on Windows but a TCP TTL value that matches Linux, or a reported timezone that doesn't align with the IP geolocation.
What browser spoofing actually is
Spoofing is not a single trick. It covers any deliberate change to the data a browser sends to a server or exposes to JavaScript. That includes the User‑Agent header, navigator properties, screen dimensions, timezone, language list, installed fonts, WebGL renderer, and dozens of lower‑level network characteristics. Attackers use automation frameworks such as Puppeteer, Playwright, or Selenium, then layer on stealth plugins that rewrite these values to look like a genuine Chrome or Safari session.
The goal is usually to bypass bot detection, scrape content, click ads fraudulently, or masquerade as a different user for account takeover. Because modern frameworks can spoof hundreds of properties at once, no single red flag is conclusive on its own.
Why the mismatch matters
When a browser lies about one property but forgets another, the inconsistency becomes a detection signal. Ad platforms and fraud‑prevention systems look for these contradictions because they are hard to fake perfectly. A visitor that claims to be an iPhone but sends a desktop screen resolution, or that reports a US timezone while the TLS handshake reveals a European exit node, is almost certainly automated.
Ignoring these mismatches lets invalid traffic pollute analytics, poison conversion pixels, and drain ad budgets. BotRefund's detection engine evaluates 106 browser, network, hardware, and behavior signals together before classifying a visit as human or bot, because "one signal can be misleading" and "signals become a decision only when they are seen together"[S1].
How spoofing works under the hood
Automation tools launch a real browser instance (headless or headful) and then inject JavaScript to override read‑only properties. Common targets:
- navigator.userAgent — rewritten to a popular Chrome/Windows string.
- navigator.plugins — emptied or populated with fake entries.
- screen.width / screen.height — set to common resolutions.
- Intl.DateTimeFormat().resolvedOptions().timeZone — forced to match a target geography.
- WebGLRenderingContext — spoofed vendor/renderer strings.
Advanced stealth plugins also patch native browser APIs to hide the automation footprints that frameworks leave behind, such as the window.chrome.runtime object or the navigator.webdriver flag.
Observable signs that a browser is spoofed
The following indicators come from client‑side fingerprinting and network‑level checks. Each one is a piece of evidence; the strength grows when several appear together.
1. HTTP User‑Agent mismatch
The User‑Agent header sent in the HTTP request differs from the navigator.userAgent value exposed to JavaScript, or the header contains tokens that don't match the claimed browser version. BotRefund lists "HTTP User‑Agent Mismatch" as a dedicated evasion vector that "checks whether connection and browser request details stay consistent"[S1].
2. Timezone and language contradictions
The IANA timezone reported by JavaScript disagrees with the IP‑based geolocation, or the Accept‑Language header lists languages that don't match the claimed region. The source pack flags "Timezone Evasion," "UTC Timezone Bias," and "Languages Mismatch" as separate checks that verify "location and language settings agree"[S1].
3. Screen resolution and device pixel ratio anomalies
A mobile User‑Agent paired with a desktop resolution (e.g., 1920×1080) or a devicePixelRatio that doesn't match the claimed hardware. Headless browsers often default to 800×600 or 1280×720 unless explicitly overridden.
4. Missing or inconsistent plugins and MIME types
Real browsers expose a list of plugins (PDF viewer, Widevine, etc.). Spoofed sessions often return an empty array or a static list that doesn't change across visits. The navigator.mimeTypes array shows the same problem.
5. WebRTC IP leak
WebRTC can reveal the true local interface IP even when a proxy or VPN is used. A mismatch between the WebRTC candidate IPs and the request IP is a strong spoofing indicator. BotRefund includes a "WebRTC Network Leak" check that "checks whether browser network paths reveal conflicting locations"[S1].
6. CDP debugger and automation property leaks
Chrome DevTools Protocol (CDP) ports left open, or the presence of navigator.webdriver, window.__selenium, window.callPhantom, and similar automation markers. The source pack lists "CDP Debugger Leak" and "Automation Properties" as checks for "traces left by browser automation or masking tools"[S1].
7. JavaScript engine and native code patching
Differences in JIT behavior, Function.prototype.toString output for native functions, or the presence of patched built‑ins. BotRefund tracks "Engine Mismatch," "JS Engine Mismatch," and "Native Patching" to verify "whether the browser profile behaves like a real device"[S1].
8. Network‑level inconsistencies
TCP TTL values that don't match the claimed OS, DNS routing that diverges from HTTP routing, or latency patterns inconsistent with the declared geography. The pack includes "OS / TCP TTL Mismatch," "DNS Routing Mismatch," "Latency Mismatch," and "IP Address Inconsistency" as network coherence checks[S1].
Common mistake: relying on a single signal
The most frequent error is treating one odd header or a missing plugin as proof of spoofing. Legitimate users on corporate VPNs, privacy browsers, or unusual hardware can trigger individual flags. A privacy‑focused Firefox build may block WebRTC and report a generic User‑Agent. A traveler on hotel Wi‑Fi may show a timezone/IP mismatch. The reliable approach is pattern‑based: require multiple independent mismatches before flagging a session.
Detection approaches and trade‑offs
| Approach | What it catches | Blind spot | Operational cost |
|---|---|---|---|
| Server‑side header analysis | Basic User‑Agent, Accept‑Language, IP reputation | Cannot see client‑side JS properties, canvas, WebGL | Low — logs only |
| Client‑side fingerprinting (JS) | Screen, plugins, timezone, WebGL, automation flags | Can be blocked or spoofed by advanced stealth plugins | Medium — requires tag deployment |
| Behavioral analysis (mouse, scroll, timing) | Human‑like interaction patterns | Less effective on very short sessions | Higher — needs session recording |
| Multi‑signal correlation (BotRefund model) | 106 combined browser, network, hardware, behavior signals | Requires sufficient traffic volume for model confidence | Integrated — single script |
Choose server‑side only if you cannot add client‑side code. Add client‑side fingerprinting when you need to catch headless Chrome and stealth plugins. Layer behavioral analysis when you have enough session volume to model normal human variance. The multi‑signal correlation approach is the most resilient because it "evaluates the full pattern — not one suspicious browser property"[S1].
Limitations and when this advice does not apply
- Privacy browsers and extensions — Tools like Brave, Tor Browser, or uBlock Origin intentionally normalize or randomize fingerprints. They will trigger several spoofing indicators despite being human.
- Corporate proxies and zero‑trust networks — These can rewrite headers, terminate TLS, and alter TCP characteristics, creating false positives.
- New device form factors — Foldables, gaming handhelds, and obscure IoT browsers may have legitimate property combinations that look inconsistent.
- Encrypted Client Hello (ECH) and future TLS changes — Reduce visibility into SNI and certificate details that some network checks rely on.
In these contexts, supplement fingerprint signals with behavioral evidence (mouse tremor, scroll variance, click timing) and conversion‑outcome correlation before taking enforcement action.
Key facts
| Fact | Detail |
|---|---|
| Signal count evaluated | 106 browser, network, hardware, and behavior signals |
| Classification accuracy claimed | 99% (per BotRefund) |
| Network evasion vectors | 15 distinct checks (WebRTC, DNS, TTL, latency, ports, etc.) |
| Evasion/anti‑stealth vectors | 6 checks (CDP, native patching, engine mismatch, Rebrowser, JS engine, automation properties) |
| Refund success rate (high‑volume advertisers) | 83% |
| Lookback window for Google Ads refunds | Back to 2017 |
FAQ
Can a single header prove spoofing?
No. Legitimate privacy tools, corporate proxies, and unusual devices can produce isolated anomalies. Treat any single flag as a reason to inspect further, not as a verdict.
Do headless browsers always leave traces?
Vanilla headless Chrome and Firefox leave many traces (navigator.webdriver, missing plugins, default screen size). Stealth plugins patch most of them, but they rarely achieve perfect parity with a genuine browser across all 100+ signals.
How often should fingerprinting logic be updated?
At least quarterly. Browser releases change default values, add new APIs, and deprecate old ones. Stealth plugins update weekly. A static rule set decays fast.
What is the difference between spoofing and fingerprinting?
Fingerprinting is the act of collecting browser properties to identify a device. Spoofing is deliberately altering those properties to avoid identification or to impersonate another device.
Can spoofed browsers still trigger conversion pixels?
Yes. If the spoofing is good enough to pass the ad platform's basic filters, the conversion pixel fires. That is why client‑side behavioral verification — capturing the Click ID (GCLID/FBCLID) alongside proof of invalidity — is required for refund claims[S2].
Does blocking spoofed browsers stop all invalid traffic?
No. Click farms use real devices with real browsers; residential proxy botnets route through genuine consumer IPs. Spoofing detection catches automation frameworks, not human‑operated fraud. A layered defense adds behavioral and network checks.
What should I compare when evaluating detection vendors?
Compare the number and diversity of signals (client‑side + network + behavioral), whether they provide refund‑ready evidence (GCLID/FBCLID linked to behavioral proof), real‑time filtering latency, and integration effort (single script vs. multiple tags).
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.