Passive OWASP ZAP assessment

OWASP Zed Attack Proxy (ZAP) is the most widely used open-source web application security scanner. It has two modes. ScanBastion's first release uses only the passive one: ZAP visits the site's public pages the way a browser would and analyses what comes back, without sending any attack payloads.

Passive means passive

In passive mode, ZAP's scan rules only ever read. They look at the requests the crawler made and the responses the server returned, and raise an alert when something in that traffic matches a known weakness. No form is submitted with test strings, no parameter is tampered with, no path is guessed. The target receives a bounded crawl of ordinary GET requests, which is why this check is included in the Quick profile and is considered safe for production sites.

ZAP's active scanner, which does inject payloads to confirm vulnerabilities such as SQL injection and cross-site scripting, is not part of the first release. It generates far more traffic, can trigger side effects in applications that are not idempotent, and needs explicit, informed sign-off from the site owner. The guide Passive vs active scanning explains the difference in terms of the traffic a site actually receives.

What the crawl covers

ZAP's spider starts at the verified hostname and follows links within the same site, up to a bounded depth and a bounded number of pages per scan. It respects the scan's request-rate limit and stops at the stage timeout. It does not log in, so anything behind authentication is not visited. It does not submit forms. Pages found are also used as the sample for the headers check.

Passive rules that run

ZAP ships dozens of passive scan rules. The categories most relevant to an external assessment are:

• Information disclosure. Server and framework version strings, debug or error messages in page bodies, developer comments in HTML, private IP addresses, timestamps and suspicious comments such as TODO or FIXME near security-relevant code.
• Cookie hygiene. Cookies set without Secure, HttpOnly or SameSite, and cookies with loose domain scope.
• Header analysis. Missing anti-clickjacking protection, missing or weak Content-Security-Policy, missing X-Content-Type-Options, cache-control on pages that look sensitive.
• Content issues. Mixed content (HTTP resources on HTTPS pages), scripts included from third-party domains without integrity attributes, password fields with autocomplete enabled, forms posting to HTTP, charset mismatches, and reflected input visible in the page (a hint, not a confirmed cross-site scripting bug).
• Application fingerprints. Recognisable frameworks, CMS platforms and JavaScript libraries, which later feed the version checks.

Rules are vetted before being enabled. Rules that produce mostly noise on typical sites, or whose output duplicates the dedicated headers and TLS checks, are either disabled or merged into the consolidated finding so an issue is counted once.

An example finding

What this check cannot tell you

• Whether an injection vulnerability exists. Passive analysis can notice that input is reflected in a page; only active testing or manual review can confirm it is exploitable. Such findings are marked Needs review.
• Anything behind a log-in or a form. Account areas, checkout flows and dashboards are not crawled.
• Business-logic flaws. Price manipulation, broken access control between users and similar issues are invisible to any passive scanner.
• JavaScript-rendered content beyond what the spider can discover from the initial HTML and linked resources.

References

• ZAP alert reference, with an explanation and remediation for every rule.
• ZAP passive scanning, how the passive scanner works.