Wapiti — a black-box web-application vulnerability scanner written in Python — attacks a running website the way an outsider would, never reading a line of its source. Created by Nicolas Surribas and released under the GNU General Public License version 2, Wapiti crawls the pages of a deployed application, extracts the links, forms and parameters it finds, then fuzzes them: it sends payloads, looks for error messages, special strings and abnormal behaviour, and reports what it can prove. It is one of the oldest continuously maintained projects in the field (the current release is v3.3.2, with roughly 1,900 stars on GitHub), and its deliberately unglamorous model — a crawler plus a set of attack modules, with no agent to install on the target — is what makes it usable from a laptop against any URL you are permitted to test.

Key Features

• True black-box operation — Wapiti works like a fuzzer rather than a code reviewer. Everything it knows about the target it learned by requesting pages, so it applies equally to PHP, Python, Java, .NET or anything else behind the endpoint, and it needs no access to the server it is testing.
• Around thirty attack modules — SQL injection (error-based, boolean-based and time-based), reflected and stored XSS, file disclosure and path traversal, command execution, XXE, LDAP injection, CRLF injection, open redirects, CSRF, insecure cookie flags, missing or weak HTTP security headers, unusual HTTP methods, backup-file discovery, a Nikto-derived database of known issues, CMS enumeration (WordPress, Drupal, Joomla, Magento, SPIP, Typo3), subdomain takeover, Log4Shell and Spring4Shell detection, and file-upload flaws. Modules are switched on and off with -m/--module or simply listed with --list-modules.
• Adding a payload is adding a line — attack payloads live in plain text files, so extending a module means editing a list rather than writing code. The same design keeps the shipped signatures readable and reviewable.
• Sessions that survive interruption — scan state is held in a local SQLite database. A long crawl can be resumed where it stopped (--resume-crawl), a scan session kept or flushed deliberately (--store-session, --flush-session, --store-config), and cookies harvested separately with the bundled wapiti-getcookie helper — including direct import from Chrome or Firefox profiles.
• Authenticated scanning — HTTP authentication (Basic, Digest, NTLM), form-based login with credentials given on the command line, cookie files, raw --jwt bearer tokens, or your own Python code via --form-script for the complicated multi-step logins real applications use.
• Scope and politeness controls — restrict a scan to a domain, folder, single page or URL (--scope), exclude specific URLs such as logout endpoints (-x), and bound the work with --max-links-per-page, --max-files-per-dir, timeouts, a maximum scan time and a configurable number of concurrent HTTP tasks. An explicit exclusion file keeps a scan away from the parts of a site that must not be touched.
• Reports in six formats — HTML, XML, JSON, TXT, CSV and Markdown, with colour in the terminal and three verbosity levels. Every finding carries its request/response evidence, which makes triage and re-testing straightforward.
• Browses like a browser — HTML5-aware crawling, a basic JavaScript interpreter for extracting URLs, optional headless Firefox crawling (--headless), and MITM proxy support for recording traffic in an HTTP proxy such as Burp or ZAP.
• Restrained by default, tunable when needed — Wapiti removes parameters that cause endless loops, limits the values tried per parameter, and distinguishes reflected from permanent XSS instead of flooding a report. When you need breadth and can afford the traffic, raising the concurrency and disabling the guards is a flag away.
• REST APIs too — given an OpenAPI/Swagger definition (--swagger), Wapiti scans documented API endpoints and injects payloads in JSON bodies as well as query strings, which covers the growing share of applications that have no HTML forms to crawl.
• Technology fingerprinting with CVEs — the Wappalyzer-derived database identifies the software and versions in use on a target and links the results to known vulnerabilities, so a scan ends with context and not just a list of payloads.

Why Use Wapiti?

Most attack-surface tooling asks you to change something first: install an agent, adopt a template language, hand over source code, or accept a hosted service. Wapiti asks for none of that. It is a Python package you can install on the machine you already have (pip install wapiti3), pointed at a URL you already own, and it will crawl what is actually reachable, fuzz every parameter it found and write the evidence to disk. That makes it a natural first pass on a new target, a regression check after a deployment on staging, and a teaching tool — the report shows the payload that triggered each finding, so a developer can reproduce it without extra tooling. It is also deliberately conservative about scope and resource use, so it will not crawl your production estate into the ground unless you tell it to. The honest caveat is the same one that applies to every scanner: it finds the classes of bug its modules encode. It is not a substitute for an engaged tester, and it must only ever be pointed at systems you are authorised to test — a scan is active, noisy and looks exactly like an attack in your logs.

Use Cases

• Run a first-pass vulnerability sweep over a site you have just been authorised to assess — crawl, fuzz, then hand the module findings to a human for verification.
• Scan a staging environment after each meaningful deployment as a regression check, using an exclusion file for logout and payment paths that must not be fuzzed.
• Test an authenticated application area by supplying a cookie file exported once from your browser, then re-running the scan on a schedule without touching the login flow each time.
• Check the security posture you can fix cheaply: missing X-Content-Type-Options, absent CSP, insecure cookie flags, dangerous HTTP methods and stray .env or backup files turn up regularly on small sites.
• Enumerate a REST API from its Swagger/OpenAPI document when there are no forms for a crawler to find.
• Teach the mechanics of web application fuzzing — the payload files and the request/response evidence in the report are readable by someone who has never used a scanner before.

Similar

• Nikto — the classic fast server scanner; Wapiti goes further with parameter fuzzing, authenticated sessions and resumable crawls.
• Nuclei — template-driven, community-maintained detections; Wapiti ships its own built-in attack modules and crawls the target first.
• OWASP ZAP — a full interception proxy and manual testing workbench; Wapiti is the scriptable, headless scanner you can put in a cron job.
• Semgrep — static analysis of your own source, where Wapiti tests the deployed application from the outside.
• Gitleaks — credential scanning in repositories, a natural companion before an external scan.
• OpenVAS and Lynis — host and network auditing, where Wapiti covers the web application layer itself.

Platform

Python 3.12, 3.13 or 3.14 — installed from PyPI as wapiti3, which pulls the required modules automatically · runs on Linux and macOS, and on Windows through WSL · scan sessions stored locally in SQLite · optional headless Firefox and MITM-proxy modes for authenticated or JavaScript-heavy targets

Licence

GNU General Public License v2.0 (GPL-2.0) — free and open source, no paid tier or proprietary component. Source is developed publicly at github.com/wapiti-scanner/wapiti.

Website

wapiti-scanner.github.io · source on GitHub · wiki · also see the Security & Privacy category for more tools that keep systems in check.