ScanScopeRequest | ScanScopeInsertionPoint).
Overview Diagram
The Three Scopes
ScanScopeInsertionPoint
Invoked once for each parameter (insertion point) in the request. The executor parses the raw HTTP request, extracts every injectable location, and hands them to the module one at a time. The module receives a singleInsertionPoint with a BuildRequest(payload) method to inject its payload at that exact position.
How it works step by step
Given this request:CreateAllInsertionPoints() and finds 5 insertion points:
BuildRequest(payload) to construct the modified request. Only the target parameter changes; everything else stays the same:
| Type | Example | What gets tested |
|---|---|---|
| URL parameter | ?id=123 | The value 123 |
| Body parameter | username=admin | The value admin |
| JSON value | {"user":"admin"} | The value "admin" |
| Cookie | session=abc | The value abc |
| HTTP header | Host: example.com | The value example.com |
| XML element | <id>5</id> | The value 5 |
| XML attribute | <tag attr="val"> | The value val |
| Multipart field | Content-Disposition: name="file" | The field value |
| URL path folder | /api/users/123 | The segment 123 |
| URL path filename | /api/report.pdf | The filename report.pdf |
| Parameter name (URL) | ?id=123 | The key id itself |
| Parameter name (body) | username=admin | The key username itself |
| Entire body | Full POST body | The whole body as one blob |
includeNested=true (the default), the executor also discovers nested structures - for example, a URL parameter whose value is Base64-encoded JSON will produce additional insertion points for each key inside that JSON.
Each module also declares which InsertionPointTypes it accepts (via AllowedInsertionPointTypes()), so an SQLi module might only test URL params, body params, and JSON values, while skipping cookies and headers.
Typical vulnerabilities found:
- SQL injection (error-based, blind)
- Cross-site scripting (XSS)
- Server-side template injection (SSTI)
- Command injection
- Path traversal / LFI
- SSRF
- CRLF injection
- NoSQL injection
- XML/SAML injection
- Insecure deserialization
sqli_error_based, ssti_detection, reflected_ssti, csti_detection, ssrf_detection, lfi_generic, lfi_path_traversal, crlf_injection, nosqli_error_based, nosqli_operator_injection, xml_saml_security, insecure_deserialization, backslash_transformation, suspect_transform, smart_behavior_detection, input_behavior_probe, race_interference, oast_probe (hybrid)
ScanScopeRequest
Invoked once per unique request/response pair. The module receives the entireHttpRequestResponse and decides on its own what to modify. It is not given a specific parameter - it has full control over the request structure.
This scope is used for vulnerabilities that:
- Don’t map to a single parameter (e.g., changing the HTTP method, adding new headers)
- Need cross-parameter context (e.g., comparing timing across multiple params)
- Test request-level properties (e.g., JWT tokens, CSRF tokens, caching behavior)
- Internally manage their own parameter iteration for specialized logic
How it works step by step
Given this request that returns a 403:forbidden_bypass module receives the whole request and tries multiple attack vectors itself:
host_header_injection module tests header reflection:
jwt_vulnerability module manipulates the JWT token:
ScanScopeRequest instead of ScanScopeInsertionPoint.
Typical vulnerabilities found:
- 403/401 bypass (path tricks, method tampering, header injection)
- Host header injection
- Open redirect
- JWT vulnerabilities (algorithm confusion, weak secrets)
- CSRF verification bypass
- Web cache poisoning
- Prototype pollution
- XXE (full-body injection)
- HTTP method override
- Swagger/API documentation exposure
- File upload vulnerabilities
- JSONP callback injection
- Nginx path escape
forbidden_bypass, host_header_injection, open_redirect, jwt_vulnerability, csrf_verify, web_cache_poisoning, prototype_pollution, client_prototype_pollution, xxe_generic, xss_scanner, xss_light_scanner (3 sub-modules), sqli_boolean_blind, sqli_time_based_params, sqli_time_based_header, code_exec, file_upload_scan, swagger_disclose, spring_actuator_misconfig, nginx_path_escape, path_normalization, jsonp_callback, oast_probe (hybrid)
Passive modules using this scope (19):
info_disclosure_detect, secret_detect, cookie_security_detect, cors_headers_detect, content_type_mismatch, dom_xss_detect, csrf_detect, mixed_content_detect, auth_headers_detect, jwt_weak_secret, oauth_facebook_detect, openredirect_params, sensitive_url_params, sourcemap_detect, sql_syntax_detect, serialized_object_detect, crypto_weakness_detect, anomaly_ranking, idor_params_detect
ScanScopeHost
Invoked once per unique host. The executor deduplicates by hostname - if 500 requests arrive forexample.com, the module runs only once. This scope is for expensive one-time checks that apply to the entire host, not to individual pages or parameters.
How it works step by step
Given 500 different requests toexample.com:
ScanScopeHost module only on the first request it sees for that host. The remaining 499 requests are skipped:
- CORS misconfiguration
- Default credentials
- GraphQL introspection enabled
- HTTP request smuggling
- Sensitive file discovery (
.env,.git/config,robots.txt) - Missing security headers
cors_misconfiguration, default_credentials, graphql_scan, http_request_smuggling, sensitive_file_discovery
Passive modules using this scope (1):
security_headers_missing
Hybrid Scope
A module can declare multiple scopes. Currently,oast_probe is the only module that does this:
What Happens With Different Inputs
Full request with parameters
Simple URL with no parameters
Static file URL
URL with path parameters only (REST-style)
JSON API with nested structures
Execution Order
For each incoming request, the executor runs scopes in this order:Choosing a Scope for New Modules
| Question | Recommended Scope | ||
|---|---|---|---|
| Does the vulnerability live in a specific parameter value? | ScanScopeInsertionPoint | ||
| Does it require modifying the request structure (method, path, headers)? | ScanScopeRequest | ||
| Does it need custom parameter iteration logic? | ScanScopeRequest | ||
| Is it a one-time check per target host? | ScanScopeHost | ||
| Does it need both parameter-level and request-level testing? | Combine with ` | (e.g.,ScanScopeRequest | ScanScopeInsertionPoint`) |