DEV Community: SAMYUKTHA SARAVANAN

Learning OWASP A01 and A02: Broken Access Control and Security Misconfiguration

SAMYUKTHA SARAVANAN — Wed, 26 Aug 2026 13:06:13 +0000

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.

From a Static Marketing Site to a Live Production API: A Web Application Security Walkthrough

SAMYUKTHA SARAVANAN — Tue, 25 Aug 2026 13:26:12 +0000

By Samyuktha S

Introduction

Not every security assessment ends with a critical vulnerability — and that's fine. Real-world testing involves mapping, dead ends, false positives, and genuine findings.

This post covers an authorized assessment of a healthcare recruitment/networking platform [TARGET]. The assessment started with a static front-end, then moved to the real production application discovered through subdomain enumeration, resulting in two findings worth reporting.

The key lesson is simple: verify before claiming. Some things initially looked vulnerable but were ruled out after testing.

Scope: TARGET and associated subdomains. No destructive testing, brute-forcing, or data modification was performed.

Phase 1: Mapping the Surface
The assessment began with the primary domain, which contained a homepage, login, registration, job portal, and contact form.

Basic reconnaissance — including viewing page source, inspecting network requests, and reviewing JavaScript — showed that these features had no real backend.

The login button performed a client-side redirect without submitting credentials or sending a request. The dashboard displayed the same hardcoded content regardless of authentication state. Registration, contact, and job-related forms followed a similar pattern.

This was not treated as an authentication bypass because there was no real data or backend logic behind these pages. However, it was worth noting as a design issue that could become risky if a real backend is later connected.

Phase 2: Finding the Real Application
The next step was passive subdomain enumeration using publicly available information, including Certificate Transparency logs and passive DNS sources.

This revealed an API host and a corresponding application host.

Unlike the primary domain, these were active production systems. The application was a real single-page application backed by an Express.js API with OTP authentication, role-based data, and a REST API.

This became the focus of the assessment.

Phase 3: Testing and Ruling Things Out
CORS Headers — Investigated, Not Exploitable
The API returned:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

This looked concerning because it appeared to allow any origin to make credentialed requests.

However, testing showed that the server returned a static * rather than reflecting arbitrary origins.

Browsers do not allow credentialed CORS requests with a wildcard origin, so no working exploit could be demonstrated.

Conclusion: A configuration issue worth cleaning up, but not a confirmed vulnerability.

A suspicious configuration should always be tested before being reported as exploitable.

Phase 4: Two Findings That Held Up
Finding 1 — Authentication Token Stored in Browser localStorage
The application's JavaScript showed that authentication tokens and user-related information were stored in localStorage:

localStorage.setItem("userToken", [TOKEN]);
localStorage.setItem("userId", [USER_ID]);
localStorage.setItem("roleId", [ROLE_ID]);

Unlike HttpOnly cookies, localStorage can be accessed by JavaScript running on the same origin.

This means a future XSS vulnerability could potentially expose authentication tokens and user information. No XSS vulnerability was claimed during this assessment, but this design increases the impact of any future XSS issue.

Severity: Low–Medium

Remediation: Consider storing authentication tokens in HttpOnly, Secure, and appropriately configured SameSite cookies, with CSRF protections where necessary.

Finding 2 — Possible User Enumeration via Password Reset Endpoint
The password-reset endpoint returned a distinct response for a non-existent account:

POST /api/user/forgot-password/send-otp
{
"email": "[NONEXISTENT_TEST_EMAIL]"
}
Response:
{
"message": "User not found"
}

This could allow attackers to determine whether an email address is registered if valid accounts receive a different response.

Important limitation: I did not test a real user's email address for comparison because that was outside the authorized scope. Therefore, this is reported as a probable user enumeration issue rather than a fully confirmed vulnerability.

The platform owner can confirm this internally using an authorized test account.

Severity: Low–Medium

Remediation: Return the same generic response for both existing and non-existing accounts, for example:

If an account is associated with this email address, an OTP has been sent.

Response timing should also be kept as consistent as practical to reduce timing-based enumeration.

Conclusion
This assessment reinforced the importance of not overstating findings.

The accessible dashboard and CORS configuration initially looked concerning but did not result in a confirmed exploit. The token storage design and probable password-reset enumeration issue, however, were worth reporting.

Good security testing is not about finding the most dramatic vulnerability. It's about verifying what is actually exploitable and being honest about what cannot be confirmed.

Responsible Disclosure
The findings were reported to the platform owner before publication. Sensitive, proprietary, and identifying details have been omitted from this post.

Have questions about this methodology or want to discuss the findings? Feel free to reach out.