docs

Browser automation

Drive a real browser through Hugin to reach authenticated, JavaScript-heavy attack surface — security overrides, anti-bot bypass, DOM-XSS verification, and 80+ scriptable actions. (Pro)

Some attack surface only appears in a real browser: a SPA that builds requests in JavaScript, a flow behind a login and three clicks, a page that needs a rendered DOM. Hugin can drive a browser for you, and every request it makes flows through the Proxy into History like any other. Browser automation is a Pro feature.

A browser driven by Hugin, with its traffic captured in History
Drive a real browser through Hugin to reach authenticated, JavaScript-heavy surface — every request lands in History like any other.

The browsers

Hugin drives four kinds of browser:

Chrome

Standard Chrome over the Chrome DevTools Protocol (CDP).

Mullvad / Firefox

Gecko-based browsers driven over Marionette.

Hugin Browser

Hugin's own self-contained browser — no separate browser install needed.

Headless

A lightweight JS-only mode with no rendering — the fallback when a full browser isn't available.

The Browser view

The view is split into 6 tabs: Browser (the live session), Network (its requests), Cookies, Tabs, Automation, and DOM Invader for client-side bug hunting.

Driving it

You don't speak CDP or Marionette directly — Hugin wraps them. Drive the browser by hand from the Automation tab, or have an AI agent call the browser MCP tool with an action — launch, navigate, click, type_text, exec_js, screenshot, get_cookies, and dozens more. Scripts can hit the same surface over the /api/browser/* REST endpoints. The actions below are the ones that change what an attack can reach.

Drive the browser to the interesting state, then work from History. Once the authenticated request is captured, send it to Repeater or the Scanner — you don't re-drive the browser for every test.

The high-value actions

security_override

Drop the browser's own safety rails so a client-side proof-of-concept actually runs: switch off Content-Security-Policy (CSP), X-Frame-Options, HTTP Strict Transport Security (HSTS), Cross-Origin Resource Sharing (CORS) checks, or mixed-content blocking. A reflected payload CSP would have killed, or a framing PoC X-Frame-Options would have blocked, now fires so you can capture the result. It is a deliberate, gated switch — Hugin makes you opt in before it will weaken the browser's trust posture, so it never trips by accident.

block_url / unblock_url

Kill requests by regular-expression pattern before they leave the browser. Point it at an anti-bot vendor's beacon or telemetry endpoint and the page loads without ever phoning home — the fingerprint POST or challenge script never fires. unblock_url lifts the pattern again.

headers_inject

Add headers to every request the browser sends — an X-Forwarded-For, a forged auth header, a custom routing header. Hugin refuses CR/LF/NUL and its own reserved names, so you are injecting headers, not splitting requests.

fetch / fetch_all

Send a request from inside the live browser context, through its cookie jar and TLS fingerprint. Because it carries your real authenticated session and looks like the browser on the wire, a web application firewall (WAF) or anti-bot that blocks a raw HTTP client lets it through. fetch runs one request; fetch_all batches up to 256 URLs in a single call.

network_har / network_stream

Pull everything the browser actually loaded, background API calls included. network_har exports the session as an HTTP Archive (HAR) file you can read or hand off; network_stream tails network events live, bounded by a wait window and an event cap. Good for catching the one background call a SPA makes that never shows up in the page itself.

inject_script

Install a script that runs before any of the page's own JavaScript. Use it to plant taint hooks, spoof a fingerprint, or stub a function the page checks on load — anything that has to be in place before the app boots, not after.

Prove a DOM-XSS sink fires

Finding a sink that looks reachable is not the same as proving your value reaches it. Two browser actions close that gap on a Chrome (CDP) session, where Hugin's sink hooks live — run them against Chrome, not the Hugin Browser's own engine, which has no DOM sink hooks.

taint_inject

Install Hugin's taint hooks before the page's scripts run. They watch every dangerous DOM sink — innerHTML, document.write, eval, and the rest — and flag the moment a value you control reaches one. You drive the page; Hugin tells you where your input lands.

dom_xss_replay_verify

Hand it the page URL, the source value, and your canary. Hugin drives the browser and returns a verdict: executed (your payload fired in the sink), not_observed (it didn't), or browser_error. A hard yes/no instead of "this looks exploitable".

For interactive client-side hunting — watching sources and sinks light up as you click — use DOM Invader.

Get past anti-bot

Anti-bot defences — DataDome, Cloudflare, and the like — block the raw HTTP client, not the real browser. Drive the real browser and the same requests go through. Two MCP tools cover this, alongside the browser actions above.

The antibot tool

batch_fetch

Fire many authenticated requests at once through the browser's own fetch() and cookie jar. They carry your real session and the browser's TLS fingerprint, so a WAF or anti-bot that drops a scripted client lets them through. It stops on the first 403/429 so a block doesn't cost you the whole session.

captcha_detect

Name what's guarding the page — DataDome, GeeTest, hCaptcha, reCAPTCHA, Cloudflare Turnstile, or a generic block page — and whether a datadome cookie is already set. Know what you're up against before you spend effort on it.

cookie_check / monitor

Watch session health while you work. cookie_check tells you whether your cookies still authenticate or have hit a 403/CAPTCHA wall; monitor runs a long scrape across batches, spots a block as it happens, and tries to recover instead of failing the whole run.

The datadome tool

DataDome serves a silent JavaScript interstitial a pure-HTTP client can't pass — its challenge script has to run in a real engine to mint a valid fingerprint.

solve_js

Drive a real Chrome through the interstitial so DataDome's own challenge script runs in a live V8 engine, then harvest the verified datadome cookie into the shared jar. Repeater and every jar-aware tool carry it automatically from then on — solve once, replay at HTTP speed.

verify

Prove a datadome cookie actually clears the target: a Chrome-TLS GET that comes back 200 with no challenge body. Confirms the cookie works and is portable to your pure-HTTP requests.

capture

Mine your captured traffic for DataDome artifacts — the challenge bundle, the fingerprint POST body, the inline var dd= config — and save them so you can reverse-engineer the payload.

detect

Check whether DataDome is challenging a given page before you commit to a solve.

To make the browser look like a real one to these defences in the first place — TLS and JA3/JA4 mimicry — see fingerprinting.

Every action here runs two ways: by hand from the Browser view, or from an AI agent over MCP — the browser actions through the browser tool, the anti-bot work through the antibot and datadome tools. To let an agent chain them into a multi-step flow, see MCP.

Last updated 2026-06-17.