wapiti: Scans web applications for vulnerabilities

There’s a specific kind of engagement where I don’t want the manual, request-by-request control of Burp Suite — I want something to crawl an entire application on its own and come back with a broad first-pass vulnerability report I can then dig into manually. That’s exactly the role Wapiti fills for me. It’s a black-box web vulnerability scanner that crawls a target, finds every injectable point it can, and systematically tests each one against a wide range of vulnerability classes — without needing access to the application’s source code.

What Is Wapiti?

Wapiti is a free, open-source, command-line web application vulnerability scanner written in Python. It performs black-box testing: it doesn’t read the application’s source code, but instead crawls pages, discovers forms and parameters, and injects payloads to detect common vulnerability classes — SQL injection, XSS, command injection, SSRF, XXE, CRLF injection, and more.

Wapiti has been actively maintained for well over a decade and remains a solid, lightweight choice when you need a full-application scan without the overhead of a commercial scanner.

How Wapiti Works Internally

Wapiti operates in two clear phases:

1. Crawling phase — Wapiti’s spider (swf/crawler module) systematically explores the target, following links, submitting forms with test data, and mapping out every parameter (GET, POST, cookies, HTTP headers) it can find, building an internal model of the application’s attack surface.
2. Attack phase — for every discovered injection point, Wapiti runs a battery of vulnerability-specific modules (“attack modules”), each targeting a distinct vulnerability class:
   • sql — SQL injection detection (error-based and blind)
   • xss — reflected and stored cross-site scripting
   • exec — command injection (similar in spirit to what Commix specializes in)
   • file — file disclosure / path traversal / local & remote file inclusion
   • xxe — XML external entity injection
   • ssrf — server-side request forgery
   • crlf — CRLF/header injection
   • htaccess — misconfigured access control files
   • backup — exposed backup/config files
   • csp — Content Security Policy analysis
   • cookieflags — missing Secure/HttpOnly cookie flags

Because Wapiti doesn’t understand application logic the way a human tester does, it relies on pattern-based detection (error signatures, reflected payload markers, timing) — which is why its results should always be manually triaged, similar to any automated scanner.

Installation

pip install wapiti3 --break-system-packages

Or on Kali Linux (preinstalled):

wapiti --version

From source:

git clone https://github.com/wapiti-scanner/wapiti.git
cd wapiti
pip install . --break-system-packages

Basic Syntax

wapiti -u <target-url> [options]

Command Examples

1. Basic full scan (against a lab target):

wapiti -u http://testlab.local/

Sample output (abridged):

[*] Loading modules: mod_backup, mod_blindsql, mod_brute_login_form,
    mod_buster, mod_cookieflags, mod_crlf, mod_csp, mod_exec, mod_file,
    mod_htaccess, mod_htp, mod_permanentxss, mod_shellshock, mod_sql,
    mod_ssrf, mod_wapp, mod_xss, mod_xxe
[+] Beginning attack with module mod_sql
[*] Injecting the following methods: GET
[!] SQL Injection in http://testlab.local/product.php?id=1

2. Scanning with authentication (cookie-based session):

wapiti -u http://testlab.local/ --cookie cookies.json

3. Restricting scope to a specific scan depth:

wapiti -u http://testlab.local/ --scope folder --depth 3

4. Running only specific modules (faster, focused scans):

wapiti -u http://testlab.local/ -m "sql,xss,exec"

5. Generating a full HTML report:

wapiti -u http://testlab.local/ -f html -o wapiti_report/

6. Scanning through Burp Suite for traffic inspection:

wapiti -u http://testlab.local/ -p http://127.0.0.1:8080

7. Passing custom authentication credentials for form-based login:

wapiti -u http://testlab.local/ --auth-user admin --auth-password pass123 --auth-type post

Key Options

Flag	Purpose
-u	Target URL
-m	Modules to run (comma-separated)
--scope	Crawl scope: page, folder, domain, url
--depth	Maximum crawl depth
-p	Proxy (e.g., route through Burp Suite)
-f	Report format: html, json, xml, txt
-o	Output directory/file for the report
--auth-type	Authentication method: post, get, basic, digest, ntlm
-t	Request timeout
--max-attack-time	Cap total scan time

Real-World Use Cases

• Baseline vulnerability scanning: Running a broad first pass across an entire web application before diving into manual, targeted testing with Burp Suite.
• Regression testing: Re-scanning after a development cycle to catch newly introduced vulnerabilities before each release.
• Smaller-budget engagements: Where a commercial scanner license isn’t available, Wapiti provides solid black-box coverage for free.
• CI/CD security gates: JSON/XML report output makes it straightforward to integrate Wapiti into automated pipelines, failing a build if critical findings appear.
• Educational/training environments: A good teaching tool for demonstrating how automated scanners discover and classify vulnerabilities, since its module names map directly onto specific vulnerability classes.

Workflow: Integration With Other Tools

1. WhatWeb first, to confirm the tech stack and decide if any CMS-specific tool (WPScan) should run alongside Wapiti.
2. Wapiti for a broad automated sweep across the whole application.
3. Manual triage in Burp Suite — take each Wapiti finding and reproduce it manually in Repeater to confirm it’s a true positive, not a false alarm from pattern-matching.
4. SQLMap/Commix for deep-dive exploitation of any injection points Wapiti flags, using its identified parameter directly.
5. Report consolidation — merge Wapiti’s structured JSON/XML output with manual findings for a complete client deliverable.

Performance Optimization

• Limit --scope to folder or page rather than domain when you only need to test a specific application section, cutting crawl time significantly.
• Use -m to run only relevant modules — a REST API target, for example, gains little from mod_csp or mod_htaccess checks.
• Set --max-attack-time to bound scan duration on large applications, especially in CI/CD contexts where pipeline time matters.

Troubleshooting & Common Mistakes

• Scanner missing authenticated pages entirely: make sure you’ve supplied valid session cookies or configured --auth-type/--auth-user/--auth-password correctly — Wapiti can’t test what it can’t log into.
• Crawler getting stuck in infinite loops (calendar widgets, pagination): use --exclude to skip known problematic URL patterns.
• High false-positive rate on custom error pages: some applications return HTTP 200 with a custom “not found” or “error” page body; Wapiti’s detection can occasionally misfire here — verify flagged SQLi/XSS findings manually.
• Slow scans on large applications: narrow scope, reduce depth, or run only the modules relevant to your actual concern rather than the full default battery.

Best Practices

• Always run against a staging/lab environment first if possible, since active scanning (especially mod_exec, mod_sql) can occasionally affect application state or trigger alerts/rate-limiting on production WAFs.
• Treat every finding as a lead, not a confirmed vulnerability, until manually verified.
• Keep Wapiti updated (pip install -U wapiti3) — vulnerability signatures and module logic improve over time.
• Combine automated scanning with manual business-logic testing; Wapiti (like all scanners) can’t reason about application-specific logic flaws.

FAQ

How does Wapiti compare to OWASP ZAP? Both are free, open-source, black-box scanners. ZAP has a more polished GUI and active development community; Wapiti is lighter-weight, CLI-first, and often faster to get running for a quick automated sweep.

Can Wapiti test single-page applications (SPAs)? Its crawler primarily follows static HTML links and forms; heavily JavaScript-rendered SPAs may need supplementary tools or manually supplied URL lists (-s to add specific starting URLs) since Wapiti doesn’t execute JS like a full browser.

Does Wapiti require authentication setup for every scan? Only if the target application requires login to reach the pages you want tested — for public-facing pages, no authentication configuration is needed.

Lab Example

Using DVWA:

docker run --rm -it -p 80:80 vulnerables/web-dvwa

Export your logged-in session cookie to a cookies.json file (Wapiti supports importing cookies), then run:

wapiti -u http://localhost/ --cookie cookies.json -m "sql,xss,exec" -f html -o wapiti_dvwa_report/

Open the generated HTML report to see Wapiti’s findings mapped directly onto DVWA’s known vulnerable pages — an easy way to sanity-check that your scan configuration is working correctly.

Summary

Wapiti fills a useful middle ground: heavier and broader than a single-purpose tool like SQLMap or Commix, but lighter and more transparent than a full commercial scanner. As the first automated pass in an authorized engagement, it’s a fast way to surface likely vulnerability classes across an entire application before manual testing takes over to confirm and dig deeper.

References

• Official site: https://wapiti-scanner.github.io
• GitHub repository: https://github.com/wapiti-scanner/wapiti
• Documentation: https://wapiti-scanner.github.io/pages/documentation.html