Every option. Every check. Explained.

Quick Summary

Web Iron Shield's scan options fall into five groups: scan modes (Normal / AI / Pentest / Bounty), scan profiles (Quick / Normal / Deep / Pentest), check categories (the individual rules), anomaly hunters (weirdness detectors), and network options (proxy, timeouts, rate limits). Below, everything is explained in detail.

Normal Scan vs AI Scan

The single most important choice when starting a scan. Both modes run the same underlying checks — the AI mode adds a reasoning layer on top. It does not replace the Normal scan; it extends it.

Aspect	Normal Scan	AI Scan
Speed	~3 min (Quick profile)	~8 min (Quick profile)
Cost per scan	$0	~$0.05 (your Anthropic API key)
Signature checks	150+	150+ (same as Normal)
Anomaly hunters	10 (runs all)	10 + AI review of findings
Business logic	No — rules only	Yes — understands app purpose
Exploit chains	No — each finding standalone	Yes — chains low-severity into critical
Custom PoCs	Generic payloads	App-specific payloads
Bounty estimates	Rough (rule-based)	Precise (HackerOne/Bugcrowd patterns)
External API calls	None (100% offline)	Sends scan data to Anthropic
Deterministic	Yes — same input → same output	No — AI reasoning varies

When Normal mode finds more than AI

Normal mode is exhaustive on known patterns. If a bug matches a rule, Normal will find it — every time. AI reasoning can sometimes miss signature-matchable bugs if it's distracted by business logic. That's why AI mode always runs Normal checks underneath.

When AI mode finds more than Normal

AI shines on custom apps where bugs are about what the app does, not about how it's coded:

• An endpoint called /api/transfer that doesn't check if the source account belongs to the authenticated user
• A password reset flow that reuses the same token across emails
• A file upload that trusts the client's declared MIME type
• An admin panel that authenticates via a cookie the client can forge

Rules can't catch these because "doesn't check ownership" isn't a pattern — it's a logic gap. AI reads the endpoint, understands the purpose, and tests the contract.

Scan Modes

Normal Scan FREE TIER + PRO

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).

AI Scan (Claude-powered) PRO REQUIRES API KEY

What it does: Everything a Normal scan does, plus a reasoning layer powered by Claude. The AI reads discovered pages, understands what the app is trying to do, and tests the intent — not just the code. Particularly effective on custom SaaS, APIs, and authentication-heavy apps.

When to use: Bug bounty hunting, custom-built application audits, any target where business logic matters more than code patterns.

What it adds over Normal:

• Business logic flaws — broken authentication, missing authorization checks, IDOR, race conditions in business workflows
• Exploit chaining — spots when 2 or 3 low-severity findings combine into something critical
• Custom payloads — generates PoCs tailored to the app's input format, not generic XSS/SQLi blanks
• Bounty prioritization — estimates payout ranges based on known program patterns
• Natural-language summaries — a narrative explanation of each finding suitable for client reports

Setup: Get an Anthropic API key at console.anthropic.com, paste it into Settings → AI Provider, tick Use AI for scan.

Cost: Roughly $0.02 to $0.10 per scan depending on target size. All billed directly to your Anthropic account — Web Iron Shield doesn't upcharge.

Active Pentest Mode PRO NORMAL OR AI

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, and 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.

Bug Bounty Mode PRO BEST WITH AI

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)

Scan Profiles

Profiles control how much the scanner tests — how many pages to crawl, how deep to go, how many parameters to fuzz. Every profile runs the same types of checks; they differ in coverage.

Quick Profile FREE + PRO

• 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.

Normal Profile FREE + PRO

• 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.

Deep Profile PRO

• 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.

Pentest Profile PRO

• 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.

Check Categories

The 150+ rule-based checks break down into 10 categories. Every scan runs every category — you can't disable individual checks, because picking-and-choosing creates blind spots.

Injection Attacks CRITICAL

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

• 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

Example detection — SQL Injection
[CRITICAL] SQL injection in param 'id' on /products/view
Payload: 1' AND 1=CONVERT(int,(SELECT @@version))--
Response: Conversion failed when converting nvarchar 'Microsoft SQL Server 2019...'

XSS Family HIGH

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

• 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)

Authentication HIGH

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

• 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

Access Control CRITICAL

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.

• 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

Cryptography & TLS MEDIUM

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

• 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)

Security Headers LOW to MEDIUM

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

• 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)

Cookie Security MEDIUM

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

• 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

CORS & CSRF HIGH

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

• 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

Sensitive Files & Endpoints CRITICAL when hit

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

Path	Why it's dangerous if exposed
.env	Contains DB passwords, API keys, JWT secrets
.git/config	Full source code history clonable via git
.DS_Store	Lists files in directory (macOS metadata leak)
wp-config.php.bak	WordPress DB credentials in plaintext
backup.sql	Entire database dump
phpinfo.php	Server internals, env vars, PHP paths
composer.lock	Exact package versions → CVE targeting
.htpasswd	Hashed credentials for basic auth

CVE Database VARIES

Fingerprints server and framework versions, then matches against known CVEs (21+ CVE checks). 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

Example finding
[CRITICAL] CVE-2021-41773 — Apache Path Traversal & RCE
Detected: Apache/2.4.49 (from Server header)
CVSS: 9.8 — public exploit available

Anomaly Hunters — detailed

Ten hunters that flag suspicious behaviour rather than matching specific signatures. Each runs independently during Phase 4 of every scan.

01. Stack Traces & Debug Output HIGH

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 finds
[HIGH] PHP stack trace leaked on /search?q=%00
Fatal error: Uncaught PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'appdb.serch_log' doesn't exist in /var/www/html/includes/db.php:47

02. Filesystem Path Disclosure MEDIUM

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.

03. Suspicious Response Headers LOW

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.

04. Dangerous HTTP Methods HIGH

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.

05. Default Installation Pages MEDIUM

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.

06. Debug & Admin Endpoint Probing CRITICAL when hit

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.

07. HTTP Parameter Pollution (HPP) LOW

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.

08. Content-Type Mismatches LOW to MEDIUM

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.

09. Login Timing Oracles MEDIUM

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.

10. Parameter Reflection Surfaces HIGH

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.

Verify Now — 9 Verifiers

After a scan finds something, clicking "Verify Now" on any finding invokes a category-specific verifier that actively tries to exploit the finding and produces hard evidence.

Command Injection Verifier

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%.

SQL Injection Verifier

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.

XSS Verifier (Context-Aware)

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).

Path Traversal / LFI Verifier

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.

Open Redirect Verifier

How it confirms: Injects an external URL into redirect parameters (?redirect=, ?url=, ?next=, ?return_to=). Follows the response and checks if the 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.

CORS Verifier

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.

Security Headers Verifier

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.

Exposed Files Verifier

How it confirms: For any sensitive file finding, downloads the file and checks if the content matches the 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.

Cookie Flags Verifier

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).

Network Options

HTTP / HTTPS Proxy

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 it can be disabled for MITM proxy workflows (Burp).

SOCKS5 / Tor

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.

Proxy Authentication

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

Format: http://username:[email protected]:8080

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

Request Timeouts

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 you want to finish quicker — 5s catches anything responsive.

Rate Limiting

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 backs off automatically when they spike.

Advanced Options

Authenticated Scanning

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.

Custom Headers

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

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

X-API-Key: your-key-here
X-Tenant-Id: 12345
X-Scanner: WebIronShield (authorized scan)

Scope & Exclusions

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)