Guardian Engine

The fraud detection engine that powers your protection

Guardian Stack's server API transforms raw browser signals into actionable fraud intelligence. When your client calls guardian.get(), our processing engine analyzes hundreds of signals to detect bots, VPNs, browser tampering, and sophisticated fraud attempts.

How Server Processing Works

The magic happens server-side where we can safely perform intensive analysis without impacting user experience or exposing detection logic to potential attackers.


Complete Event Response Structure

Core Identification

Fraud Detection Usage:

  • id - Reference this in your fraud logs and dispute resolution

  • ip - Cross-reference with your existing IP reputation lists

  • location - Flag geographic anomalies (user in US, IP in Russia)

  • browser - Detect impossible browser configurations


Bot Detection Analysis

What This Means for Fraud:

  • detected: true β†’ Almost certainly automated traffic. Recommended action: BLOCK

  • score > 80 β†’ Very high bot probability. Consider challenging or blocking

  • score 40-80 β†’ Suspicious but inconclusive. Add friction or monitor

  • automationSignalsPresent: true β†’ Definitive automation tools detected

Common Bot Indicators You'll See:

  • webdriver β†’ Selenium automation (credential stuffing, account creation bots)

  • headless_chrome β†’ Headless browser (scraping, automated purchases)

  • puppeteer β†’ Advanced automation (sophisticated fraud attempts)


IP Intelligence Deep Dive

Critical Fraud Signals:

  • is_datacenter: true β†’ Traffic from hosting providers (bots, farms)

  • is_tor: true β†’ Maximum anonymity seeking (high fraud correlation)

  • is_abuser: true β†’ IP has fraud history across the internet

  • company.type: "hosting" β†’ Not residential internet (suspicious for consumers)

Risk Assessment Guide:


VPN Detection Engine

Fraud Detection Intelligence:

  • detected: true β†’ User hiding real location (why?)

  • timezoneDifference > 6 β†’ Major geographic inconsistency

  • confidence: "high" β†’ Very likely VPN usage

Fraud Context Matters:


Browser Tampering Detection

What Tampering Means:

  • detected: true β†’ Browser has been modified to avoid detection

  • antiDetectBrowser: true β†’ Professional fraud tools detected

  • anomalyScore > 0.7 β†’ Major inconsistencies in browser environment

Tampering = Fraud Intent:

  • Users don't accidentally modify browsers

  • Tampering tools are expensive and specialized

  • High correlation with fraud attempts

Key Indicators:

  • vendor_mismatch β†’ Browser claims to be Chrome but acts like Firefox

  • canvas_spoofing β†’ Artificial fingerprint to avoid tracking

  • webgl_anomalies β†’ Graphics inconsistencies (virtual environments)


Privacy Settings vs. Fraud

The Privacy Dilemma:

  • Legitimate privacy users β†’ Ad blockers, privacy browsers, VPNs for safety

  • Fraud actors β†’ Same tools to avoid detection

Smart Fraud Detection:


Virtualization Red Flags

Why VMs Matter for Fraud:

  • Scalability β†’ Easy to spin up hundreds of fraud instances

  • Isolation β†’ No risk to fraudster's real machine

  • Throwaway β†’ Delete evidence after attack

VM Detection = High Fraud Risk:

  • Consumer users rarely run VMs for browsing

  • Professional fraud operations always use VMs

  • Combined with other signals = almost certain fraud


Incognito Detection Intelligence

Incognito Fraud Context:

  • By itself β†’ Normal privacy behavior

  • With VPN + new account β†’ Avoiding identification

  • With bot signals β†’ Automated incognito sessions


Request IP Velocity Intelligence

  • What it is: Number of requests from the same IP (scoped to your siteKey when provided) within rolling 5-minute, 1-hour, and 24-hour windows.

  • How it's computed:

    • Server-side counts within [now βˆ’ window, now].

    • Includes the current event (+1), so first-ever event yields at least 1.

    • Uses server time; not affected by client timezones.

  • Why it matters: Sudden spikes strongly correlate with automation, credential stuffing, scraping, and abuse.

Fraud Detection Usage

  • High burst traffic: Treat as a strong indicator of automation.

  • Per-site scope: When siteKey is present, velocity is computed per site; otherwise global per IP.

  • Noise considerations:

    • Popular endpoints can have legitimate spikes; combine with bot, datacenter, or tampering signals for confidence.

    • Logged-in returning users with high velocity may be power users; tune responses accordingly.

Recommended Actions

  • Block when high velocity co-occurs with any of:

    • Datacenter IP, TOR, known abuser IP

    • Bot indicators or browser tampering

  • Challenge when high velocity is isolated but the user is new/anonymous

  • Allow but monitor for high velocity from known, low-risk customers

Here are the docs for Visitor Velocity Intelligence that you can copy:


Visitor Velocity Intelligence

What it is: Number of requests from the same visitorId (scoped to your siteKey when provided) within rolling 5-minute, 1-hour, 24-hour, and 7-day windows.

How it's computed:

  • Server-side counts within [now βˆ’ window, now].

  • Includes the current event (+1), so first-ever event yields at least 1.

  • Uses server time; not affected by client timezones.

  • Only computed when a visitorId is available.

Why it matters: Tracks request patterns per stable visitor identity, catching automation, credential stuffing, and abuse even when the attacker rotates IPs. Complements IP-based velocity to detect account-level or device-level spikes.

Compared to Request Velocity:

  • velocity: Counts by IP address (may aggregate many visitors behind NAT/proxies).

  • visitorVelocity: Counts by stable visitorId (resilient to IP rotation for the same visitor).

Fraud Decision Framework

Immediate Block Scenarios

Challenge/Additional Verification

We also offer our server-side SDK which includes many helper functions to save time in destructuring the event data.


Last updated

Was this helpful?