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 settings

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. This can be done 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 can be seen 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 (eg. only parameter values, not parameter names). This smart fuzzing approach allows you to reach code deep inside your applications business logic. In case you want to modify or add new requests, you can modify the requests templates (method, URI, headers, and body) for the selected fuzz test. settings

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. In order not to slow down the fuzzers too much, you can specify which packages you want to be instrumented. By default, only your applications 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 behaviour is to be 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 resource could not be found. 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.