@waftester/cli

Cancel a running async task. Use this to stop a long-running scan, assess, bypass, or discover operation that is no longer needed. USE THIS TOOL WHEN: • The user wants to stop a running task • A task is taking too long and you want to abort it • The user has changed their mind about what to test Only running/pending tasks can be cancelled. Completed or failed tasks cannot be cancelled. EXAMPLE: {"task_id": "task_a1b2c3d4e5f6g7h8"}

List all async tasks with their status and progress. Use this to see what's running, completed, or failed. USE THIS TOOL WHEN: • You want to see all running tasks • You lost track of a task_id (e.g., after reconnecting or session reset) • You want to check if any tasks are still running before starting new ones • You need to recover a task_id from a previous session OPTIONAL FILTERS: • status: filter by task status ("running", "completed", "failed", "cancelled") • tool_name: filter by which tool started the task ("scan", "assess", "bypass", "discover", "scan_spec", "discover_bypasses", "event_crawl") • If omitted, returns all tasks EXAMPLES: {} or {"status": "running"} or {"tool_name": "assess"} or {"status": "running", "tool_name": "scan"}

Browse the catalog of registered tamper techniques — sqlmap-compatible payload transformations for WAF bypass. Each tamper rewrites attack payloads using SQL tricks, encoding transformations, whitespace substitutions, or WAF-specific bypasses. This tool lists them WITHOUT sending any network traffic. USE THIS TOOL WHEN: • The user asks "what tampers are available?", "list tamper techniques", or "show bypass methods" • You need to understand what a specific tamper does before using it • Planning which tamper to use with 'discover_bypasses' or in CLI --tamper flag • You want to filter tampers by category (encoding, space, sql, waf, etc.) or WAF vendor tag DO NOT USE THIS TOOL WHEN: • You want to TEST tampers against a live target — use 'discover_bypasses' instead • You want encoding-based mutations (URL, hex, Unicode) — use 'mutate' instead • You want mutation-matrix bypass testing — use 'bypass' instead CATEGORIES: encoding, space, sql, mysql, mssql, waf, http, obfuscation EXAMPLE INPUTS: • List all: {} • SQL tampers only: {"category": "sql"} • WAF-specific bypasses: {"category": "waf"} • Tampers for Cloudflare: {"for_waf": "cloudflare"} • MySQL-specific: {"category": "mysql"} Returns: tamper count, per-category breakdown, tamper list with name/description/category/tags.

Parse an API spec, auto-select attacks using the intelligence engine, and execute a security scan. USE when: - You have an API spec and want to run a full security scan - You want spec-driven attack selection (smarter than manual category selection) - You need findings mapped back to specific endpoints and parameters DON'T USE when: - You want a single-URL scan without a spec — use scan instead - You just want to see the plan — use plan_spec instead - You want to validate the spec — use validate_spec instead Supported formats: OpenAPI 3.x, Swagger 2.0, Postman Collection v2.x, HAR 1.2, GraphQL, gRPC, AsyncAPI 2.x. Example: {"spec_content": "<spec>", "target": "https://api.example.com", "intensity": "deep", "dry_run": true} Result format: JSON with findings, endpoint results, attack summary, and scan duration.

Encode a payload string into WAF-evasion variants — URL, double-URL, Unicode, HTML hex. Offline encoding, no network traffic. USE THIS TOOL WHEN: • A payload was blocked and the user wants to see how it looks in different encodings • The user says "encode this", "mutate this payload", or "show me evasion variants" • Inspecting what the mutation matrix would produce before testing live with 'bypass' • Preparing payloads for manual testing in Burp Suite or curl DO NOT USE THIS TOOL WHEN: • You want to also TEST the mutations against a WAF — use 'bypass' instead (it mutates AND tests) • You want to scan a target — use 'scan' instead • You want to browse the payload catalog — use 'list_payloads' instead 'mutate' vs 'bypass': mutate is offline — it shows you what the encodings look like. bypass is online — it encodes AND fires them at a target to find what passes. mutate = preview, bypass = execute. EXAMPLE INPUTS: • URL-encode a SQLi payload: {"payload": "' OR 1=1--", "encoders": ["url"]} • Try multiple encodings: {"payload": "<script>alert(1)</script>", "encoders": ["url", "double_url", "unicode", "html_hex"]} • All available encoders: {"payload": "{{7*7}}"} • HTML hex encoding: {"payload": "<img src=x onerror=alert(1)>", "encoders": ["html_hex"]} AVAILABLE ENCODERS: url, double_url, unicode, html_hex If encoders is omitted, ALL are applied. Returns: list of {encoder, encoded_payload} pairs ready for copy-paste testing.

Inventory tool — browse the local attack payload catalog WITHOUT sending any traffic. USE THIS TOOL WHEN: • The user asks "what payloads/categories/attacks do you support?" • You need to check how many payloads exist for a category before running 'scan' • You want to show the user sample payloads for a specific attack type • Planning which categories to include in a scan or assessment DO NOT USE THIS TOOL WHEN: • You want to actually TEST a target — use 'scan' instead • You want WAF bypass testing — use 'bypass' instead • You want to encode/mutate a specific payload — use 'mutate' instead This is a READ-ONLY local operation. Zero network requests. Instant results. EXAMPLE INPUTS: • See everything: {} (no arguments) • Browse SQL injection payloads: {"category": "sqli"} • Only critical XSS payloads: {"category": "xss", "severity": "Critical"} • High+ severity across all categories: {"severity": "High"} CATEGORIES:

Fingerprint the WAF/CDN vendor protecting a target. This is step 1 of any engagement — run it FIRST. USE THIS TOOL WHEN: • Starting any new target — ALWAYS detect the WAF before scanning or bypassing • The user asks "what WAF is protecting this site?" • You need vendor-specific bypass hints before running 'bypass' or 'scan' • Verifying whether a target even has a WAF in front of it DO NOT USE THIS TOOL WHEN: • The user already told you the WAF vendor (skip straight to 'scan' or 'bypass') • You want full attack surface mapping — use 'discover' instead • You want TLS/header/infra details without WAF focus — use 'probe' instead Sends ~20 benign probes + ~5 trigger requests. Very low impact. Takes 10-30 seconds. Covers 26+ WAF vendors with header analysis, behavioral probing, and TLS fingerprinting. EXAMPLE INPUTS: • Basic detection: {"target": "https://example.com"} • With custom timeout: {"target": "https://slow-site.com", "timeout": 30} Returns: vendor name, confidence %, detection method, CDN info, and bypass tips. Known vendors: Cloudflare, AWS WAF, Azure WAF, Akamai, Imperva, ModSecurity, Coraza, F5 BIG-IP, Fortinet, Barracuda, Sucuri, Google Cloud Armor, Wallarm, and more. TYPICAL WORKFLOW: detect_waf → discover → learn → scan → bypass

Validate an API specification file for correctness and completeness. USE when: - You have an API spec (OpenAPI, Swagger, Postman, HAR) and want to check it before scanning - You need to verify a spec parses correctly - You want to see validation warnings and errors with line numbers DON'T USE when: - You want to actually scan — use scan_spec instead - You want to list endpoints — use list_spec_endpoints instead Supported formats: OpenAPI 3.x (YAML/JSON), Swagger 2.0 (YAML/JSON), Postman Collection v2.x (JSON), HAR 1.2 (JSON), GraphQL (introspection), gRPC (reflection), AsyncAPI 2.x (YAML/JSON). Example: {"spec_content": "openapi: \"3.0.0\"\ninfo:\n title: My API\n version: 1.0\npaths:\n /users:\n get:\n summary: List users"} Result format: JSON with fields: valid (bool), format (string), endpoint_count (int), warnings ([]string), errors ([]string).

Parse an API specification and list all endpoints with their methods, parameters, and auth requirements. USE when: - You want to see what endpoints are in a spec before scanning - You need to understand the API surface area - You want to filter by group or path DON'T USE when: - You want to validate the spec — use validate_spec instead - You want to scan — use scan_spec instead Supported formats: OpenAPI 3.x, Swagger 2.0, Postman Collection v2.x, HAR 1.2, GraphQL, gRPC, AsyncAPI 2.x. Example: {"spec_content": "<yaml or json spec>", "group": "users"} Result format: JSON array of endpoints with method, path, parameters, auth, tags.

Parse an API specification and generate an intelligent scan plan using 8 analysis layers. USE when: - You want to see what attacks would be selected before scanning - You want to understand the intelligence engine's analysis - You need a dry-run preview of the scan DON'T USE when: - You want to execute the scan — use scan_spec instead - You just want to list endpoints — use list_spec_endpoints instead The intelligence engine analyzes: parameter types, parameter names, endpoint paths, auth context, schema constraints, content-type mutations, method confusion, and cross-endpoint correlations. Example: {"spec_content": "<spec>", "intensity": "deep"} Result format: JSON with entries (attack plan), total_tests, priority breakdown, and category summary.

Compare current scan findings against a saved baseline to detect regressions, fixes, and new findings. USE when: - You want to diff two scan results to see what changed - You need to detect regressions after making changes - You want to verify fixes Result format: JSON with fixed, regressed, new, unchanged arrays and counts.

Preview what a scan would do without sending any requests. Shows endpoints to test, attack types per endpoint, estimated payload counts, and total request budget. USE when: - You want to see what will be tested before committing to a scan - You need to estimate how long a scan will take - You want to filter by group or intensity first Result format: JSON with entries (endpoint, attack category, payload count), total_tests, estimated_duration.

Analyze an API specification to identify security-relevant patterns, attack surface, and recommended scan configuration. USE when: - You want to understand what makes this API interesting from a security perspective - You need to decide which scan types to focus on - You want parameter-level analysis (names that suggest injection, auth patterns, etc.) Result format: JSON with attack_surface, auth_analysis, parameter_insights, recommended_scan_types.

Extract and describe all authentication schemes declared in an API specification. USE when: - You need to understand what auth the API expects - You want to configure auth tokens before scanning - You need OAuth flow details (token URLs, scopes) Result format: JSON with schemes array, each containing name, type, details, and per-endpoint auth requirements.

Parse an API specification and export the normalized internal representation. Useful for debugging spec parsing, or for piping into other tools. USE when: - You want to see how WAFtester interprets a spec - You need to verify endpoints were parsed correctly - You want the spec in WAFtester's normalized format Result format: JSON with the normalized Spec object (endpoints, servers, auth, metadata).

Turn discovery results into a prioritized test plan. This is the brain between 'discover' and 'scan'. USE THIS TOOL WHEN: • You just ran 'discover' and need to generate a smart test plan • The user wants an intelligent, endpoint-aware scan (not just blind payload spraying) • You want to prioritize which endpoints to test first based on risk DO NOT USE THIS TOOL WHEN: • You want to scan a single known URL — use 'scan' directly with a category • You haven't run 'discover' yet — run that first to get the input JSON • You want WAF metrics/grades — use 'assess' instead Takes raw discovery JSON and produces: endpoint-to-attack mappings, priority rankings (P1 auth/injection through P5 fuzzing), injection point identification (query, body, headers, cookies), custom payload selection per endpoint, and optimal concurrency settings. EXAMPLE INPUTS: • From discovery output: {"discovery_json": "<paste raw JSON from discover tool>"} The input MUST be the raw JSON string output from the 'discover' tool. Pass it as a string, not an object. Returns: test groups, endpoint tests, priorities, category mappings, recommendations. TYPICAL WORKFLOW: detect_waf → discover → learn → scan

Browse the bundled template library — policies, overrides, workflows, Nuclei bypass/detection templates, output formats, and report configs. USE THIS TOOL WHEN: • The user asks "what templates do you have?" or "show me available policies" • You need to find the right template name before using it in a scan or workflow • You want to explore a specific template category • Planning which policy, override, or workflow to use DO NOT USE THIS TOOL WHEN: • You want to read the actual content of a template — use 'show_template' instead • You want to run a scan — use 'scan' instead This is a READ-ONLY local operation. Zero network requests. Instant results. EXAMPLE INPUTS: • See all categories: {} • Browse policies: {"kind": "policies"} • Browse Nuclei templates: {"kind": "nuclei"} • Browse output formats: {"kind": "output"} KINDS:

Read the full content of a bundled template. Returns the raw YAML or Go template content. USE THIS TOOL WHEN: • The user asks "show me the strict policy" or "what's in the enterprise report config?" • You need to inspect a template before using it • You want to understand what a Nuclei template tests DO NOT USE THIS TOOL WHEN: • You want to browse available templates — use 'list_templates' first • You want to run a template — use 'scan' with --policy or --overrides flags EXAMPLE INPUTS: • Policy: {"path": "policies/strict.yaml"} • Nuclei template: {"path": "nuclei/http/waf-bypass/sqli-basic.yaml"} • Output format: {"path": "output/csv.tmpl"} • Short name (auto-resolved): {"path": "policies/strict"} Returns the template content as text. Maximum 1MB.