When I start testing an application, I don't immediately look for complex exploits.
I click everything.
Every button. Every tab. Every dropdown. Every hidden feature.
Because sometimes, the biggest vulnerabilities hide behind the most ordinary functionality.
Initial Recon
While exploring a web application, I mapped its basic functionality and monitored traffic using the browser's Network tab.
Most API calls looked standard:
- Authenticated requests
- Session cookies
- Expected JSON responses
Nothing unusual.
Until I noticed this endpoint:
GET /api/members?clubId=<id>At first glance, it appeared to be a normal data retrieval endpoint used by the frontend to display club member information.
But something stood out.
There was no Authorization header.
No access token.
No session validation visible in the request.
Just a query parameter: clubId.
That raised a simple but important question:
Is authentication actually enforced server-side?
Testing the Assumption
To validate this:
- I logged out of the application.
- Cleared all cookies.
- Removed session storage.
- Replayed the request manually.
The server responded:
200 OKAnd returned full member data.
What the API Exposed
The response was not limited or sanitized.
It included:
- Full names
- Email addresses
- Phone numbers
- Student IDs
- Department information
- Membership status
- Join metadata
All accessible without authentication.
This was no longer a misconfiguration.
It was a broken access control issue.
Technical Root Cause
The vulnerability consisted of two major issues:
1. Missing Authentication Enforcement
The endpoint did not require any form of authentication middleware.
2. Direct Object Reference Without Authorization
The backend accepted the clubId parameter without validating whether:
- The requester was authenticated
- The requester was authorized to view that club's data
- The requester belonged to the referenced club
This resulted in an Insecure Direct Object Reference (IDOR) combined with missing access control.
The backend implicitly trusted the client.
Scalability of the Issue
The clubId parameter followed a predictable numeric pattern.
Since:
- There was no authentication requirement
- No ownership validation
- No rate limiting observed
An attacker could:
- Enumerate club IDs
- Harvest structured JSON responses
- Aggregate complete datasets of member records
No brute force required. No exploitation tricks. Just direct requests.
That's what makes broken access control dangerous.
It doesn't crash systems.
It quietly leaks them.
Impact Assessment
This vulnerability exposed Personally Identifiable Information (PII), which could enable:
- Targeted phishing campaigns
- Social engineering attacks
- Identity misuse
- Regulatory compliance violations
Depending on scale, the impact could extend to thousands of individuals.
Responsible Disclosure
To validate the issue, I accessed only minimal data necessary to confirm impact.
No automation was used. No mass extraction was performed.
I reported the issue responsibly with a clear proof-of-concept and reproduction steps.
The goal is always remediation — never exploitation.
Key Takeaways for Security Testing
When assessing APIs:
- Monitor every request in the Network tab
- Test endpoints without authentication
- Modify object identifiers
- Validate server-side enforcement
- Never assume the backend checks access
The most dangerous vulnerabilities are not always complex.
They're often the result of a single missing validation.
And sometimes…
The difference between secure and exposed is just one unchecked request.
Until next time — Stay curious. Hack ethically.
Cyber Tamarin out. 🍌