Calibrated client-side browser risk intelligence for fingerprint, automation, VM, network, hardware, behavior, and evasion review.

Overview

Antiwall is a Next.js browser risk dashboard that runs a client-side deep scan and correlates browser fingerprint, automation, virtual machine, network, hardware, timing, behavior, DOM/API integrity, privacy, and anti-evasion signals into a calibrated 0-100 risk score.

Raw module points remain visible for auditability, while the main score uses weighting, saturation, evidence floors, cluster correlation, and guardrails so repeated weak warnings do not dominate the result.

Features

• Calibrated risk dial with low, medium, high, and critical bands, animated sweep progress, and rolling score values.
• 46 scan modules covering WebDriver, automation globals, iframe/worker consistency, WebGL/WebGPU, canvas, audio, fonts, WebRTC/IP, storage, permissions, codecs, locale, behavior, DOM/API integrity, and platform coherence.
• Virtual machine profile in the viewport card with Yes, Review, or No based on correlated VM heuristics.
• VM detection signals for VMware, VirtualBox, Hyper-V, QEMU/KVM, Parallels, software renderers, low CPU/RAM, sparse fonts, missing media devices, common VM resolutions, WebGL extension count, battery/storage oddities, timing anomalies, and VirtualBox-style WebRTC local IPs.
• Browser environment summary for browser/OS, CPU, RAM, screen profile, language, timezone, touch, connection, and same-origin round trip.
• False-positive controls that treat ambiguous signals such as common laptop resolutions, missing cameras, unavailable WebGPU, battery API behavior, and privacy settings as weak context unless they correlate with stronger evidence.
• Proxy/VPN detection summary card with Detected, Review, or No status from IP intelligence, WebRTC public-IP comparison, organization keywords, and timezone coherence.
• IP detail panel with selectable public IP providers, local WebRTC address review, privacy network flags, and timezone comparison.
• Same-origin server ping used only to display browser-to-server round trip time.
• Animated dashboard metrics, including rolling numbers for scores/IP values and radial expansion for the threat radar.
• Visitor ID, stable fingerprint digest, top weighted signals, raw family scores, confidence, data quality, and JSON export.
• PWA metadata, manifest, favicon set, OpenGraph/Twitter image, and install button when supported by the browser.

Risk Scoring

The scanner keeps raw points per signal family, then converts them into a calibrated score:

1. Each risk signal is weighted by severity, confidence, and evidence quality.
2. Each family has a cap and saturation curve.
3. Strong evidence such as navigator.webdriver, automation globals, iframe WebDriver leakage, patched primitives, local automation ports, or virtual/software GPU renderers can set a minimum evidence floor.
4. Independent clusters such as automation, tamper, virtualization, network, behavior, and fingerprint anomalies can add a correlation bonus.
5. Guardrails cap reports that only contain weak or ambiguous warnings.

Score	Level	Meaning
0-34	Low	Normal or low-risk profile based on available client-side evidence.
35-64	Medium	Multiple warnings or weakly correlated anomalies.
65-84	High	Strong evidence or several independent risky clusters.
85-100	Critical	Highly likely automation, virtualization, anonymization, or browser tampering.

Virtual Machine Detection

Browser JavaScript cannot ask the operating system whether it is running inside a VM, so Antiwall uses heuristic scoring. Direct GPU strings such as VMware SVGA, VirtualBox, QEMU/KVM VirGL/virtio, Parallels, Hyper-V, Microsoft Basic Render Driver, SwiftShader, or llvmpipe are treated as high-signal evidence. Weaker clues such as low CPU/RAM, sparse fonts, missing media devices, common VM resolutions, low WebGL extension count, audio/canvas anomalies, storage limits, and WebRTC local IP patterns are only persuasive when correlated.

The VM result shown in the viewport card means:

Label	Meaning
No	No strong VM indicators were found in the current browser surfaces.
Review	Some supporting VM-like signals exist, but evidence is not strong enough for a direct VM conclusion.
Yes	Direct hypervisor/software renderer evidence or multiple correlated signal groups were found.

Proxy / VPN Detection

The Proxy / VPN Detection card summarizes network anonymity signals without exposing every raw flag in the main dashboard. It correlates public IP intelligence, WebRTC candidates, ISP/organization keywords, and browser-vs-IP timezone coherence in a compact single-column card with inline label/value rows.

The scanner treats provider-reported proxy, vpn, tor, anonymous, and hosting fields as direct IP intelligence. It also reviews organization and network text for datacenter or privacy-service terms such as VPN, proxy, Tor exit, hosting, VPS, colocation, cloud providers, and known VPN brands.

If the selected public-IP provider is rate-limited, times out, or is blocked by browser fetch/CORS policy, Antiwall automatically tries the remaining providers in a stable fallback order and records the attempted providers in the IP detail payload. When fallback succeeds, the Proxy / VPN card keeps rendering with the recovered public IP details instead of dropping into an unavailable state.

WebRTC public-IP comparison is handled separately: if ICE candidates expose a public IP that differs from the HTTP-observed public IP, Antiwall raises a stronger proxy/VPN leak signal. Timezone differences are scored only when the IANA timezone region differs, reducing false positives from nearby cities or normal travel.

The card labels mean:

Label	Meaning
No	No proxy/VPN/Tor indicators were found in the current scan.
Review	One or more weak or contextual network indicators were found.
Detected	Strong provider, WebRTC leak, Tor, VPN, proxy, or datacenter evidence was found.

Quick Start

npm install
npm run dev

Open the local URL printed by Next.js, then run a deep scan from the dashboard.

Scripts

npm run dev        # Start the local Next.js dev server on 127.0.0.1
npm run build      # Build the production server bundle
npm run start      # Start a Next.js production server
npm run typecheck  # Run TypeScript checks without emitting files

Scan Responsiveness

CPU-only probes run in the module Web Worker at src/scanner/scanner.worker.ts: the 5M-operation CPU benchmark, Math/FPU fingerprint, WebAssembly/crypto timing, and final SHA-256 digest. If a browser blocks workers, the scanner falls back to the same implementations in cooperative chunks so input and rendering still receive task boundaries.

DOM-bound phases remain on the Main Thread, but Canvas, WebGL, emoji rendering, font enumeration, font metrics, and repeated Canvas/Audio integrity probes yield through scheduler.yield(), requestIdleCallback(), or setTimeout(0) between expensive phases. The idle path includes a timeout so hidden/background tabs cannot stall a scan indefinitely.

Server Transport Fingerprinting

POST /api/scan/server correlates the network User-Agent, UA Client Hints, Fetch Metadata headers, JavaScript-reported navigator identity, trusted TLS fingerprints, and trusted wire header order. The response includes:

• JA3/JA4, TLS version/cipher, ALPN, and HTTP version when an edge or ingress supplies them.
• HTTP header and HTTP/2 pseudo-header order when supplied by a trusted ingress.
• Browser-family/platform consistency findings and a bounded automation score.
• The original client-observed round-trip measurement.

GET /api/scan/server remains available as a compatibility/health probe, but it cannot perform JavaScript-to-network identity correlation.

Why ingress telemetry is required

Next.js Route Handlers receive the Web Request API after TLS termination. They cannot reconstruct the raw TLS ClientHello, and Web Headers iteration is not treated as wire order. The route therefore reports transport fingerprint availability as unavailable instead of inventing JA3/JA4 values when no trusted edge observation exists.

Supported trusted sources:

• Vercel: x-vercel-ja3-digest and x-vercel-ja4-digest are accepted when the VERCEL deployment variable is present.
• Amazon CloudFront: CloudFront-Viewer-JA3-Fingerprint, CloudFront-Viewer-JA4-Fingerprint, CloudFront-Viewer-TLS, CloudFront-Viewer-Http-Version, CloudFront-Viewer-Header-Order, and CloudFront-Viewer-Header-Count.
• Cloudflare: the cf-ja3-hash and cf-ja4 Managed Transform headers.
• A custom TLS-aware ingress: x-antiwall-ja3-hash, x-antiwall-ja4, x-antiwall-tls-version, x-antiwall-tls-cipher, x-antiwall-alpn, x-antiwall-http-version, x-antiwall-http-header-count, x-antiwall-http2-header-order, x-antiwall-http2-pseudo-header-order, and x-antiwall-tls-client-family.

CloudFront, Cloudflare, and custom ingress telemetry is enabled with:

ANTIWALL_TRUST_PROXY_TELEMETRY=true

Only enable this after the origin is restricted to the trusted proxy and the proxy removes client-supplied copies of those headers. Otherwise a caller could forge fingerprint metadata.

Known fingerprint intelligence can be injected without changing application code:

ANTIWALL_TLS_FINGERPRINT_REGISTRY={"ja3":{"<hash>":{"family":"python-requests","automation":true,"confidence":97,"label":"Python requests/OpenSSL profile"}},"ja4":{"<fingerprint>":{"family":"tls-client","automation":true,"confidence":96}}}

The registry is intentionally deployment-controlled because browser, OpenSSL, curl-impersonate, and tls-client fingerprints change with versions and profiles. A TLS fingerprint match is correlated with header order and the JavaScript identity rather than used as standalone blocking proof.

Docker

Build and run the production web image locally:

docker build -t antiwall-web:local .
docker run --rm -p 8080:8080 antiwall-web:local

Or use Docker Compose:

docker compose up --build

Set a different host port when needed:

WEB_PORT=8088 docker compose up --build

The container serves the Next.js standalone server on port 8080, including the /api/scan/server round-trip endpoint.

CI/CD

The GitHub Actions workflow at .github/workflows/cicd.yml runs npm ci, npm run typecheck, and npm run build on pull requests and pushes to main.

For non-pull-request events, the CD job builds and pushes a Docker image to GitHub Container Registry with tags derived from branch, version tag, commit SHA, and latest on the default branch:

ghcr.io/<owner>/<repo>:latest
ghcr.io/<owner>/<repo>:main
ghcr.io/<owner>/<repo>:sha-<commit>
ghcr.io/<owner>/<repo>:vX.Y.Z

Accuracy Notes

Antiwall sees browser-exposed client-side surfaces plus a same-origin server request telemetry API. These signals are useful for device and browser intelligence, but they should not be the only blocking decision. For production fraud workflows, correlate Antiwall output with account history, TLS/JA fingerprinting, behavioral session data, payment/shipping signals, and abuse feedback loops.

Privacy tools, locked-down enterprise browsers, uncommon hardware, remote desktop sessions, and permission settings can change many browser surfaces. Treat Review and weak warning signals as correlation context, not standalone proof.