By Samyuktha
Introduction
Not every learning exercise ends with a dramatic finding, and that's a fine outcome. This post walks through two OWASP Top 10 (2025) categories I studied hands-on via TryHackMe — A01: Broken Access Control and A02: Security Misconfiguration — and how I applied that thinking to a real, authorized production web application afterward.
The result on the real target wasn't a vulnerability. It was a clean pass. That turned out to be its own useful lesson about what a methodical assessment actually looks like.
Scope: This post covers concepts from two TryHackMe rooms plus a brief, authorized look at a production login/dashboard flow. No destructive testing, brute-forcing, or data modification was performed, and identifying details about the target have been omitted.
Phase 1: A01 — Broken Access Control
Broken access control is consistently ranked the top web application risk, and going through the room made clear why: it's less about clever exploitation and more about the server trusting things it shouldn't.
A few concepts stood out:
IDOR (Insecure Direct Object Reference) — when an app exposes an internal identifier (like a numeric user or order ID in a URL or request body) and doesn't verify the requester actually owns that resource. Swap the ID, and you may be looking at someone else's data.
Missing function-level access control — a feature like an admin panel might be hidden from the UI for regular users, but if the endpoint itself doesn't check role server-side, it's still reachable by anyone who finds or guesses the URL.
Privilege escalation via parameter tampering — modifying a role or permission value in a request (for example, a role field) to see if the server blindly trusts what the client sends.
Forced browsing — manually requesting pages that aren't linked in the UI but still exist and respond on the server.
The recurring theme: hiding something in the UI is a design choice, not a security control. Every sensitive action needs to be re-checked server-side, every time.
Phase 2: A02 — Security Misconfiguration
This category is less about flawed logic and more about the gap between "the app works" and "the app was actually hardened" — defaults, leftovers, and things nobody circled back to clean up:
- Default or sample credentials still active
- Verbose error messages leaking stack traces, file paths, or framework versions
- Directory listing left enabled
- Missing security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security)
- Outdated software with known CVEs still running in production
- Unnecessary services or ports left exposed
What stood out here is how mundane most of these issues actually are. They're rarely clever — they're just things nobody revisited before shipping. Which also makes them some of the easiest wins in a real assessment, when they exist.
Phase 3: Applying It to a Real Target
With those two categories fresh, I got the chance to apply the same checklist to a live production web application I was authorized to test, using Burp Suite to intercept and review the login and post-login dashboard flow.
I went through the A01 checklist specifically:
- Tested for IDOR by swapping identifiers in requests made with my own low-privilege account
- Checked whether role-restricted functionality was reachable directly, bypassing the UI
- Compared what the UI exposed against what the server actually permitted
- Spot-checked response headers and error handling for A02-style misconfiguration signs
Result: nothing exploitable turned up. No accessible IDOR, no reachable hidden admin functionality, no glaring header or error-handling issue in what I checked.
A clean result isn't a failed assessment — it's evidence the access control model held up under a defined set of tests, plus a documented baseline for the next round.
Conclusion
This exercise reinforced something the labs don't always emphasize as strongly as real targets do: a negative result is still a result. It's tempting, especially early on, to feel like an assessment only "counts" if it turns up a finding. But ruling things out methodically — and being honest that nothing jumped out — is exactly what a real assessment looks like most of the time.
Good security testing isn't about finding the most dramatic bug. It's about applying the checklist consistently and being straightforward about what did and didn't hold up.
Next, I'm planning to work through A03: Injection and start keeping more structured notes so these write-ups build into an actual testing checklist over time.
Responsible Disclosure
Any production testing referenced here was performed under authorized scope as part of a formal assessment, and identifying details about the target have been omitted from this post.
