Every option. Every check. Explained.

What it does: Runs all 150+ rule-based signature checks, executes the 10 anomaly hunters, and verifies findings with the 9 exploit verifiers. No external API calls.

When to use: Daily checks, CI/CD integration, quick smoke tests, any target where you want fast, deterministic results.

Output: Findings list with severity, description, affected URL/parameter, and remediation notes. Each finding can be verified on-demand with Verify Now.

Typical runtime: 3 minutes (Quick), 15 minutes (Normal), 45 minutes (Deep), 2–4 hours (Pentest).

What it does: Enables Phase 3 of the scan pipeline — sends real (but safe) exploit payloads to confirm exploitability. Includes XXE injection, JWT weakness testing, IDOR probes, OS command injection, SSRF tests.

When to use: Pre-production audits, any engagement where you have explicit authorization to test actively. Never on third-party targets without permission.

Why it's separate: Active pentest payloads are more intrusive than passive checks. They're designed to be non-destructive (echo canaries, sleep timings, SELECT-only SQL), but they still hit the target with exploit-like traffic that a WAF will see. Keeping this mode opt-in protects you from accidentally running aggressive tests.

Authorization wall: Before Phase 3 runs, the scanner prompts you to confirm ownership and supply an owner email. This gets logged to the audit trail with timestamp + your IP.

What it does: A wrapper mode that tunes scanner behaviour for bounty workflows. Enables payout estimation on every finding, generates reports pre-formatted for HackerOne / Bugcrowd / Intigriti, and flags findings that hit sweet spots (authentication flaws, IDOR, RCE — the payout headliners).

When to use: You're hunting on a bounty program you're authorized for, and you want the scanner prioritizing high-payout findings over low-severity noise.

Output differences:

• Every finding shows estimated payout range (e.g. "$250 – $2,000 based on HackerOne medium-severity SQL injection reports")
• Findings sorted by expected payout, not just severity
• Report export buttons for each major platform
• Duplicate-detection warnings (if a finding looks like a commonly-reported bug pattern)

Crawl scope: 10 pages, depth 2 (homepage → links → links' links)

Parameters fuzzed: Up to 20 unique params

Runtime: ~3 minutes

Best for: Smoke tests, CI/CD pipelines, daily health checks on production. If this scan finds nothing, your site is probably okay for common bugs — but doesn't prove deep coverage.

Crawl scope: 50 pages, depth 3

Parameters fuzzed: Up to 80 unique params

Runtime: ~15 minutes

Best for: Weekly checks on staging, pre-release gates. Good balance between coverage and speed.

Crawl scope: 200 pages, depth 5

Parameters fuzzed: Up to 300 unique params

Runtime: ~45 minutes to 1 hour

Best for: Pre-production audits, before major releases. Deep enough to reach "hidden" pages and API endpoints that Quick misses.

Crawl scope: 500 pages, depth 10

Parameters fuzzed: All unique params discovered

Runtime: 2 to 4 hours

Best for: Full bug-bounty hunts, authorized engagements where time is not a constraint. Will explore every corner of the app. Combine with AI mode for maximum coverage.

Any place where user input gets mixed with code or queries. If an attacker can sneak in their own code, they own the server.

Subcategories

• SQL Injection — 14 database types detected, error-based, boolean-based, and time-based blind techniques
• OS Command Injection — Unix and Windows payload sets, canary reflection + time-based blind
• Server-Side Template Injection (SSTI) — Jinja2, Twig, ERB, Freemarker, Velocity template engine detection
• LDAP Injection — Authentication bypass via LDAP filter manipulation
• XPath Injection — XML-based query manipulation
• NoSQL Injection — MongoDB, CouchDB operator injection
• XXE (XML External Entity) — XML parsers accepting external DTDs

Cross-site scripting: attacker-controlled JavaScript executing in another user's browser. Ranges from session theft to full account takeover.

Subcategories

• Reflected XSS — Input in URL reflected unescaped in response
• Stored XSS — Input saved to backend, rendered later (detected via canary + crawler replay)
• DOM-based XSS — Input processed by JavaScript and written to DOM unsafely (pattern matching on JS source)
• Context-aware payloads — Different payloads for HTML body, attribute, JS string, event handler, inside <script>
• Filter bypass — Tests common WAF bypass techniques (case variation, encoding, comment injection)

Everything to do with login, session, and identity. Weak authentication is one of the highest-impact vulnerability classes.

Subcategories

• JWT weakness — None algorithm, weak secrets (brute-force test with common keys), algorithm confusion attacks
• Session fixation — Session ID not regenerated after login
• Insecure session cookies — Missing HttpOnly, Secure, SameSite flags
• Password reset flaws — Token predictability, token reuse, email enumeration
• Brute-force protection — Rate limiting on login endpoints
• Default credentials — admin/admin, root/root on discovered admin panels

Can user A access user B's data? Can anyone access admin functions? Access control bugs are bounty gold because they're often trivially exploitable.

Subcategories

• IDOR (Insecure Direct Object Reference) — Sequential IDs in URLs that aren't checked against the requesting user
• Missing authorization — Admin endpoints accessible without admin role
• Path traversal — ?file=../../etc/passwd style attacks, 5 bypass payloads tested
• Horizontal privilege escalation — User A reads User B's resources
• Vertical privilege escalation — Regular user performs admin action

How the site handles data in transit and at rest. Mistakes here often affect every user at once.

Subcategories

• TLS configuration — Weak ciphers, old protocols (SSLv3, TLS 1.0/1.1), invalid/expired certs
• Mixed content — HTTPS page loading HTTP resources
• HSTS enforcement — Whether strict-transport-security is set
• Weak hashing detection — MD5/SHA-1 in response headers or cookies
• Certificate transparency — Cert logged in CT logs (public disclosure)

Browser-side defenses the site can opt into. Missing these doesn't directly cause a bug, but makes existing bugs much easier to exploit.

Headers checked

• Strict-Transport-Security — Forces HTTPS for future requests
• Content-Security-Policy — Restricts what scripts can execute (huge XSS mitigation)
• X-Content-Type-Options: nosniff — Prevents MIME sniffing attacks
• X-Frame-Options — Clickjacking protection
• Referrer-Policy — Controls what Referer header sends
• Permissions-Policy — Disables unused browser APIs (camera, mic, geolocation)

Flags on session cookies, especially. Missing flags are trivial XSS/session-hijack amplifiers.

Flags checked

• HttpOnly — JavaScript can't read the cookie (blocks XSS session theft)
• Secure — Cookie only sent over HTTPS
• SameSite — Cookie not sent on cross-site requests (CSRF protection)
• Domain scope — Cookie scoped too broadly (e.g. .example.com when only app.example.com needs it)
• Path scope — Similar check for path attribute
• Max-Age / Expires — Session cookies lasting weeks instead of hours

Cross-origin policies. Misconfiguration here means any website can act on behalf of your users.

Subcategories

• CORS misconfiguration — Reflecting Origin header into Access-Control-Allow-Origin with credentials enabled (allows any site to read authenticated data)
• Null origin accepted — Origin: null is honored (trivial bypass)
• Wildcard with credentials — Browsers block this but some servers still try to set it
• CSRF token presence — State-changing endpoints (POST/PUT/DELETE) accepting requests without anti-CSRF tokens
• SameSite cookie defense — If SameSite=Strict/Lax is set, CSRF is mitigated; check for this

Files that should never be web-accessible but frequently are. 120+ paths probed.

Example paths probed

Fingerprints server and framework versions, then matches against known CVEs. Finds vulnerabilities that already have public exploits available.

How fingerprinting works

1. Read Server:, X-Powered-By:, and framework-specific headers
2. Check paths like /readme.html, /CHANGELOG.md, /composer.lock for version strings
3. Cross-reference with NVD feed
4. Report any matching CVEs with CVSS score, description, and linked exploit databases

What it does: Looks for stack traces, error messages, and debug output across PHP, Python, Java, Ruby, .NET, Node.js, and Go. Also triggers errors by sending malformed input (null bytes, unterminated brackets, apostrophes).

Why it matters: Stack traces leak source file paths, framework versions, database queries, and internal variable names. Attackers use these to pick the right exploit.

What it does: Scans response bodies for absolute filesystem paths. Catches /var/www/..., /home/user/public_html/..., Windows C:\inetpub, Docker /app/....

Why it matters: Knowing the filesystem layout is critical for LFI/path-traversal exploitation. If your site leaks the paths and has a path-traversal bug, exploitation is trivial.

What it does: Flags headers that leak implementation details or indicate debug/staging environments: X-Powered-By, Server (versioned), X-AspNet-Version, X-Environment: dev, X-Debug-Mode.

Why it matters: Version headers = direct CVE targeting path. Debug headers = forgot to disable before production.

What it does: Tests whether the server accepts PUT, DELETE, TRACE, PATCH, CONNECT on discovered endpoints.

Why it matters: A 200 OK on PUT /shell.php is a potential webshell upload. TRACE echoing the request body is a classic XST (cross-site tracing) vector that bypasses HttpOnly cookies.

What it does: Checks for the "hello world" pages that ship with servers: Apache's "It works!", Nginx welcome, IIS default, Tomcat examples, Plesk panels, Webmin, phpMyAdmin login.

Why it matters: These pages often come with default credentials. An exposed phpMyAdmin is one step away from database takeover if admin/password still works.

What it does: Probes 40+ known-dangerous endpoints — /actuator/env, /actuator/heapdump, /.git/HEAD, /.env, /composer.lock, /phpmyadmin, /server-status, /debug.

Why it matters: Each of these is a full disclosure in itself. A Spring Actuator endpoint can leak your entire environment config including DB passwords. A heapdump is literally every runtime object in memory.

What it does: Sends duplicate parameters (?x=A&x=B) and compares server behaviour. Flags when the server treats duplicates differently than single values.

Why it matters: Backends and WAFs often disagree on which duplicate to use — the WAF checks the first, the backend reads the last. This lets attackers smuggle payloads past filters.

What it does: Detects when response bodies don't match their declared Content-Type. JSON served as text/html, XML served as text/plain, JavaScript served as text/html.

Why it matters: Browsers will attempt to render JSON as HTML if the Content-Type says so, turning any attacker-controlled string in a JSON response into XSS.

What it does: Sends login attempts with a known-good username (admin) vs a random nonsense username, and compares response times across multiple samples.

Why it matters: If the app hashes the submitted password only when the user exists (short-circuiting on unknown users), a 200ms+ timing difference reveals which usernames are valid. Combined with a password-spray attack, this is an account-takeover pipeline.

What it does: Sends a unique marker into every query parameter and form field, then searches the response to see if it appears anywhere. Reports where input reaches output, even if not directly exploitable.

Why it matters: A reflection isn't an XSS bug on its own, but finding which params reach output tells you where to focus manual XSS testing. If the marker lands in a dangerous context (inside a <script> tag or an event handler attribute), severity bumps up automatically.

How it confirms: Sends canary-echo payloads (; echo WISCMD<random>) and also time-based blind (; sleep 5). Unix and Windows payload sets both tested.

Confidence bumps: Canary appears in response body → 95%. Response delay matches sleep duration → 90%. Both present → 99%.

How it confirms: Three channels, run in order — error-based (14 DB error signature types), boolean-based (' OR '1'='1 vs ' OR '1'='2 response size comparison), and time-based blind (DB-specific sleep payloads for MySQL, PostgreSQL, MSSQL, Oracle, SQLite).

Why three channels: Error-based only works if the app leaks DB errors. Boolean works if responses differ between true/false conditions. Time-based works even when output is fully suppressed.

How it confirms: Sends 5 payloads targeting different contexts — HTML tag body, attribute value, JavaScript string, event handler, inside <script>. Each payload includes a unique canary.

Verdict logic: If the full payload reflects unencoded → VULNERABLE (high confidence). If only the canary reflects (payload partially encoded) → LIKELY_VULNERABLE (medium confidence, manual check recommended).

How it confirms: Sends 5 bypass payloads (../, URL-encoded, double-encoded, null byte, absolute path). Looks for content signatures of /etc/passwd, win.ini, /etc/hosts.

Content signature matching: Watches for strings like root:x:0:0: (passwd format) or [fonts] (win.ini structure) in the response. Presence = confirmed LFI.

How it confirms: Injects an external URL into redirect parameters (?redirect=, ?url=, ?next=, ?return_to=). Follows the response and checks if Location header points to the external host.

Bypass testing: Tests common filter bypasses — double slashes (//evil.com), protocol-relative URLs, URL-encoded schemes, whitelist trust bugs.

How it confirms: Sends requests with different Origin headers (evil.com, null, subdomain.evil.com, app.com.evil.com) and checks if the server reflects them into Access-Control-Allow-Origin with credentials enabled.

Worst-case: Arbitrary origin reflection + Access-Control-Allow-Credentials: true = any site can read authenticated data. That's a critical finding.

How it confirms: Checks all 6 major security headers (HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy) and analyzes their values — not just presence.

Value analysis: A CSP of default-src * is worse than no CSP at all. HSTS with max-age=10 is effectively useless. The verifier flags weak values, not just missing ones.

How it confirms: For any sensitive file finding, downloads the file and checks if the content matches expected format (is it a real .env? Does .git/HEAD contain a ref?). Prevents false positives from 200-but-not-really-there custom 404 pages.

How it confirms: Re-requests the endpoint, parses Set-Cookie headers, and reports exactly which flags are missing on which cookies. Distinguishes session cookies (high-value) from functional cookies (lower priority).

What it does: Routes all scanner traffic through a specified HTTP proxy. Useful for testing through Burp Suite, capturing all requests for debugging, or scanning from a different geographic location via a remote proxy.

Configuration: Settings → Proxy → http://proxy.example.com:8080

TLS behaviour: The scanner preserves TLS verification by default, but can be disabled for MITM proxy workflows (Burp).

What it does: Routes all traffic through a SOCKS5 proxy. The primary use case is Tor (127.0.0.1:9050) for anonymity during authorized bounty research.

IP leak detection: During scan start, the scanner queries a public IP service through the proxy and compares against your direct IP. If they match, you get a red warning — your proxy isn't working.

Configuration: socks5://127.0.0.1:9050 for Tor Browser's bundled Tor.

What it does: Inline credentials in the proxy URL for authenticated proxies.

Format: http://username:password@proxy.example.com:8080

Security: Credentials are stored encrypted in the local settings file (AES-256 with user's machine ID as key).

Default: 15 seconds per request.

When to increase: If the target is slow or behind strict rate limiting, the default timeout can produce false negatives (scanner thinks endpoint doesn't exist when it's just slow). Increase to 30–60s for such targets.

When to decrease: If scanning fast targets and want to finish quicker — 5s catches anything responsive.

Default: 10 requests per second.

Why it matters: Aggressive scanning can trigger WAF rate limits or DoS-protect systems, blocking your IP and invalidating the whole scan. Slow mode (1 req/s) is polite but slow. Fast mode (50+ req/s) is thorough but risky.

Adaptive mode: With Settings → Adaptive Rate enabled, the scanner monitors response times and back-offs automatically when they spike.

What it does: Logs into the target app before scanning, so the crawler reaches authenticated-only pages and the checks run against logged-in state.

Methods supported:

• Cookie-based — Paste the session cookie from your browser
• Form-based — Give the login URL + username/password, scanner performs login
• Bearer token — For API scanning, paste the Authorization header
• Basic Auth — For admin-panel-style authentication

Session refresh: The scanner detects when a session expires (401/redirect to login) and re-authenticates automatically.

What it does: Adds custom headers to every scan request. Useful for API keys, tenant selectors, CSRF tokens that must be present.

Format: Key-value pairs in Settings → Custom Headers:

What it does: Controls which URLs the scanner will and won't test.

Scope rules:

• Include subdomains — by default only the target hostname is scanned; enable to crawl *.example.com
• Exclude URL patterns — regex patterns to skip (e.g. /logout, /unsubscribe, /delete)
• File type exclusions — skip images, PDFs, videos to save scan time
• Parameter blocklist — don't fuzz certain params (useful for tracking params like utm_source)

Why exclusions matter: Scanning /logout will log your scanner out of authenticated scans. Scanning /delete-account is self-explanatory.