1. Home
  2. Docs
  3. Examples
  4. HTTP Password-based Authentication

HTTP Password-based Authentication

Accessing certain areas of a web application may require users to authenticate using their credentials. Therefore, to test an application area that is only available to authenticated users, GUARDARA must perform authentication before testing the protected page/resource. During login, web applications most often expect to receive user credentials in the body of POST requests. In response to a successful authentication request, the web application returns a Session ID cookie which the web browser must submit with any subsequent requests when accessing protected resources.

This example demonstrates how to implement such an authentication mechanism in GUARDARA.


This example is the most advanced one out of all the authentication-related examples. It utilizes a lot more features to demonstrate what GUARDARA is really capable of.

We assume the reader is already familiar with the following topics:

We recommend quickly reading through the following before jumping into the implementation of the example:

Authentication Request

In this section we are going to discuss the implementation of a Message template to authenticate to our target. Successful authentication requires the following:

  • Submitting a POST request to the appropriate resource with the credentials included in the request body
  • Using a Content-Type header in the request to let the server know the format of the request body
  • Using a Content-Length header to tell the server the size of the request body

Basic POST Request Template

We can start out by modifying the GET request we used in the previous examples or starting from scratch. As the first step, we are going to:

  1. Make sure the request uses the POST method
  2. Update the resource as appropriate for our target
  3. Create a Group to serve as a placeholder for the request body

A screenshot with the updated template is shown below.

Content-Type Header

Next, we add the Content-Type header to the request to tell the web server what kind of data to expect in the request body. In case of WebGoat, the expected content type for the authentication request is application/x-www-form-urlencoded.

Now that we have the Content-Type defined (Header.ContentType group in the above example), it is time to create the Content-Length header. The value of the header is the length of the request body in bytes.


Instead of hardcoding credentials into the request, we define two session variables, one for the username and another for the password. The screenshot below shows an example of such session variables.

Next, we implement the request body that includes the credentials. As the Content-Type is application/x-www-form-urlencoded, we have to implement the body to match the below pattern.


We are going to use the Reference field to refer to the value of the session variables we have defined earlier. This can be seen below.

We are almost ready with our request. There is one important thing missing. If the username or password contained characters like & or = that would break the request body. For example, if we had the username mac&cheese and password password&s=, the request body generated by GUARDARA would end up being:


As can be seen, despite providing valid credentials, the web application would receive the username “mac and the password password. The Content-Type (application/x-www-form-urlencoded) of the request tells us exactly what we have to do: we have to URL encode the username and password. To do that, we have to apply the “URL Encode” transform on both Reference field. This is shown below.

Content-Length Header

The length of the request body may change, therefore we cannot use a hardcoded value for the Content-Length header. The length may change:

  • Based on the value of the username and password session variables we will define and refer to from the request body.
  • If we have any fields within the request body that we configured to be tested.

Therefore, we have to create the Content-Length header so that its value is calculated automatically, based on the value of the request body. The Sizer field can help with this.

Finally, let’s have a look at the preview to make sure our request looks like as intended.

Testing Credentials

We have created the authentication request to be able to customize the user credentials on a per-target basis within the Project. However, testing the username and password inputs during the test requires a slight modification to the Message template. We can use the Switch field to “merge” multiple fields into a single field within the template, where the first child of the Switch field is the default value. The remaining children of the Switch field will produce test cases.

As per the above, in the place of the username and/or password, we create a Switch field with two fields as its children: the first child is the Reference field to refer to the default value and the next one is a mutable String field. This setup is shown below.

If we take a look at the Preview of the Message we can see that this time GUARDARA is going to generate over four thousand test cases. Looking at some of the test cases using the Preview feature we can see the username and password fields being changed.

The above example also highlights one potential issue with our configuration: only the Reference fields have URL encoding enabled. As a result, mutations generated for the username and password fields by the String fields will not be URL encoded, thus likely not producing the desired behavior. The best way to handle this is to remove the URL encoding from the Reference fields and configure the Switch fields with the URL encode transform enabled.

Next Steps

Now that we have a request to perform credential-based authentication, we can continue to test an area of an application that requires an authenticated session. While we will leave this to the reader to implement, we provide some directions below.

  1. The Message Template of the authenticated request has to be created. Assuming that the web server expects a valid session ID as a cookie to track authenticated sessions the Message Template should have a Cookie header with a value represented by a Reference field. The Reference field should point to a variable in the session, for example: PHPSESSID
  2. A Test Flow Template has to be created where the first Send action gets the authentication request assigned, and the second Send action gets the authenticated request assigned. (An example flow: Connect, Send(authenticate), Receive, Send(authenticated), Receive, Disconnect)
  3. The first Receive action in the Flow Template should use a Response Processing Rule to extract the session ID from the response received from the server and store it in a session variable e.g. called PHPSESSID. This is, so the Reference field in the Message Template assigned to the second Send action can read the content of the variable and include it in the request.
Was this article helpful to you? Yes No