OWASP ZAP Guide: Web Application Vulnerability Scanning from Basics to CI/CD Automation

Context & Why Web Application Vulnerability Scanning is Necessary?

In today’s digital world, web applications are the heart of every business. From e-commerce sites and internal management systems to service platforms, we all rely on them. However, convenience comes with alarming security risks. I once spent a sleepless night because my server was under constant SSH brute-force attacks. Having to wake up in the middle of the night for an emergency fix, I realized: security is not something to wait for. It needs to be established and continuously checked, right from the start of the project.

I understand that once a web application is ‘live’ (in production), finding and fixing security vulnerabilities is like ‘looking for a needle in a haystack.’ However, ignoring them can lead to severe consequences: from customer data leaks and damaged brand reputation to the risk of complete system collapse.

That’s why I started looking for automated vulnerability scanning tools. After more than 6 months of using OWASP ZAP on many real-world projects, I found it to be an extremely powerful, flexible, and most importantly, free and open-source solution.

OWASP ZAP (Zed Attack Proxy) is not just a vulnerability scanning tool. It also acts as an intermediary proxy, intercepting all communication between your browser and web application. This helps me not only automatically detect but also actively analyze and deeply examine vulnerabilities. ZAP is developed and maintained by the OWASP (Open Web Application Security Project) community – a leading non-profit organization in web application security.

Installing OWASP ZAP

OWASP ZAP is compatible with many platforms and offers various installation methods. For personal development, you can download a direct installer. However, I personally prefer Docker, as it makes integration into CI/CD and dependency management much more convenient.

Installation with Docker (Recommended)

If you have Docker installed, launching ZAP only requires a single command:

docker pull owasp/zap2docker-stable
docker run -p 8080:8080 -p 8090:8090 -i owasp/zap2docker-stable zap.sh -daemon -port 8080 -host 0.0.0.0 -config api.disablekey=true

• -p 8080:8080 -p 8090:8090: Maps ZAP’s API port (8080) and UI port (8090) to the host.
• -daemon: Runs ZAP in daemon mode (without a graphical interface), ideal for CI/CD.
• -config api.disablekey=true: Disables the API key requirement, convenient for local testing environments. In production, you should configure an API key to enhance security.

After running the command, you can access the ZAP interface via your browser at http://localhost:8090 if you wish to use the graphical version. In a CI/CD environment, we will interact with ZAP via API or CLI.

Operating System Installation

You can also directly download the installer from the OWASP ZAP homepage for Windows, macOS, or Linux. This method is simple and suitable if you want to use ZAP with its full user interface.

For Ubuntu/Debian:

sudo apt update
sudo apt install snapd
sudo snap install zaproxy --classic

After installation, you can launch ZAP from the application menu.

Detailed Configuration for Effective Scanning

For ZAP to operate effectively, proper configuration is crucial. This is the key factor that helps ZAP not just ‘scan for the sake of scanning’ but truly detect issues.

1. Setting up ZAP as a Proxy

ZAP acts as a Man-in-the-Middle Proxy. All HTTP/S traffic between your browser and web application will be routed through ZAP, allowing it to record and analyze every request/response.

In ZAP, go to Tools > Options > Local Proxies to check the proxy port (default is 8080). Then, configure your browser (Firefox, Chrome) to use this proxy. I often use Firefox with the FoxyProxy extension for easy proxy switching.

With Firefox:

1. Go to Settings > Network Settings > Manual proxy configuration.
2. Set HTTP Proxy to localhost and Port to 8080.
3. Check Also use this proxy for HTTPS.

If you encounter an SSL certificate error, you need to import ZAP’s Root CA certificate into your browser. In ZAP, go to Tools > Options > Dynamic SSL Certificates, click Save to save the certificate, then import it into your browser.

2. Initializing Context and Authentication

This step is essential for applications with login functionality. For ZAP to scan deeply into features requiring authentication, it needs to know how to log in.

• Creating a Context: In the ZAP UI, right-click the Site you want to scan (e.g., http://your-webapp.com) in the Sites tab, select Include in Context > New Context. Name the Context (e.g., MyWebApp).

• Configuring Authentication: In the Contexts section (left window), select the newly created Context, then choose the Authentication tab.

  • Form-based Authentication: The most common type. You need to provide the URL of the login page, username/password parameters (e.g., usernameField=user&passwordField=pass), and a text string for ZAP to recognize successful/failed logins (e.g., Log out for success, Invalid credentials for failure).
  • HTTP/NTLM Authentication: Simpler if your application uses this type.

• Creating a User: In the Users tab of that Context, click Add to create a user with the configured login information (username/password). ZAP will use this user to perform authenticated scanning sessions.

This helps ZAP effectively scan pages accessible only after login, searching for vulnerabilities like Broken Access Control and SQL Injection in backend functionalities.

3. Spidering (Application Structure Discovery)

Before performing an active scan, ZAP needs to understand the application’s structure. There are two main types of Spiders:

• Traditional Spider: Discovers links in HTML, JavaScript. To run, right-click on the Context or Site, select Attack > Spider....

• AJAX Spider: Very important for modern web applications that use a lot of JavaScript to load dynamic content. The AJAX Spider will open a headless browser and simulate user interaction to find dynamically generated links and API endpoints. To run, right-click on the Context or Site, select Attack > AJAX Spider....

I often combine both types of spiders to ensure ZAP discovers the maximum number of paths and functionalities.

4. Configuring Active Scan Policies

Active Scan is the process where ZAP sends specially crafted (often ‘malicious’) requests to the application to find vulnerabilities. You can customize policies to make the scanning process more effective:

Go to Tools > Options > Active Scan Policy. Here, you can create new Policies, enable/disable specific rules, adjust the Alert Threshold, and Attack Strength. For example, if you want to avoid causing excessive load on the server, reduce the Attack Strength to Low or Medium. Conversely, if you want to scan more deeply, choose High or Insane.

Removing irrelevant or potentially harmful rules in a production environment (e.g., denial-of-service rules) when scanning sensitive systems is particularly important.

Testing & Monitoring: From Manual to CI/CD Automation

Once installed and configured, this is when ZAP unleashes its full power.

1. Manual Scanning (Initial Exploration)

For the first scan or when I want to explore a new feature, I usually perform it manually:

1. Open the ZAP UI.
2. Configure the browser to use ZAP proxy.
3. Manually browse through all application functions: login, add/edit/delete data, submit forms, interact with APIs via the user interface. At this point, ZAP will automatically record all requests/responses in the History tab and perform a Passive Scan (analysis without sending new requests) to find basic issues.
4. After browsing, run the AJAX Spider and Traditional Spider on the created Context.
5. Finally, run an Active Scan on the entire Context or specific branches of the Site that you want to examine more deeply.

The results will be displayed in the Alerts tab with High, Medium, Low, and Informational levels. From there, you can delve into each alert to view request/response details and find remediation steps.

2. Automation with CI/CD

This is when ZAP becomes a key factor in my development process. Integrating ZAP into CI/CD helps automate vulnerability detection early on, significantly saving time and cost. According to an IBM study, detecting and fixing security bugs in the early development phase can reduce costs by up to 100 times compared to fixing bugs in a production environment.

ZAP provides a powerful Automation Framework, allowing scanning steps to be defined in a YAML file. Or more simply, use ZAP Baseline Scan or Full Scan via Docker.

ZAP Baseline Scan (Fast, suitable for daily CI/CD)

Baseline Scan only performs a Passive Scan on known URLs for a specified duration (e.g., 1 minute). It is very fast and suitable for running in every commit/pull request to detect basic, easily identifiable issues.

docker run --rm -v $(pwd):/zap/wrk/:rw owasp/zap2docker-stable zap-baseline.py -t http://your-webapp.com -g gen_report.html -r zap_baseline_report.xml

• --rm: Removes the container after running.
• -v $(pwd):/zap/wrk/:rw: Mounts the current directory into the container to save the report.
• -t http://your-webapp.com: Target URL of the web application.
• -g gen_report.html: Generates the report in HTML format.
• -r zap_baseline_report.xml: Generates the report in XML format (easily parseable by CI/CD tools).

ZAP Full Scan (More thorough, suitable for nightly build/release)

Full Scan will perform Passive Scan, Traditional Spider, AJAX Spider, and Active Scan. This process takes more time but finds more vulnerabilities.

docker run --rm -v $(pwd):/zap/wrk/:rw owasp/zap2docker-stable zap-full-scan.py -t http://your-webapp.com -g gen_report.html -r zap_full_report.xml -D 10

• -D 10: Waits 10 minutes for the AJAX Spider to complete discovery.

Processing Results and Failing Builds

I always configure CI/CD jobs to fail if ZAP finds vulnerabilities at High or Medium levels. This ensures that no code with critical security flaws makes it into production. A real-world example is many companies require zero High/Medium vulnerabilities before deploying to Staging/Production environments.

In ZAP’s XML or JSON report file, you can parse it to check the number and severity of alerts. For example, with Python:

import json

def check_zap_alerts(report_path):
    with open(report_path, 'r') as f:
        report = json.load(f) # Assuming you create a JSON report

    high_alerts = 0
    medium_alerts = 0

    for site in report.get('site', []):
        for alert in site.get('alerts', []):
            if alert['riskdesc'] == 'High':
                high_alerts += 1
            elif alert['riskdesc'] == 'Medium':
                medium_alerts += 1
    
    if high_alerts > 0:
        print(f"[ERROR] Found {high_alerts} High risk alerts.")
        return False
    if medium_alerts > 0:
        print(f"[WARNING] Found {medium_alerts} Medium risk alerts.")
        # Depending on policy, you might fail the build here
        return False # Fail build if there's a Medium risk alert
    
    print("No High or Medium risk alerts found. Good job!")
    return True

# Usage:
# if not check_zap_alerts('zap_report.json'):
#    exit(1) # Fail CI/CD build

This is just a simple example. In practice, you can use specialized libraries or built-in CI/CD tools to parse and process reports from ZAP.

Continuous Monitoring

In addition to CI/CD, I also set up scheduled scans (weekly or monthly) for critical production applications. Reports from these scans will be sent via email or integrated into a centralized vulnerability management system. This helps me continuously monitor the application’s security “health” and promptly detect newly arising issues.

In summary, OWASP ZAP is an important tool for any IT engineer concerned with web application security. From manual vulnerability discovery to automated CI/CD integration, ZAP offers incredible flexibility and power. Start using it today to better protect your applications!