Environments are named sets of variables — like dev, staging, prod — that you can switch between with one click. Variables are referenced as {{env.varname}} anywhere Hugin templates work: Repeater requests, Workflow action values, Macro inputs, Match & Replace patterns, Intruder payload templates.
Plus an auto-extract subsystem that pulls values out of HTTP responses into env variables automatically.
🔗Why Environments?
The same engagement often spans multiple environments — a staging instance with weak auth, a prod instance with strict CSRF, a developer instance with debug routes. Instead of editing a dozen requests when you switch, define {{env.api_base}} once and let the variable do the work.
Common variables to keep per env:
api_base— the base URLadmin_token,user_token,guest_token— auth tokenscsrf_token— extracted from the latest login responseaccount_id— your test accountvictim_id— the IDOR target
🔗Creating an Environment
- Open Environment view
- + New Environment → name it (e.g.
staging) - Add variables one by one or paste a
KEY=VALUEblock in bulk - Mark Active to make this the current environment
Only one environment is active at a time. The variable resolver checks active env first; if a variable isn’t there, it falls back to a project-default env if set.
🔗Variable Types
- String (default) — plain text
- Secret — masked in the UI, encrypted at rest. Useful for tokens, credentials. Reveal-on-hover behind a click guard.
- Number — typed as integer
- JSON — parsed and exposed; reference nested fields with
{{env.config.timeout}}
🔗Auto-Extract Rules
The Auto-Extract tab defines rules that watch incoming responses and extract values into env variables on match:
- Trigger — host/path/method match
- Source — header / cookie / body
- Pattern — regex with one capture group, or JSONPath, or fixed cookie name
- Target variable — env var to write into
Example rule:
Trigger: POST https://api.example.com/auth/login
Source: response body
Pattern (JSONPath): $.access_token
Target: env.access_token
Now any 200 response from POST /auth/login automatically populates env.access_token. Repeater, Intruder, Macros — all use the freshest token without manual updates.
🔗Apply Action
The Apply action manually runs all matching auto-extract rules against a specific captured flow. Useful when you want to backfill from an existing flow without re-issuing the request.
🔗Templating Reference
{{env.varname}} works in:
- Repeater request URL, headers, body
- Intruder positions and target URL
- Macro step requests
- Workflow action values
- Match & Replace patterns and replacements
- Match & Replace and Intercept Rules condition values
Special namespaces:
{{env.varname}}— current env’s variable{{env.<name>.varname}}— explicit env-by-name (overrides active selection for this template)
🔗Quick-Use Patterns
🔗Auth token rotation
Define {{env.access_token}}. Add an auto-extract rule on your auth endpoint. Use Authorization: Bearer {{env.access_token}} in Repeater. Re-login flow updates the token automatically; subsequent requests pick up the new value.
🔗Multi-env A/B
Define staging and prod envs with different api_base values. Switch active env to compare same request behaviour across environments. Combine with Comparer for response diffing.
🔗CSRF refresh
Auto-extract CSRF tokens from any GET response. Reference {{env.csrf_token}} in subsequent POST requests. As you browse, the token always reflects the latest captured value.
🔗MCP
The environment MCP tool exposes:
Environments:
create_env— new named environmentdelete_env— remove an environmentactivate— make an environment activeexport— export environment(s)
Variables:
get— read a variableset— set a variable (optional secret flag)delete— remove a variable
Auto-extract rules:
list_rules,add_rule,update_rule,remove_ruleextract— apply rules to a stored flow
Source/target helpers (response_header, set_cookie) are sub-action shortcuts for common rule shapes.