OWASP ZAP explained: what it is and 10 typical checks

What ZAP is

ZAP (Zed Attack Proxy), still called OWASP ZAP in many places, is a free, open-source security scanner for web applications. Its site describes it as an independent open source project. It works as a proxy between the browser and the application: it sees every request and response, so it can analyse them.

It is used both by a person who explores an app by hand and by an automated pipeline that runs it on every code change.

The Baseline scan: passive, no attacks

In automated test pipelines the Baseline mode is the usual choice. According to the ZAP documentation, it runs the spider against the target (for one minute by default), waits for passive scanning to finish and reports the results. The documentation points out that the script does not perform any actual attacks and takes a few minutes at most.

That is an important distinction. A passive scan reads what the application already answers to every visitor: headers, cookies, page source. An active scan sends crafted requests to find out whether the application can be tricked, which is why it may only be pointed at your own systems or with the owner's permission.

10 typical checks

The names below come from ZAP's alert list. Which of them show up depends on the version and the configuration, and a finding is a signal to look, not proof of a break-in.

1. Content Security Policy (CSP) Header Not Set. The header that tells the browser where scripts may be loaded from is missing. It limits the damage of injected foreign code.
2. Missing Anti-clickjacking Header. The page can be embedded in someone else's frame and a user tricked into clicking something they cannot see.
3. X-Content-Type-Options Header Missing. The browser may guess a file's type instead of trusting the server.
4. Strict-Transport-Security Header Not Set. The browser is not told to always use HTTPS for this site.
5. Cookie No HttpOnly Flag. A script on the page can read the cookie, a session cookie for example.
6. Cookie without SameSite Attribute. The cookie is also sent on requests from other sites, which makes CSRF attacks easier.
7. Server Leaks Version Information via “Server” HTTP Response Header Field. The server reveals which software it runs and in which version.
8. Information Disclosure - Suspicious Comments. Comments left in the page source may point an attacker in a direction.
9. Cross-Domain JavaScript Source File Inclusion. The page loads scripts from other domains, so its security also depends on them.
10. Vulnerable JS Library. The page uses a JavaScript library in a version with a known flaw.

Alongside these you often see "Re-examine Cache-control Directives", "Permissions Policy Header Not Set" and "Sub Resource Integrity Attribute Missing".

What a passive scan will not tell you

A clean Baseline result does not mean "the app is secure". The scan does not log in as a user, does not check whether a parent in one class can look into another class, and does not try to inject malicious data. That takes permission tests written for the specific app, an active scan and a penetration test. The Baseline scan is a cheap, repeatable first filter, nothing more.

How it is with us

In ClassKasa, CzynszOK and Kasandro the Baseline scan runs on every pull request against the built app and fails the build on new findings. The scan does not sign in, so it does not cover signed-in screens. The full picture of what we check across the veinito. group is on the security page.