October 3, 2023

GoTestWAF is a tool for API and OWASP attack simulation that supports a wide range of API protocols including REST, GraphQL, gRPC, WebSockets, SOAP, XMLRPC, etc. It was designed to evaluate web application security solutions, such as API security proxies, web application firewalls, IPS, API gateways, and others.

Tool Execution

The usage is simple. It only requires that you run this tool against your WAF protected application. 

docker run -v /tmp:/tmp/report gotestwaf –url=http://the-waf-you-wanna-test/

It gives clear results and indicates which of the attacks are detected with your existing appsec solution and what ways attackers can still hit your apps:

owasp   path-traversal   6/18  (0.33)

owasp   sql-injection    4/16  (0.25)

owasp   ss-include       2/8   (0.25)

owasp   xml-injection    6/8   (0.75)

owasp   xss-scripting    4/12  (0.33)

owasp   ldap-injection   0/8   (0.00)

owasp   mail-injection   3/12  (0.25)

owasp   nosql-injection  0/18  (0.00)

owasp   shell-injection  3/8   (0.38)

owasp   sst-injection    5/20  (0.25)

It’s a simple yet powerful tool that supports not only pre-defined payloads but also API requests, such as REST, SOAP, and XMLRPC, and custom encodings like Base64, which can be extended easily.

The main idea is to encode and place attack payloads in different parts of an HTTP request: its body, headers, URL parameters, etc. To simplify things, we decided to implement the following logic:

Payload -> Encoder -> Placeholder

It means that every payload sample (malicious attack sample such as an XSS string like “<script>alert(1)</script>”) will be first encoded in some way then placed into an HTTP request. There is also an option to use a plain encoder that keeps the string as-is.


To make tests readable, we introduced a YAML DSL with an equal structure (payload->encoder->placeholder), where all the fields are arrays and make a test by permutations between them.

There is an Alpine-based Docker image available. It is ready to start out-of-the-box with a single command-line right after “git clone” and “docker build”:

$ git clone https://github.com/wallarm/gotestwaf

$ docker build . -t gotestwaf

$ docker run -v /tmp:/tmp/report gotestwaf –url=http://the-waf-you-wanna-test/

The only parameter here is a directory where the PDF report will be placed. If you need the report, you are required to map it from your host machine via -v docker attribute. Otherwise, all the stats will be available in your console only.

Command-line flags have priority over configuration files. As you can see, the most important thing here is how to detect a blocking page. Currently, you can do it with a response status or RegExp that will be applied to the request body. By default, the 403 response status code will be used for this.


The main goal of this tool is to easily generate readable reports to check the current state of protection according to OWASP guidelines. 


To see what it looks like, we can install mod_security WAF and run it on the 8080 port:

git clone https://github.com/SpiderLabs/owasp-modsecurity-crs

cd owasp-modsecurity-crs/util/docker

docker build -t modsec_crs –file Dockerfile-3.0-nginx .

docker run –rm -p 8080:80 -e PARANOIA=1 modsec_crs

The PDF version will also contain a summary with an overall score, like the one below:

It will also include a few details about which attacks were passed instead of blocked:

For the technical details about payload, encoders, and responses, you can check the CSV file that will be generated in the same folder as PDF report.


Leave a Reply

%d bloggers like this: