Practice Log 05: Inspecting the Full Response
I completed PortSwigger’s “User ID Controlled By Request Parameter” lab on October 28 as part of my PWPA preparation.
This exercise focused on horizontal access control: keeping one user’s account data separate from another’s.
Two users can have the same role and still need access to different resources.
I used Burp Suite to inspect the account flow and compare requests and responses.
At one point, I wrote “It appears not” in my notes before I had fully inspected the response.
On a second review of the successful Repeater response, I found another user’s sensitive account data.
My earlier conclusion had been premature.
The lesson was to inspect the response body carefully before deciding whether a test had succeeded or failed.
The demonstrated impact was unauthorized disclosure across accounts.
Claims of account takeover or administrative access would require additional evidence.
My proposed remediation is to derive the signed-in identity from a trusted session and enforce authorization for the specific account being requested.
A self-account endpoint can retrieve the account directly from that identity.
Where an account reference is accepted, the server must check ownership or another explicit permission on every request and deny access otherwise.
For regression testing, I would check that:
- A signed-in user can still access their own account.
- A request for another user’s private account is denied.
- Denied responses contain none of the other user’s sensitive data, including in any redirect response body.
- An unauthenticated request cannot retrieve private account data.
This lab also reinforced a documentation habit: keep the observation separate from the assumption.
If you’re practicing this exercise, use PortSwigger’s authorized training environment and stay within its scope.
Building a SaaS? Explore my independent security reviews