1. Documentation
  2. Fuzzing in the JVM
  3. Finding your first bug in Java Spring Boot

Creating a Spring Boot Fuzz Test

How to create a spring boot fuzz test

Once the initialization process is complete, your application needs to be analyzed to discover controllers to fuzz.

To do this, click the pen icon in the upper right corner and select Edit web apps.

Then click ANALYZE WEB APP. You can use several methods, but you can use the easy-to-use Spring Boot option since this is a Spring Boot application.

Usually, you want also to set a Spring Boot profile, i.e.


After submitting, you should see a list of controllers.  Now you can create a fuzz test. To create a fuzz test for a Spring Boot application, go to the sidebar menu in the dashboard and click on the “Add Fuzz Test” button.


From the list, choose to create a Java Web App Fuzz Test.


After selecting it, you will be forwarded to the second step, where you can name the new Fuzz Test and specify which endpoints you want to test. In case your project builds multiple applications (Webgoat actually builds two), you can select the application you’re interested in testing.


By default, the automatically generated fuzz test will test all the endpoints detected during the initialization phase. If you’re more interested in testing selected endpoints, you can filter and select the endpoints to test.

For this example, we will focus on the “/challenge/5” endpoint and call the new fuzz test “FuzzChallenge5”. Deselect all the controllers using the button “Deselect all,” then search for the controller /challenge/5 and select it. See the image below.


Advanced Settings

With CI Fuzz, you can also change several advanced aspects of your Spring Boot Fuzz Test. Just click on the Fuzz Test you want to modify in the Fuzz Tests sidebar.


This will lead you to the configuration window of the selected fuzz test:


Setup Requests

If your Spring Boot Application uses authentication, which can not be disabled for test environments, you can configure CI Fuzz to authenticate before it starts fuzzing. You can do this by defining the requests that have to be made to successfully log in to the application. For example, in the screenshot above, the fuzz target first registers with a dummy user and then logs in with it, as shown in the “Setup Requests” section.

Request Templates

During the initialization, CI Fuzz scanned all the endpoints that your application offers. This scan allows us to identify the types of requests that are expected at every endpoint. This allows us to craft valid requests against the applications endpoints and fuzz only interesting parts of the requests (e.g., only parameter values, not parameter names). This smart fuzzing approach allows you to reach code deep inside your application's business logic. In case you want to modify or add new requests, you can modify the request templates (method, URI, headers, and body) for the selected fuzz test.

Attention! You must click the little checkmark after making changes to a request template; otherwise, the UI won't change them!


Packages Filter

Here you can define which parts of the application should be instrumented by CI Fuzz. Instrumenting the code is a requirement for feedback-based fuzzing. Instrumentation allows our fuzzers to automatically increase the code coverage reached by its test cases through the feedback they get through instrumented code. But instrumentation also slows down the code. To slow down the fuzzers too much, you can specify which packages you want to be instrumented. By default, only your application package will be selected, and no external dependencies will be instrumented. If you want to enable instrumentation of external dependencies or disable it for parts of your application, this setting will allow you to do so.

Exception Policies

With exception policies, you define what kind of behavior is considered erroneous during the fuzz test. Imagine fuzzing an endpoint that returns information about a resource based on a given numerical id /resource/{id}/. This endpoint will respond to requests like /resource/1/, /resource/99/, /resource/1223/ etc. For a request like /resource/XYZ/, it would be appropriate for the application to throw an error of type 404, indicating that the server could not find the resource. Therefore it is a good idea to ignore errors of type 404 for this fuzz target. Errors in the business logic (often declared as errors of type 500-511) should still be considered harmful.

In CI Fuzz, these kinds of settings are called exception policies. They can be set per project, per fuzz target, or as a combination of both.