Web Parameter Manipulation: A Hacker’s Perspective on Client-Controlled Parameters

Web applications rely heavily on data supplied by the client to determine how requests are processed. Parameters carried through URLs, forms, cookies, request bodies, and headers can influence application logic, data retrieval, access decisions, and even how certain functions behave.

Because these values originate from the client, they should never be treated as inherently trustworthy. A parameter that appears to be nothing more than an id, role, price, redirect, or page value can become an important control point when the server fails to properly validate or authorize it.

Parameter manipulation is therefore more than simply changing a value and seeing what happens. It is about understanding which parts of a request the client can influence, how the server interprets those inputs, and whether changing them produces behavior the application was never intended to allow.

For example:

POST /api/order HTTP/1.1

{
    "productId": 101,
    "quantity": 1
}

POST /api/order HTTP/1.1

{
    "productId": 101,
    "quantity": 1
}

By capturing the request, changing a parameter, and sending it again, we can understand how the server processes client-controlled data and how its behavior changes when those values are manipulated.

1. URL Query Parameter Manipulation

URL query parameters are values included in the query string of a URL. They are commonly used to pass information such as IDs, search terms, filters, quantities, sorting options, and other values that influence how a page or endpoint behaves.

For example, a product page might use:

https://example.com/product?id=123&quantity=1

https://example.com/product?id=123&quantity=1

Here, id and quantity are query parameters supplied through the URL.

Manipulating the Parameter

A tester can modify one parameter at a time:

Original:
https://example.com/product?id=123&quantity=1

Modified:
https://example.com/product?id=123&quantity=5

Original:
https://example.com/product?id=123&quantity=1

Modified:
https://example.com/product?id=123&quantity=5

The modified URL can then be requested and compared with the original response.

What to Observe

_Compare the original and modified responses to understand _how the server processes the changed value and whether the modification produces unexpected behavior.

2. Path Parameter Manipulation

Path parameters are values placed directly inside the URL path. Applications commonly use them to identify resources such as users, products, orders, files, or other objects.

For example:

https://example.com/users/101/profile

https://example.com/users/101/profile

Here, 101 may represent a user identifier. Unlike a query parameter, it is part of the URL path itself.

Manipulating the Parameter

The tester can modify the value:

Original:
https://example.com/users/101/profile

Modified:
https://example.com/users/102/profile

Original:
https://example.com/users/101/profile

Modified:
https://example.com/users/102/profile

The modified URL can then be requested and compared with the original response.

What to Observe

Observe what resource the modified value refers to and how the application handles the requested object.

This helps reveal how identifiers in the URL are processed and whether access controls are properly enforced.

3. Form Parameter Manipulation

Form parameters are values submitted through HTML forms. They can include visible fields such as usernames and quantities, as well as hidden fields that are not displayed in the normal interface.

For example, a checkout form might submit:

POST /checkout HTTP/1.1
Content-Type: application/x-www-form-urlencoded

product_id=101&quantity=1

POST /checkout HTTP/1.1
Content-Type: application/x-www-form-urlencoded

product_id=101&quantity=1

A form can also contain hidden values:

<input type="hidden" name="price" value="500">

<input type="hidden" name="price" value="500">

Although the field is hidden from the interface, its value is still supplied by the client.

Manipulating the Parameter

A captured request might contain:

product_id=101
quantity=1
price=500

product_id=101
quantity=1
price=500

A tester can modify an individual value and resend the request.

What to Observe

Compare the response after changing the parameter.

The important question is whether the server independently validates the submitted value or simply trusts the value supplied by the client.

4. JSON Body Parameter Manipulation

JSON is widely used by modern web applications and APIs to exchange structured data. Instead of placing every value in the URL or a traditional form, applications can send multiple parameters inside a JSON request body.

For example:

POST /api/cart HTTP/1.1
Content-Type: application/json

{
    "productId": 101,
    "quantity": 1
}

POST /api/cart HTTP/1.1
Content-Type: application/json

{
    "productId": 101,
    "quantity": 1
}

Here, both productId and quantity are values supplied by the client.

Manipulating the Parameter

A tester can modify an individual value:

{
    "productId": 101,
    "quantity": 5
}

{
    "productId": 101,
    "quantity": 5
}

The modified request can then be sent and compared with the original response.

What to Observe

Observe how the application processes the modified JSON value.

JSON parameters can also appear as strings, numbers, Boolean values, arrays, or nested objects:

{
    "user": {
        "id": 123
    },
    "active": true
}

{
    "user": {
        "id": 123
    },
    "active": true
}

Each value can represent a different client-controlled input.

5. XML Body Parameter Manipulation

XML is another format used by web applications and APIs to exchange structured data. Although JSON is common in modern APIs, XML can still be found in applications, integrations, and services that rely on XML-based communication.

For example:

POST /api/order HTTP/1.1
Content-Type: application/xml

POST /api/order HTTP/1.1
Content-Type: application/xml

The request body might contain:

<?xml version="1.0" encoding="UTF-8"?>
<order>
    <productId>101</productId>
    <quantity>1</quantity>
    <price>500</price>
    <currency>USD</currency>
    <customer>
        <id>25</id>
        <type>regular</type>
    </customer>
    <notes>Test order</notes>
</order>

<?xml version="1.0" encoding="UTF-8"?>
<order>
    <productId>101</productId>
    <quantity>1</quantity>
    <price>500</price>
    <currency>USD</currency>
    <customer>
        <id>25</id>
        <type>regular</type>
    </customer>
    <notes>Test order</notes>
</order>

Here, the values inside the XML are supplied by the client.

Manipulating the Parameter

A tester can modify an individual value:

<quantity>5</quantity>

<quantity>5</quantity>

The modified request can then be sent and compared with the original response.

What to Observe

Observe how the application processes the modified XML value.

XML can also contain deeply nested elements, making it important to inspect the complete request when identifying client-controlled values.

6. Multipart/Form-Data Parameter Manipulation

multipart/form-data is commonly used when a request needs to send multiple types of content, particularly form fields together with file uploads.

A typical upload request might contain several separate parts:

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----Boundary

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----Boundary

The body might contain:

------Boundary
Content-Disposition: form-data; name="user_id"

123
------Boundary
Content-Disposition: form-data; name="description"

Test document
------Boundary
Content-Disposition: form-data; name="file"; filename="report.pdf"

[FILE DATA]
------Boundary--

------Boundary
Content-Disposition: form-data; name="user_id"

123
------Boundary
Content-Disposition: form-data; name="description"

Test document
------Boundary
Content-Disposition: form-data; name="file"; filename="report.pdf"

[FILE DATA]
------Boundary--

Here, user_id, description, and the uploaded file are all parts of the same request.

Manipulating the Parameter

A tester can identify an individual field:

user_id=123

user_id=123

and modify it before sending the request.

What to Observe

Compare the response with the original request and determine how the server processes the modified field.

The important point is that parameters can exist inside different sections of the same HTTP request.

Cookies are commonly used to maintain sessions and store client-side state between requests. Sometimes, however, the cookie value is not immediately readable. Applications may store information in an encoded, signed, or otherwise protected format.

For example, a cookie may contain a JWT rather than simple key-value data:

GET /profile HTTP/1.1
Host: lab.example
Cookie: session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJwbGFuIjoiZnJlZSIsImZlYXR1cmUiOiJiYXNpYyJ9.47H7X5TSLZQYp0vs9L5wZUWLvX5O5Mm4N72NZ3qjdJs

GET /profile HTTP/1.1
Host: lab.example
Cookie: session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJwbGFuIjoiZnJlZSIsImZlYXR1cmUiOiJiYXNpYyJ9.47H7X5TSLZQYp0vs9L5wZUWLvX5O5Mm4N72NZ3qjdJs

At first glance, the value of session is difficult to understand. Before attempting to manipulate it, we need to determine what format it uses and inspect its contents.

Manipulating the Parameter

After decoding a readable JWT payload, we may find values such as:

{
    "sub": "demo-user",
    "plan": "free",
    "feature": "basic"
}

{
    "sub": "demo-user",
    "plan": "free",
    "feature": "basic"
}

For example, the plan value may be:

plan=free

plan=free

A tester can investigate how changing such a client-controlled value affects the application's behavior in an authorized testing environment.

What to Observe

Observe whether changing the cookie affects the application's behavior.

If the cookie contains an encoded or signed value, first identify its format and understand how its contents are represented. Decoding a value does not bypass its signature or encryption. A signed value may become invalid when modified unless it can be legitimately re-signed.

The decoding process is covered in the "When Parameters Aren't Readable" section below.

When Parameters Are Encoded or Encrypted

The parameters we have discussed can sometimes contain values that are not immediately readable. Depending on how an application handles its data, values may be encoded, encrypted, or signed before being sent to the server.

When we encounter such a value, we first need to identify its format and determine how it can be decoded or inspected. A cookie is just one example — we may encounter similar values in other parts of a request as well.

For example, a cookie may contain a JWT:

session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJwbGFuIjoiZnJlZSIsImZlYXR1cmUiOiJiYXNpYyJ9.47H7X5TSLZQYp0vs9L5wZUWLvX5O5Mm4N72NZ3qjdJs

session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJwbGFuIjoiZnJlZSIsImZlYXR1cmUiOiJiYXNpYyJ9.47H7X5TSLZQYp0vs9L5wZUWLvX5O5Mm4N72NZ3qjdJs

We can use jwt.io to decode and inspect the readable parts of a JWT.

This process can work in both directions: we can decode or decrypt a value to understand its contents, and when the format and required cryptographic mechanism allow it, transform the modified data back into the format expected by the application before testing it. For encoded data, this means decoding → modifying → encoding again. For encrypted data, it means decrypting → modifying → encrypting again with the appropriate key and method. For signed data such as JWTs, the modified value must also have a valid signature if the server verifies it.

Conclusion

Understanding how applications handle encoded and encrypted data gives us a better view of what happens behind the scenes. What may look like meaningless data can often reveal important logic when we understand how it is processed.

The real value is not in simply decoding or encrypting data, but in understanding the entire flow and thinking about how that process could be secured. Hopefully, this article gave you a practical starting point for looking at data from a security researcher's perspective.

Contents

1. URL Query Parameter Manipulation

Manipulating the Parameter

What to Observe

2. Path Parameter Manipulation

Manipulating the Parameter

What to Observe

3. Form Parameter Manipulation

Manipulating the Parameter

What to Observe

4. JSON Body Parameter Manipulation

Manipulating the Parameter

What to Observe

5. XML Body Parameter Manipulation

Manipulating the Parameter

What to Observe

6. Multipart/Form-Data Parameter Manipulation

Manipulating the Parameter

What to Observe

7. Cookie Manipulation

Manipulating the Parameter

What to Observe

When Parameters Are Encoded or Encrypted

Conclusion