Active Scan Rules - Alpha

The following alpha quality active scan rules are included in this add-on:

An example active scan rule which loads data from a file

This implements an example active scan rule that loads strings from a file that the user can edit.
For more details see: Hacking ZAP Part 4: Active Scan Rules.

Latest code:

Cloud Metadata Attack

Attempts to abuse a misconfigured NGINX server in order to access the instance metadata maintained by cloud service providers such as AWS, GCP and Azure.
All of these providers provide metadata via an internal unroutable IP address ‘’ - this can be exposed by incorrectly configured NGINX servers and accessed by using this IP address in the Host header field.

Latest code:

.env Information Leak

Checks for web accessible .env files which may leak sensitive information (such as usernames, passwords, API or APP keys, etc.).

Latest code:

Example Active Scan Rule: Denial of Service

This implements a very simple example active scan rule.
For more details see: Hacking ZAP Part 4: Active Scan Rules.

Latest code:

Hidden File Finder

This scan rule checks for various web accessible files which may leak administrative, configuration, or credential information. The original included set of payloads were based on Snallygaster by Hanno Böck. Such payloads are verified by checking response code, and content. If the response code is 200 (Ok) then additional content checks are performed to increase alert confidence. If the response code is 401 (Unauthorized) or 403 (Forbidden) or the content checks are un-successful then an alert is raised with lower confidence (at HIGH Threshold). Note: If the Custom Payloads addon is installed you can add your own hidden file paths (payloads) in the Custom Payloads options panel. For custom payloads only the response status code is checked. If there is a requirement to include a content check then it is also possible to add payloads to the json/hidden_files.json file in ZAP's user directory (in which case they will be treated as included payloads).

The following describes the fields of the JSON entries.

  "content":["content you want to find in responses"],
  "not_content":["content you do not want the response to have"],

Details worth noting:

  • The only field that is required is path.
  • The fields content, not_content, and links can have multiple quoted, comma separated values (arrays of strings).
  • Checks of binary content are based on starting position 0 (ex: startsWith not contains).

The following is an example JSON entry:


Latest code:

LDAP Injection

LDAP Injection may be possible. It may be possible for an attacker to bypass authentication controls, and to view and modify arbitrary data in the LDAP directory.

Latest code:

NoSQL Injection - MongoDB

This rule attempts to identify MongoDB specific NoSQL Injection vulnerabilities. It attempts various types of attacks including: boolean based, error based, time based, and authentication bypass. It will also attempt JSON parameter specific payloads if the scan is configured to include JSON parameter variants. Latest code:

XSLT Injection

This scan rule checks for certain responses induced by injecting XSL transformations.
It attempts to obtain those responses with payloads which may induce: error responses, disclosure of library/framework vendor name, remote port scanning, or command execution.

Latest code: