zaproxy community-scripts: the rule library that makes ZAP useful

The problem: a scanner is only as good as its rules

OWASP ZAP is a dynamic application security testing proxy. It sits between your application and the world, records the traffic, and runs scripts against it: an active script sends payloads, a passive script inspects responses, a request or response processor rewrites traffic on the way through. The engine is general. The knowledge of what to actually try lives in the scripts.

That is why a script collection is not a trivial repository. Without one, ZAP gives you a browser-driven scanner and a lot of configuration. With one, you get concrete checks that somebody already wrote, tested against somebody else's application and found a problem with.

The community-scripts repository is exactly that collection. The project description calls it a collection of ZAP scripts and tips provided by the community, with pull requests very welcome, and the README opens with the same idea in plainer words: a collection of ZAP scripts provided by the community, in other words by the readers of the project.

The audience is ZAP users who want a starting set of rules that is better than nothing and cheaper than writing their own, and the secondary audience is the people who contribute a script when they find a check that ZAP ought to have.

The licence is Apache-2.0, the repository is not archived, and the last push was on 2026-10-01, so scripts are still being added. The releases are versioned as the add-on, with v19 from 2024-07-01, v18 from 2024-01-29 and v17 from 2023-06-28, and the CHANGELOG.md at the root is where the additions are listed.

The categories, which are the ZAP script types

The directory listing is the taxonomy, and it maps directly onto the way ZAP attaches scripts to a scan.

There are active/ and passive/ directories, which are the two halves of the scanning model: active scripts attack, passive scripts observe. Then there are the processing directories, httpsender/ for request and response processors, payloadgenerator/ and payloadprocessor/ for the payload machinery, and httpfuzzerprocessor/ for the fuzzer. proxy/ holds scripts that act on traffic passing through the proxy, selenium/ holds browser-driven scripts, sequence/ holds scripts that replay a recorded sequence of requests, and session/ holds scripts that manage the scanning session as a whole. standalone/ holds scripts that run on their own rather than as part of a scan, and extender/ and variant/ handle extension of ZAP itself and of other scripts. The websocket directories, websocketpassive/ and websocketfuzzerprocessor/, cover the WebSocket side of the protocol, and there is authentication/ for scripts that handle authentication, and encode-decode/ for encoding and decoding helpers. other/ is the drawer for everything else.

The point of the split is that the category decides when a script runs and what it is given. A passive script sees a response and reports; an active script is handed a request to mutate; a request processor sits in the path and can rewrite what is sent. A script in the wrong place does not error, it simply never fires, which is the single most common reason a new contributor's script appears to do nothing.

For a user, the categories are a way to think about which parts of a scan to trust, and for a contributor they are the instructions for where a file belongs.

Installing: the Marketplace add-on, or a local clone

The easiest way to use the repository in ZAP is to install the Community Scripts add-on from the ZAP Marketplace. That is the whole installation for the intended user, and it is what the project documentation puts first.

The alternative is for people who intend to contribute or to modify what they run. You clone the repository to a local directory and then add that directory to ZAP using the Options and Scripts screen. The documentation points at the Scripts Tab, which you display with View, then Show Tab, then Scripts Tab, and that is where you manage the scripts once they are loaded.

There is a third path for anyone building their own tooling: the ZAP scripting documentation and the internal scripting wiki are linked, and there is a video called ZAP Deep Dive: Scripting ZAP, about 28 minutes long, which is the fastest way to understand the API that every script in this repository is written against.

The scripts are then enabled per script, or per group, in that tab, and the scope of what you run is the scope of what you trust. A script that sends a payload to a live application changes state, and a script that is enabled against a production endpoint is a decision about production.

For discussion, the project points at the zaproxy-scripts group on Google Groups, which is where questions about how a script should be written get answered.

The caution note, and what review means in practice

The project documentation carries a caution callout, and it is the most important paragraph in the project.

It says that while the project does review all scripts to ensure they do not do anything obviously malicious, you should still review them and use them with caution.

That is a careful and honest formulation, and it deserves to be read as a design statement rather than a disclaimer. The review that is performed is a check for the obviously malicious: a script that exfiltrates data, phones home, or hides something. That is a meaningful gate and it is a low bar, because such a script would be easy to spot.

What review cannot do is tell you whether a script is appropriate for your application. A script that fuzzes a parameter is legitimate in a test environment and unacceptable against a system that sends email, charges cards, or moves money. A script that deletes a record on a 500 response is a bug in one context and the point of the exercise in another. The scripts here were written against other people's applications, and the assumptions they encode are theirs.

The practical consequence is that a script collection is a source of starting points, not a finished scanning policy. The work of adopting it is deciding which scripts you run, against which targets, and how you review the findings afterwards.

One more constraint on the mechanics: for .py scripts to be visible, you must have the Python Scripting add-on installed, and the same applies to Ruby and Kotlin. The repository is mostly JavaScript, which ZAP runs natively, but the scripts are written in several languages and the ones in a language you have not installed simply do not appear.

Licensing, file extensions and the one rule contributors must not break

All scripts in the repository are released under the Apache v2.0 licence, and the project is explicit about what submitting a script means.

By submitting your scripts to the repository you are releasing them under the Apache v2.0 licence. However, you may optionally also release them under more lenient licenses via comments in the scripts. That is a specific and useful mechanism: a contributor who wants their script to be usable in a codebase under a more permissive licence can say so in a comment, and a consumer can then rely on that, while the repository's default for everything is Apache 2.0.

There is one mechanical rule for contributors, and it is the one most likely to be forgotten: please ensure that scripts submitted have the correct extension for the language they are written in. The consequence of getting it wrong is the same as the language add-on problem above, since ZAP decides what a file is by its extension and by the engine it maps to.

The build side is conventional for a ZAP add-on. The project uses Gradle to build it, and you run:

    ./gradlew build

in the main directory of the project, and the add-on is placed in the build/zapAddOn/bin/ directory. The top-level files are the ones you would expect for a Gradle project, with build.gradle.kts, settings.gradle.kts and the wrapper, alongside CHANGELOG.md, CONTRIBUTING.md and RELEASING.md, and a src/ directory for the add-on wrapper itself alongside the script directories.

The repository also carries a .gitattributes file, which is worth noticing in a collection where file extensions decide how a file is executed, because it is what keeps line endings and diffs consistent across a community of contributors on different platforms.

Maintenance, the release cadence and where a script collection is the wrong answer

The project is not archived, the last push was on 2026-10-01, and the released add-on versions are v19 from 2024-07-01, v18 from 2024-01-29 and v17 from 2023-06-28. The pattern is a versioned add-on release every six months or so, with the scripts themselves changing more often between those points, which is exactly the shape you would expect for a repository whose contents are contributed by many people and shipped as one package.

The practical risk in that pattern is version skew. The Marketplace add-on is tied to a ZAP version, and a script written against a newer ZAP API may not work on an older one, so the add-on version and your ZAP version have to be chosen together. The CHANGELOG.md is the place to look when a script behaves unexpectedly.

Where this repository is the wrong tool is worth saying plainly. It is a rule library for a dynamic scanner, so it cannot tell you whether your application is vulnerable to a business logic flaw, an access control problem that needs a human account, or a design issue that no payload will find. Those need a different kind of work entirely, and no quantity of scripts substitutes for them.

It is also not a replacement for reading the ZAP scripting documentation if you intend to write your own scripts, because the collection is a body of examples rather than a guide, and the linked video and wiki are where the API is explained.

What it is good for is the first hour of using ZAP. A fresh install with no scripts finds very little. A fresh install with these finds a useful baseline, and a team that reads the ones that fire on their application, keeps what fits, and discards the rest has a defensible starting position. That is a good trade for something Apache licensed and contributed in the open, and the caution note is the part that makes it safe to accept.

Editorial conclusion

Adopt the ZAP community scripts add-on if you run OWASP ZAP for dynamic application security testing and want a set of working rules, payloads and processors that other practitioners have already written. Do not treat it as a substitute for understanding what each script does, because the project itself asks you to review what you run, and do not expect it to cover your application's logic, since a generic rule set cannot know your business rules. Before you enable it in a scan, read the scripts that fire on your target, and check that the language add-ons you need are installed, since a script in a language you do not have will simply not run.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. zaproxy/community-scripts on GitHub