OWASP ZAP Tutorial: A Step-by-Step First Scan on a Lab Target

Key takeaways

• Active scanning sends attack traffic. Run it only against your own lab app or a target with written permission.
• ZAP works as a proxy first and a scanner second. Exploring the app manually through the proxy improves every scan.
• Every alert needs human review. Automated scanners produce false positives and miss logic flaws.
• ZAP is a good first scanner, not a substitute for a manual test.

What is ZAP and what is it not?

ZAP is an open-source tool maintained under the OWASP community. It does two jobs: it sits between your browser and a web app so you can see and change requests, and it can crawl and scan the app for common weaknesses. It suits learners, developers who want security checks in a pipeline, and testers who want a free proxy.

It does not replace a manual test. Automated scans find known patterns such as missing security headers or some injection points. They are weak at business-logic bugs, broken access control between users and anything that needs context.

Before you start: permission and a safe target

Scanning a site you do not own, or have no written permission to test, can be a criminal offence under India's Information Technology Act, 2000. Do not "test" public websites to practise.

Use a deliberately vulnerable app on your own machine, such as OWASP Juice Shop or DVWA, running in a VM or container. The DVWA project and Juice Shop both document how to run them locally.

Step 1: install ZAP

Download ZAP from zaproxy.org for Windows, macOS or Linux. It needs a Java runtime on some packages; the installers usually bundle it. On Kali Linux, check the Kali docs or the package manager. Start ZAP and choose to persist the session if you want to keep your results.

Step 2: explore the app through the proxy

1. In ZAP, note the proxy address, by default 127.0.0.1 port 8080.
2. Set your browser to use that proxy, or use the browser launched from ZAP, which is already configured.
3. Open your lab app and click through it like a real user: register, log in, add items, submit forms.
4. Watch the Sites tree fill up. This manual exploration finds pages a crawler would miss behind forms and logins.

For HTTPS traffic, you will need to trust ZAP's local root certificate in your test browser. Use a throwaway browser profile, and remove the certificate when you finish.

Step 3: run the spider

Right-click your target in the Sites tree, choose the Spider option, and run it. The spider follows links and adds URLs it finds. The AJAX Spider is the option for apps that build pages with JavaScript.

Step 4: run the active scan

Right-click the target and choose the Active Scan option. ZAP now sends many test requests that try common attacks. Watch the progress panel, and stop if your lab app becomes unstable. Do this only on your own lab target.

Use scan policies to limit which tests run. In a real engagement you also set scope and rate limits so you do not disrupt the service.

Step 5: read the alerts

Open the Alerts tab. Each alert shows a risk level, a confidence level, the URL and parameter, the evidence and a suggested fix. For each one:

1. Read the request and response that triggered it.
2. Reproduce it manually in the browser or with a request replay.
3. Decide if it is real. Mark false positives so they do not return in the next report.
4. Note the fix, which is more useful than the alert name.

Common results on a vulnerable lab app include missing anti-CSRF tokens, missing security headers, cookies without flags, and SQL injection or cross-site scripting findings. Compare what you find with the OWASP Top 10 to understand why each matters.

Step 6: generate a report

Use the Report menu to create an HTML or other report. A useful report lists each real finding, how to reproduce it, its impact and the fix. Remove false positives first.

What ZAP often misses

• Authorisation flaws, such as one user reading another user's data.
• Multi-step business logic problems, such as skipping a payment step.
• Vulnerabilities behind login if authentication is not configured.
• Anything that needs human reasoning about how the app should behave.

After your scan, try to find one issue by hand that ZAP did not report. That habit separates a tool operator from a tester.

Common mistakes

• Running an active scan against a production or third-party site.
• Skipping the manual exploration step, so the scan sees only the login page.
• Sending the raw report to a developer without checking false positives.
• Leaving the ZAP certificate trusted in your everyday browser.

Next steps

For a tool comparison, read the OWASP ZAP overview and the web application testing tools list. To learn the full method behind the tool, see the Web Application Penetration Testing (WAPT) course.

Related reading

• How to Perform Penetration Testing with Acunetix
• Understanding Burp Suite: Your Partner in Cybersecurity