Using ZAP to write automated regression test cases.

What are different type of ZAP script?

  1. Stand Alone: scripts that are self contained and are only run when your start them manually
  2. Active Rules: these run as part of the Active Scanner and can be individually enabled
  3. Passive Rules: these run as part of the Passive Scanner and can be individually enabled
  4. Proxy Rules: these run 'inline', can change every request and response and can be individually enabled. They can also trigger break points
  5. HTTP Sender: scripts that run against every request/response sent/received by ZAP. This includes the proxied messages, messages sent during active scanner, fuzzer, …
  6. Targeted Rules: scripts that invoked with a target URL and are only run when your start them manually
  7. Authentication: scripts that invoked when authentication is performed for a Context. To be used, they need to be selected when configuring the Script-Based Authentication Method for a Context.
  8. Script Input Vectors: scripts for defining exactly what ZAP should attack
  9. Extenders: scripts which can add new functionality, including graphical elements and new API end points

Why does ZAP automatically disable all scripts?

All scripts that are run automatically are initially 'disabled' - you must enable them via the The Scripts 'tree' tab before they will run. If an error occurs when they run then they will be disabled. When you select the script then the last error will be shown in the Script Console tab. Targeted scripts can be invoked by right clicking on a record in the Sites or History tabs and selecting the 'Invoke with script…' menu item.

Can we use all scripting language for all script types?

All scripting languages can be used for all script types, but only those languages that have been downloaded from the ZAP Marketplace will typically have templates. However you may well be able to adapt a template for another language. If your favourite language is not available on the Marketplace then please raise a new issue via the "Online/Report an issue" menu item. In the meantime you can just place the relevant jars in the 'lib' directory (not the 'plugin' directory) and restart ZAP.

Can we have global variables?

Yes. Variables can be shared between all scripts via the class org.zaproxy.zap.extension.script.ScriptVars. For example in Javascript you can use this class as follows:


Can we have script variables?

Yes. Variables can be shared between separate invocations of the same script via the same org.zaproxy.zap.extension.script.ScriptVars class. For example in Javascript you can use this class as follows:

org.zaproxy.zap.extension.script.ScriptVars.setScriptVar(this.context, "","value")
org.zaproxy.zap.extension.script.ScriptVars.getScriptVar(this.context, "")

Note that these methods are only usable from scripting languages that provide access to the ScriptContext (like Javascript).

How can we speed up ZAP by configuring Global Exclude URL?

  1. Click on Tools -> Options -> Global Exclude URLs
  2. Select appropriate check boxes
  3. Click the OK button

How can we speed up ZAP by turning off certain attack categories?

  1. Click on Tools -> Active Scan -> Policy
  2. Click on various links in the left hand side
  3. On the right hand-side, under the Threshold column we can change it to OFF.
  4. Click on the OK button

Perhaps, to make the above steps persistent across restarts:

  1. Click on Analyze -> Scan Policy Manager
  2. Click on "Default Policy"
  3. Click on Modify
  4. Click on various links in the left hand side
  5. On the right hand-side, under the Threshold column we can change it to OFF.
  6. Click on the OK button

How can we speed up ZAP?

ZAP usually attack every parameter on every page. The time a scan takes is therefore based on: [Number pages] x [number parameters] x [number attacks] x [how long a request takes] / [number of threads]

There will be a practical limit to the number of threads that will actually be useful – you will always be limited by the network and the amount of processing power on both the target application and the attacking machine (especially if they are the same!). So if you have a very large application with lots of pages and parameters running on a relatively slow machine then with a default configuration any scanner will take a long time to complete!

However most scanners are very configurable, so even if you do have a massive application there are lots of approaches you can use. When investigating performance issues with ZAP I recommend running it with the UI even if you want to run it in headless mode in the end – it will allow you to see whats going on much more effectively. The most important thing is to identify the underlying causes, and there are many possibilities, any or all of which could be the culprits:

  1. Target application/machine overloaded
  2. Attacking machine overloaded
  3. Network overloaded
  4. Firewall throttling connections
  5. Spider looping
  6. Too many pages + params + tests
  7. Inappropriate tests
  8. Badly written tests
  9. Unnecessary / duplicated tests

It is worth identifying hardware and network related issues first. Have a look at the CPU usage on both the target and attacking (the one with your scanner) machines – are either of them excessively high? If either machine is underpowered or with low memory then you may need to look at using more powerful machines. Check the target application logs – ZAP has a tendency to overwhelm applications that are not designed with high performance in mind.

Crucially you should look at the number of requests that ZAP is making. Both the Spider and Active Scanner dynamically report the URLs that they have accessed. The Spider shows a count of URIs it has found on its toolbar – you can expect this to rise quickly at the start and then tail off as the Spider progresses: zap-perf-spider-sm-252x34.png
The Active Scanner has a “Scan Progress Detail” popup accessible from its toolbar that shows the time each rule has taken, the total number of requests and the time each request took: zap-perf-ascan1b-252x110.png

How fast requests can be made will depend on many factors, but if each request is taking over a second then you are likely to have a hardware or network problem that is outside of the scope of this blog post! If requests are taking an excessively long time then check to see if there is something on your network that might be throttling the connection, having identified ZAP as a potentially malicious tool.

If the spider never completes then have a look at the requests it is making. If it appears to be making very similar requests then it might have got stuck in a loop. This shouldnt happen – there is code to prevent that – but if it does then you should report the problem and in the meantime you can use regex excludes to prevent the spider accessing the links that cause it problems.

Have a look at the “Scan Progress Detail” popup after the scan has completed – this will show you which rules were run and how long they each took. If one rule is taking significantly longer than the other then there may be a problem with it – report it and we’ll look into it. This is more likely with the alpha and beta scan rules than the release quality ones. Also have a good look at which rules are being run – if you know your application is definitely not using an SQL database then there is no point running those rules. You can configure which rules are run via the Policy dialog which is also linked off the Active Scan toolbar: zap-perf-ascan2b.png
There are also various spider and active scanner options which you should double check – the defaults are good for most cases but may have been changed or may not be suitable for your environment. These are accessible via the top level “Tools/Options…” menu or from the relevant toolbar: zap-perf-ascan3b-252x108.png

Check that they are set to sensible values – click on the blue ‘?’ help icon in the top right hand corner as this gives much more information about the parameters. Be especially aware of the active scanner “Delay when scanning in milliseconds” – this should usually be set to zero, particularly if the scan is taking too long. The “Attack Strength” is also important – this is roughly the number of requests you can expect each rule to make on every parameter on every page. All rules are unique and some only ever use a very small number of requests, but in general assume:

  1. Low – to be up to 6 requests
  2. Medium – to be up to 12 requests
  3. High- to be up to 24 requests
  4. Insane- to be over 24 requests, potentially hundreds

The default is Medium – you should not go higher than this if you are having performance problems. In a future release we are planning on allowing the Attack Strength to be configured on a per rule basis.

Also be aware that while the the “Handle anti CSRF tokens” option is very useful if your application uses anti CSRF tokens, it can significantly impact performance as it forces the scanner to run single threaded.

The final recommendation can potentially have the biggest effect. Have a look at the structure of your application in the Sites tree – are there a very large number of nodes anywhere in the application? I have been working with the Mozilla QA team to get ZAP security tests included in their Selenium service. One particular site was taking so long that they thought ZAP had hung – it hadnt, but in the end took 13 hours to complete the scan! When I looked at the Sites tree I found that one node had many thousands of children. It turned out that this part of the application was data driven, and there were a very large number of records which all ‘generated’ multiple pages. So ZAP was attacking the same code in the same way thousands of times, which was pointless – the important thing is to attack the code, not to worry about all of the data held in the db. We fixed this by adding a “Exclude from scanner” rule. We could have excluded the whole subtree, but we wanted to scan the code at least once, so we came up with a regex expression similar to: ".*/bigsubtree/(?!justincthispart).*" which excluded everything apart from a relatively small subset of the child nodes, ie the “justincthispart” subtree under “bigsubtree”.

One of the most important configuration settings was the removal of unnecessary scanner rules (configured in the Scan Policy menu). I would also suggest that if a scan takes a long time, you can break it down into several iterations using different scan rules each time.

You mentioned the Anti-CSRF token and I can’t agree more. It had a drastic impact on performance when turned on. It’s worth remembering to turn it off, since ZAP saves your last settings.

Attacking single nodes using the Active Scan Subtree (or defining Scopes) will also assist in preventing slow scan/freeze.

Nexus scanner

// What to configure
Pages to ignores (logout, static pages that does not contain any forms)
Anti CSRF tokens
Session handling
Structure (single page apps)
Non-standard separators, e.g. aaa:bbb;ccc:ddd

To switch ZAP to safe mode, click the arrow on the mode dropdown on the main toolbar to expand the 
dropdown list and select Safe Mode.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License