Practice Log 04: Profile Editing and Permissions

I completed PortSwigger’s "User Role Can Be Modified In User Profile" lab today as part of my PWPA preparation.

The lab felt familiar.

I’m documenting the practice and reviewing what my evidence supports.

The focus was the boundary between editing your own profile and changing your permissions.

An ordinary user may be allowed to update certain profile fields.

Permission changes need separate authorization because administrative access can expose sensitive data and operations.

I used Burp Suite to inspect requests and responses while navigating the application and updating my profile.

My initial attempts revealed no admin panel or additional clues.

I continued by examining the normal profile-editing flow.

The evidence showed that an ordinary account could gain administrative capability and perform a restricted action against another lab account.

The important result was the unauthorized action, beyond the appearance of an admin link.

My proposed remediation is to allow only explicitly permitted fields in ordinary profile updates.

The server should enforce authorization separately for permission changes and for each administrative action.

For regression testing, I would check that:

A legitimate profile edit succeeds without changing privileges.
An ordinary user’s attempt to modify a privileged property leaves their stored role unchanged.
An unauthorized administrative request is denied, and the target account remains unchanged.
Authorized administrative use still works.

The response status and interface are only part of the evidence.

Where test access permits, I would also check persisted state, including the database, to verify that a prohibited change did not occur.

These are proposed checks; I did not implement a fix or inspect the lab’s database.

If you’re practicing this exercise, use the authorized training environment and stay within its scope.