I recently found and reported a real authorization flaw, and it was one of those wins that reminds me why I enjoy security testing.
Key Takeaways
- Authorization must be enforced on every request.
- Request-layer testing catches issues UI testing will miss.
- Ownership checks are the difference between safe and exposed.
What happened, technically
I intercepted a legitimate PUT request that referenced a user ID, modified it, and the server accepted a change it should have rejected. The result was unauthorized account access. The request was authenticated, but the server did not consistently validate that the action was authorized for the specific target.
This is the classic access control gap. Authentication answers who you are. Authorization answers what you are allowed to touch. If those checks are not tightly enforced on every request, the boundary between accounts can be crossed.
Why this was meaningful
The UI was not the problem. Everything looked correct on the front end. The issue lived in server-side logic. A field was trusted without being validated against ownership. That is the exact failure mode that turns a valid request into unauthorized access.
How I got here
I learned this style of testing through hands-on labs on TryHackMe. The training forced me to focus on trust boundaries and request integrity, not just UI behavior. That mindset led me to review the request itself and ask, \"If I change this, does the server still allow it?\"
Why this kind of testing matters
- Server-side enforcement is everything. UI checks do not protect data.
- Authorization must be explicit. Every request needs a verified owner.
- Small gaps have big impact. One missed check can expose accounts.
Outcome
I reported the issue, it was fixed, and it reinforced a simple truth. Security wins often happen in the details of a request and the assumptions behind it. That is why I test at the request layer, not just the UI.