Security · Senior & Test Lead

OWASP ZAP

The leading open-source web application security scanner. Used by NZ government agencies and enterprises to find OWASP Top 10 vulnerabilities automatically.

Senior Test Lead ~15 min read

1 The Hook — The Auckland Medical Data Breach

A medical clinic in Auckland had a simple website where patients could request repeat prescriptions. The site had a "hidden" SQL injection vulnerability in the search bar. Using a free, automated tool, a hacker was able to bypass the login and download 50,000 patient records, including names, addresses, and sensitive health information. The breach resulted in a massive Privacy Commissioner investigation and permanent damage to the clinic's reputation.

A simple OWASP ZAP Baseline Scan during development would have flagged this vulnerability in seconds. Security isn't just for "cyber experts"; it's an automation skill that protects your users and your company. Finding a bug is good; finding a vulnerability is essential.

2 The Rule — Shift Left Security

Security is not a final step; it's a continuous process. Run automated security scans on every deploy.

Don't wait for a manual "Pen Test" once a year. Use ZAP to scan your staging environment on every pull request to catch common vulnerabilities before they ever reach production.

3 The Analogy — The Home Security System

Analogy

Checking the Locks.

Building an app without security scanning is like building a house with beautiful windows and doors but never checking if they actually lock. OWASP ZAP is like a security guard who walks around your house every night, rattling every handle and checking every window to make sure nothing was left open by accident.

Senior engineer insight

The single biggest shift in how I think about ZAP came when I stopped treating it as a one-shot audit tool and started treating it as a regression test for my security posture. Once you baseline your alert count on a clean build and gate PRs on that number, regressions become immediately visible — a developer adds a new endpoint without a Content-Security-Policy header and the pipeline goes red before anyone reviews the code. That feedback loop is worth more than any annual pen test.

The most common mistake: running ZAP once at go-live, not in every CI pipeline job, which means six months of new vulnerabilities accumulate undetected before anyone looks at the report again.

4 Watch Me Do It — ZAP Baseline Scan (Docker)

Scenario: Running a non-destructive "Baseline Scan" against a staging environment to find missing security headers or common configuration issues.

# Run the ZAP Baseline Scan using Docker
docker run -v $(pwd):/zap/wrk/:rw -t owasp/zap2mg-stable zap-baseline.py \
    -t https://staging.resync.nz \
    -r report.html

This command pulls the ZAP image, scans the target URL, and saves a full HTML report to your current directory. It's the standard way to run ZAP in a CI/CD pipeline like GitHub Actions.

From the field

A Wellington-based fintech building an open-banking integration assumed their API was safe because it sat behind an API gateway with OAuth 2.0 — the assumption being that authenticated requests couldn't be malicious. When we ran a ZAP Active Scan against their staging environment, it surfaced an Insecure Direct Object Reference (IDOR) on a balance-inquiry endpoint: swap out your own account ID for any other valid integer and you'd get back another customer's balance. The gateway checked the token was valid; it never checked the token owner matched the requested resource. The team had completely missed it because functional testing confirmed "you can see your balance" — not "you can only see your balance." The lesson that generalises: authentication and authorisation are different problems, and automated scanning catches the patterns that human testers forget to probe once the happy path is green.

5 Decision Tool — Active vs. Passive Scanning

🔍 Passive Scan

  • Safe for Production
  • Finds missing headers/cookies
  • Does NOT send attack payloads
  • Fast and non-intrusive

⚠️ Active Scan

  • STAGING ONLY (Never Production!)
  • Finds SQLi, XSS, Path Traversal
  • Sends 1000s of attack payloads
  • Can corrupt data or crash services

6 Common Mistakes

🚫 Scanning Production Without Permission

Warning: In many countries (including NZ), scanning a system you don't own without permission is illegal under the Crimes Act. Always use a dedicated staging environment for active scans.

🚫 Ignoring "Low" Alerts

Mistake: Thinking only "High" alerts matter.
Actually: Hackers often chain multiple "Low" vulnerabilities together (e.g., info disclosure + weak cookies) to create a major exploit. Triage everything.

7 Now You Try — Setup

🚨 Safety First

Download the ZAP Desktop app from zaproxy.org. Try the "Automated Scan" against a safe target like https://demo.testfire.net (a deliberately vulnerable site for testing).

To integrate into your project, look into the ZAP GitHub Action:

- name: ZAP Scan
  uses: zaproxy/action-baseline@v0.12.0
  with:
    target: 'https://staging.resync.nz'

Why teams fail here

  • Alert fatigue from untuned scans: Default ZAP configs generate hundreds of false positives; teams stop reading the reports entirely because noise overwhelms signal. Invest an hour in a context file and a suppress list before your first real pipeline run.
  • Active scanning a live environment: ZAP's Active Scan sends thousands of malformed payloads — SQL fragments, XSS strings, path traversal sequences. Against a production database that lacks proper input sanitisation, this can corrupt real data. Always gate Active Scan behind a STAGING_ONLY environment flag in your CI config.
  • Not authenticating the scan session: An unauthenticated ZAP scan only sees your login page and public endpoints — typically 20–30% of your actual attack surface. Wire up ZAP's script-based authentication so it can crawl behind the login wall and test the routes that actually handle sensitive data.
  • Treating ZAP as a substitute for threat modelling: ZAP finds known vulnerability patterns; it has no model of your business logic. It will never catch "a customer can approve their own expense claim" or "a free-tier user can query a paid-tier API endpoint." Security scanning and threat modelling answer different questions — you need both.

8 Self-Check

Q1. What is the OWASP Top 10?

A standard awareness document for developers and web application security experts. It represents a broad consensus about the most critical security risks to web applications.

Q2. Can ZAP find business logic flaws?

Rarely. ZAP is great at finding technical vulnerabilities (like SQLi), but it doesn't understand your business. For example, it won't know if "User A should not be able to see User B's invoices." That requires manual testing.

Key takeaway

ZAP in CI does not make you secure — it makes security regressions impossible to ignore, which is a completely different and far more valuable thing.

9 Interview Prep

"What is the difference between a False Positive and a True Positive in a ZAP report?"

Answer: "A True Positive is a genuine vulnerability that needs fixing. A False Positive is when the scanner flags something as a risk that actually isn't (e.g., flagging a test page as an information leak). Part of my job as an automation engineer is to triage these reports and filter out the noise so developers can focus on the real risks."