OWASP ZAP
An intercepting proxy and active web scanner: capture, inspect, and tamper with HTTP traffic, with a headless mode for the console and automation.
Authorized use only. Run these only on systems you own or have explicit written permission to test. Full notice at the foot of the page.
01The proxy at the centre of web testing
Most web testing runs through an intercepting proxy, and ZAP is the open-source one. You route your browser through ZAP, and every request and response passes through where you can read it, pause it, change it, and replay it. That visibility is the foundation: once you can see and tamper with the real traffic, you can test authorization, manipulate parameters, and feed exact requests to other tools. ZAP adds an active scanner on top, but the proxy is the heart of it. It has a full GUI; it also runs entirely headless for automation, which keeps it usable from the console and in CI.
02Install and the GUI note
ZAP is a Java application; install from your package manager or the official download. This is the one tool in the arsenal built around a GUI, though its headless and automation modes are first-class. The GUI is worth it here: inspecting and tampering with requests is a visual task.
$ sudo apt install zaproxy # Debian / Kali
$ flatpak install flathub org.zaproxy.ZAP # Gentoo / Fedora / any (Flatpak)
$ # or the cross-platform installer from zaproxy.org/download
03Routing traffic through ZAP
Point your browser's proxy at ZAP (by default 127.0.0.1:8080) and install ZAP's CA certificate so HTTPS can be intercepted. ZAP's own browser launch does this for you in one click. Now browse the app; every request appears in ZAP's history, building a map of the site as you use it.
1. Start ZAP and open the automated browser from the Quick Start tab.
2. Browse the target app normally; log in, click through features.
3. Watch the Sites tree and History fill with the real requests.
4. This passive pass alone flags many issues without sending a single attack.
04Intercept and tamber
Turn on breakpoints and ZAP pauses matching requests before they go out, so you can edit them by hand: change a price, swap a user ID, strip a parameter. This manual tampering is how you find authorization flaws and logic bugs that no automated scanner catches. Request a resource as one user, change the ID, and see if you get another user's data.
05Spidering to find content
ZAP's spider crawls the app to discover pages and endpoints, and the AJAX spider drives a real browser to reach content behind JavaScript. Run these to build coverage before scanning, so the active scan knows about every page.
$ # in the GUI: right-click the site > Attack > Spider
$ # AJAX spider for single-page apps that the normal spider misses
06The active scanner
Once ZAP has mapped the app (passively and via the spider), the active scanner attacks the discovered requests with payloads for injection, cross-site scripting, and many other classes. It is intrusive by definition, so point it only at authorized targets and prefer a staging copy. Review the alerts it raises by severity.
07Headless and the automation framework
For the console and for CI, ZAP runs without the GUI. The modern way is the Automation Framework: a YAML plan describing the target, the spider, and the scan, run by zap.sh in daemon mode. This is how ZAP fits a terminal-first workflow and how teams gate deployments on a clean scan.
$ zap.sh -cmd -autorun plan.yaml
$ # plan.yaml defines context, spider, activeScan, and a report job
08ZAP in your own pipeline
ZAP's best defensive use is as a gate: run the automation plan against every build of your own app in CI, fail the build on high-severity alerts, and you catch injection and scripting flaws before they ship. The manual proxy, meanwhile, is how you test the things scanners miss, especially broken access control, which is consistently the most damaging and the least automatable web flaw.
» Automate a baseline scan in CI so regressions are caught at commit time.
» Use the manual proxy to test authorization: can one user reach another's data by changing an ID.
» Fix the high and medium alerts at the source; treat the scan as a regression test, not a one-off.
Authorized use only
The tools and techniques in these guides are for defending, testing, and understanding systems you own or have explicit written permission to assess. Unauthorized access to computers, networks, accounts, or data is a criminal offense in nearly every jurisdiction, and the penalties are real.
A few of the laws that apply, by way of example:
- Philippines: Cybercrime Prevention Act of 2012 (Republic Act No. 10175)
- United States: Computer Fraud and Abuse Act (18 U.S.C. § 1030)
- United Kingdom: Computer Misuse Act 1990
- European Union: Directive 2013/40/EU on attacks against information systems, as implemented by each member state
- Most other countries have equivalent computer-misuse laws
Wherever you are, the rule is the same: get authorization in writing, stay within the agreed scope, and never touch a system that is not yours to test. If you are unsure whether something is permitted, treat it as not permitted until you have clear authorization.
This is general information, not legal advice.