Security
OWASP ZAP
A free web application scanner you can automate.
OWASP ZAP in practice
An open-source web application scanner that sits between a browser and the application as an intercepting proxy, records what passes through it, and then probes what it has seen. Passive scanning reviews that traffic for weak headers, cookie handling and disclosure; active scanning sends crafted requests designed to provoke a response indicating a flaw. It runs headless from a container against a configuration file describing the entire job, which is what makes it the usual starting point for automated security checks inside a pipeline.
It carries the automated layer of an assessment: the crawl, the passive review, and an active scan across the endpoints inside the agreed scope. Because nothing is charged per run, it is the tool we can leave behind on a client’s pipeline so a baseline scan happens on every deployment for years after the engagement closes. What it produces then goes through a person before it goes anywhere near a report, because deciding which alerts are real and which are noise is the part that cannot be handed to a machine.
It reports things that are not true. False positives are an ordinary cost of automated scanning, and an unreviewed export forwarded to a development team destroys the credibility of security work faster than almost anything else available.
Active scanning writes. Aimed at production it will submit forms, create records and trigger notifications to real people, so scope and environment have to be agreed in writing before anything starts.
It cannot reason about your business. Whether one account should be able to read another account’s invoice is a question about intended behaviour, and no scanner has ever known what you intended.
Authenticated scanning of a modern single-page application takes configuration work. Sessions, tokens and client-side routing all need describing first, and a crawl that never manages to log in has tested your login page.
Coverage is bounded by the crawl. Anything the spider fails to reach, including flows behind a multi-step state machine or a payment step nobody wants triggered, is simply never scanned at all.
FAQ
OWASP ZAP questions we hear often
Is a free scanner good enough on its own?
For continuous coverage of known categories it is genuinely useful, and running one is meaningfully better than running nothing. As the whole of a security posture, no, and that holds for every scanner regardless of what it costs. Automated tooling finds what somebody has already encoded; it does not find the flaw in how your permissions model was designed.
Can we point it at production?
A passive scan, frequently. An active scan only with written agreement, a maintenance window and somebody watching, because it submits data and can disrupt a live service in ways that reach customers. Our default is an environment resembling production closely enough for findings to transfer, plus an honest conversation about the places where it does not.
How do we handle the false positives?
Triage before distribution, without exception. Somebody verifies each alert by hand, discards what does not hold up, and records the reasoning behind anything suppressed so the identical alert is not re-argued next quarter by different people. A tuned configuration that a human maintains is the whole difference between a scan teams act on and a scan teams mute.
How does it compare with a commercial scanner?
Commercial tooling generally produces a cleaner signal and better reporting out of the box, and you pay for that. This one produces more noise and costs nothing per pipeline, which changes what you can afford to run continuously rather than annually. We would rather run a noisier scanner on every deployment and triage it than run a quiet one once a year.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.