Response Parameter Injection - slightly hidden gems

06-05-2025 By Philip Meier Kreutzer, Security Advisor

Response Parameter Injection

This type of injection is one I have read about in a blog post a few years ago, but I have not been able to find the original blog post, which I thought explained this topic very well, so instead you are left with my best attempt. The name of the injection technique seems to have several different names.

The first name for the injection, from the aforementioned blog post, was "Response in Request injection". I have also seen it addressed as a "Structured Format Injection" in another blog post, but from brief discussions on the PortSwigger Discord, some people referred to it as a "Response Parameter Injection", which I found the most fitting.

What is it?

A response parameter injection is not really an injection in the classical sense. While it still fits the typical M.O. of injecting more functionality into an endpoint than expected, it is not that you are injecting malicious "standard" operations into the application. Instead, you are injecting additional parameters into a request, that modifies the state of the application. As such, we are looking at application logic abuse, which is enabled by a lack of restriction on the input an endpoint can and should receive.

This type of vulnerability is typically native to API calls, as the structured format of a request and response would overlap. With the ever-increasing number of APIs and even the rise of regular websites utilizing frameworks such as React and Angular, this attack vector might be more present than ever, but it seems to be rarely addressed, while it is something that we see becoming more common in web applications.

Example

Throughout this blog post, we will be displaying a simple example, which is the act of changing information of a user account. The theoretical webpage will be supporting JSON communication in order to make it more visible what is going on. It is worth noting that this type of attack is equally likely to happen through other types of formats.

The core principle of a response parameter injection is that the UI presents a set of functionalities, which is then sent to the server. Our example application presents an option to edit a user profile, which includes a first name, last name, and a phone number. We send this using a post request with the following JSON as input.

Post Request

{
  "FirstName": "Philip",
  "LastName": "Kreutzer",
  "PhoneNumber": "+4561102038"
}

Then the response from the web server includes the request, but also includes even more information in the same structure, an example could be JSON that would look like this.

Post response

{
  "FirstName": "Philip",
  "LastName": "Kreutzer",
  "PhoneNumber": "+4561102038",
  "UserId": "666",
  "Role": "user"
}

An adversary would then be able to guess that even though the user interface only presents fields for the first three fields, it could potentially allow for "hidden" parameters. To attempt this, one would usually use a proxy to intercept and add additional parameters in the JSON. The obviously interesting parameter to edit above is the "Role" parameter, which we could attempt to change its value to "admin". The following JSON would then be sent to the server.

Post Request - Injection

{
  "FirstName":"Philip", 
  "LastName":"Kreutzer", 
  "PhoneNumber":"+4561102038", 
  "UserId":"666", 
  "Role":"admin"     
}

In case of a successful attack, we are able to see it in the output, where it would show us the new updated user, now with a new role.

Identification

My advice for pentesters is to always spend a good portion of the start of a test learning how the application works and what it is capable of before attempting to exploit the application. A deeper understanding of the application usually leads to a more accurate estimate of what can be exploited and how. That does not hold true only for this type of vulnerability.

Further, some tools exist to automate part of this process as well. If using Burp Professional, it is possible to use the Param Miner extension. It does not automatically scan endpoints by default; however, it is possible to let it automatically scan.

I would not suggest automatically scanning all endpoints but instead scan specific endpoints that you find interesting, and which also have a request-response structure similar to what is shown in the example.

Similar work

During the writing of this blog post, I stumbled upon research and blogposts by Dana Epp, where one of these displays the usage of the Param Miner tool. I encourage any testers looking to search for this type of vulnerability to go check out his blog post regarding how to find hidden API parameters, which is essentially a way of utilizing this method, but in other cases where it is not made as clear by the application that it can be possible.

He also has a good blog post on this specific technique, calling it "Structured Format Injection". While trying to exploit and explain this, I was unable to find the blog post, but in the process of writing this I discovered it. In the spirit of trying to make it easier to find material on this technique, I decided to release my own take on the vulnerabilities.

Want to uncover the vulnerabilities in your company?

Let our specialists test your IT security. Read more about our web application security testing or web service security testing and see how we can help you secure your systems.