1. Documentation
  2. Continuous Fuzzing
  3. Setup - Web Application Fuzzing

Fuzz Testing an Azure Web App

How to deploy a Java Web App to Azure with CI Fuzz Java agent as part of your CICD pipeline and fuzz it

TIP: Some of the screenshots in this tutorial have small text. Use right click -> open image to view the full size screenshot.

Azure App Service Setup

Go to portal.azure.com, select App Services, Create

Pick settings that suit your application, and give it a unique name.

Create or select a Resource Group and note down it's name.

Fuzzing an Azure Web App


In this example, we will use Webgoat and Github Actions. We will choose to deploy jarfiles, that we will build with every commit. That way any changes that someone creates pull requests for will be deployed to Azure and fuzzed. For this, we will pick the "Code" option.

Since our compiled Webgoat jar includes a server, we will pick Embedded Web Server.

complie jar

Create a service plan and pick a SKU (stock keeping unit, which is a pricing/performance option). For Webgoat, B1 should be enough.

create a service plan and pick a SKU

It is a good idea to block all access to our application and only allow traffic from your fuzzing server (which needs it to send http requests to our application), your computer (for debugging) and the machine that will run your CICD pipeline. The first 2, we can set in Azure Portal. Click on your application, networking, access restriction.

 block all access to our application

Click Add Rule. Add rules for your public IP and your fuzzing server. You can find your public IP for example at:


Add rules for your public IP and your fuzzing server

Choose any names for the rules, priority is not important in our case, but must be filled. Paste your IP address with /32 at the end (an IP range that contains only this one IP address). You can leave the HTTP headers empty.

You will see that a "Deny all" rule will be automatically added at the end, which is exactly what we need.

Fuzzing Server firewall configuration

If you are using your own fuzzing server, it must be reachable from the deployed application on ports 6773 and 6777-7777.

Service Principal

A Service Principal in Azure is an account that serves one purpose and should have minimum privileges to do so. Ours will be used to deploy and modify our application. Create it with the az command line tool:

az ad sp create-for-rbac --name "webgoatfuzzing" --role contributor \

--scopes /subscriptions/yoursubscriptionID/resourceGroups/yourresourcegroup/providers/Microsoft.Web/sites/webgoatfuzzing \

replace yoursubsriptionID, your resource group, and webgoat fuzzing accordingly.

You can find your subscription ID by going to azure portal and clicking on Subscriptions.

This command will output a JSON which contains all information needed to log in as this Service Principal. Save this JSON.

Changes in project repository

Now we need to tell CI Fuzz what to fuzz. Go to


edit yaml files of all the fuzz targets you want to run, and set the correct endpoint:

base_url: http://webgoatfuzzing.azurewebsites.net:80

replace webgoat fuzz testing with your Service Application name.

Azure supports running apps only on ports 80 and 443.

The Java Agent also needs to be put in the repository at the time of writing. In the webgoat example, we will put it to the "webgoat-server/" directory, as that is what we are going to deploy (explained later in the deployment step).

cp -L ~/bin/fuzzing_agent_deploy.jar webgoat-server/

add the changes:

git add -f webgoat-server/fuzzing_agent_deploy.jar .code-intelligence/fuzz_targets/*yaml

CICD Settings

We need to add Azure deployment and fuzzing to the CICD pipeline. This tutorial only explains the deployment part. First, you should add fuzzing. See Contiuous Fuzzing Setup.

Github actions is used as an example here, so we are editing 


TIP: Yaml files are sensitive to indentation. If you copy paste configuration from this tutorial, please make sure it is correct, otherwise the Github Actions file will not run.

Add these additional steps before fuzzing:

Checkout repository

Needed so that we can build the application with code changes.

- name: Checkout repository
uses: actions/checkout@v2

Set up Java

so that we can compile

- name: setup Java 11
uses: actions/setup-java@v2
# If your pom.xml <maven.compiler.source> version is not in 1.8.x,
# change the Java version to match the version in pom.xml <maven.compiler.source>
java-version: '11'
distribution: 'adopt'
cache: 'maven'

adjust version and build system for caching accordingly.

Build application

- name: Build with Maven
run: |
#set port 80, as Azure does not support 8080:
sed -i 's/8080/80/g' webgoat-container/src/main/resources/application-webgoat.properties
mvn clean package -DskipTests --batch-mode --file pom.xml

Adjust build command according to the way your application is built.

Azure login

- name: Login
uses: azure/login@v1
creds: $

For this to work, go to the github actions web interface and create a new secret. Call it AZURE_CREDENTIALS and paste the JSON that you got when creating the Service Principal as value.

IP Whitelisting

Find the public IP address of the machine where the CICD script is running and allow it to access the web application in Azure.

- name: Public IP
id: ip
uses: haythem/public-ip@v1.2

- name: Whitelist this runner's IP
uses: azure/CLI@v1
inlineScript: |
az webapp config access-restriction add -g yourResourceGroup -n webgoatfuzzing --rule-name githubactions --action Allow --ip-address $ --priority 200


This is the crucial step. We need to deploy both our application and the Java Agent. Fortunately, Azure supports deploying a directory from the filesystem. The contents of this directory will then end up under the following path:


In our example we will use the azure-webapp github action. This is how the result looks like for Webgoat on our SaaS platform:

- name: 'Deploy to Azure WebApp'
uses: azure/webapps-deploy@v2
app-name: webgoatfuzzing
package: $/webgoat-server/
startup-command: timeout 2400 java -javaagent:/home/site/wwwroot/fuzzing_agent_deploy.jar=tls=true,api_token=$,instrumentation_includes="org.owasp.webgoat.**",fuzzing_server_host=app.code-intelligence.com,service_name=projects/yourProjectName/web_services/webgoat -jar /home/site/wwwroot/target/webgoat-server-8.0.0-SNAPSHOT.jar --server.address=

For the Java Agent arguments, please see the web services section in your project in CI Fuzz web interface. Also adjust the "package" setting, application name and startup command according to how your application is started. Set the fuzzing server hostname. API token should be stored in a github action secret, as explained in Continuous Fuzzing Setup.

The timeout command is there so that the application is stopped after fuzzing is done. The delay should be slightly more than the max_runtime setting in .code-intelligence/project.yaml.

If everything goes well, this step should deploy the application.

Remove IP whitelisting

This Github Runner machine will soon be used by someone else, let's not give them network access to our application.

- name: Remove runner IP whitelist entry
uses: azure/CLI@v1
inlineScript: |
az webapp config access-restriction remove -g yourResourceGroup -n webgoatfuzzing --rule-name githubactions


At this point, continue with the fuzzing actions generated by CI Fuzz Web Interface, as explained in Continuous Fuzzing Setup.

Push changes to git repository

git add .github/workflows/main.yml
git commit -m 'Deploy application to Azure before starting fuzzing'
git push

If everything goes well, the Github Actions script should now run. It should deploy and fuzz the application.

You can see the complete setup in this Github repository.