Table of Contents

• Introduction
• Approaching the target
• OAuth2 Credentials Discovery
• Exploiting OAuth2 Client Credentials
• Increasing Finding’s Impact
• Conclusion

Introduction

During a YesWeHack bug bounty engagement, I discovered exposed OAuth credentials that provided unrestricted access to sensitive user data. This post details how a seemingly simple misconfiguration escalated into a critical vulnerability, and highlights essential lessons for anyone involved in web security—especially those active in the bug bounty field.

Approaching the target

The methodology used to approach a new web application target in a bug bounty context is important because it often determines whether a bug hunter persists with the target or moves on due to a perceived lack of findings.

One of my favorite approaches is to start discovering the web application while unauthenticated (even when the program provides credentials for testing purposes) and try to achieve significant impact from this position. This requires no complex tooling beyond a web browser and a proxy like Burp Suite or Caido.

I then begin interacting with the web application by manually clicking links and submitting forms while proxying the traffic. Though seemingly simple, this classic step is crucial for familiarizing oneself with the web application. During this phase, I’ve observed that a common error is scoping traffic solely to the target domain. Passive analysis is critical, and overly narrow scoping can mask sensitive information, especially when third-party services are involved. Examples include:

• Classic Distributed Architectures: Frontends in scope often call backend services on out-of-scope domains.
• No-Code/Low-Code Platforms: User-facing apps run on the target domain, while APIs live on *.nocodeplatform.com, which can be overlooked.
• Headless CMS: Presentation layers serve from one domain, while content APIs live elsewhere, which you must monitor.

After unauthenticated exploration, I carefully review the proxy’s HTTP history for key interactions—filtering out noise such as analytics. Notable sources include:

• JavaScript Files: Analyzing JavaScript, regardless of the framework (React, Vue, etc.), often reveals sensitive information, API endpoints, or developer comments that offer valuable insights into the application’s intended behavior.
• XHR and Fetch Requests: These asynchronous requests are the lifeblood of modern web apps, handling data exchange between the client and server. Intercepting and analyzing them helps identify API endpoints, understand data structures, examine authentication mechanisms, and potentially uncover vulnerabilities like Insecure Direct Object References (IDORs), excessive data exposure, or flawed access controls.

Furthermore, experienced bug hunters should look for subtle indicators within the traffic. Unusually large or high-latency HTTP responses, for example, can suggest complex backend workflows that may warrant deeper investigation.

OAuth2 Credentials Discovery

During the engagement, I spotted an XHR request to the following endpoint:

https://TARGET/api/v1/configuration

This endpoint returned global configuration settings, including sensitive OAuth2 credentials:

{"configuration":{"clientId":"TARGET_CLIENT_ID","clientSecret":"TARGET_CLIENT_SECRET"}}

OAuth2 is a robust authorization framework, but its implementation complexity makes it prone to misconfiguration. Broadly, OAuth2 workflows involving client applications fall into two categories:

• Client Credentials Grant (Server-to-Server): Used when an application needs to access resources under its own control (not on behalf of a user). The application authenticates directly with the authorization server using its clientId and clientSecret (or other methods) to obtain an access token.
• User-Delegated Workflows (e.g., Authorization Code Grant): Used when an application needs to access resources on behalf of a user. These flows involve redirecting the user to the authorization server to grant permission, after which the application receives an authorization code or token to act on the user’s behalf.

Given this discovery, the exposed OAuth2 credentials likely belong to a Client Credentials workflow. The next step is to leverage them, which typically involves:

1. Retrieving an Access Token: First, we must identify the authorization server’s token endpoint. This might require further reconnaissance (e.g., examining documentation, other API calls, or JavaScript files). Once found, we can use the clientId and clientSecret (usually via a POST request to the token endpoint with grant_type=client_credentials) to obtain an access token.
2. Performing Authenticated API Calls: With the access token acquired, we need to identify the protected API endpoints we want to interact with. The token is typically sent in the Authorization header of requests to these endpoints, using the Bearer scheme (e.g., Authorization: Bearer <access_token>).

Exploiting OAuth2 Client Credentials

I identified the authorization server’s token endpoint at /auth/oauth2.0/v1/access_token and constructed this request:

POST /auth/oauth2.0/v1/access_token HTTP/2
Host: TARGET
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=TARGET_CLIENT_ID&client_secret=TARGET_CLIENT_SECRET

The authorization server returned a JSON payload:

{
  "access_token": "TARGET_ACCESS_TOKEN",  // use for subsequent API calls
  "id_token": "TARGET_ID_TOKEN",          // JWT with user identity claims
  "token_type": "Bearer",
  "expires_in": 3599,
  "scope": "mail openid profile uid"
}

We successfully achieved the first step. Now, still by observing the traffic gathered from the initial discovery, I constructed an authenticated API request. Typically, the acquired access token is sent in the Authorization header using the Bearer scheme. The specific request looked like this:

GET /v1/SENSITIVE_ENDPOINT?id=xxxxxx HTTP/1.1
Host: TARGET_API
Api-Key: STATIC_API_KEY
Authorization: Bearer TARGET_ACCESS_TOKEN
Accept: application/json

This request included both the required static Api-Key header and the bearer token in Authorization. The API responded with personally identifiable information (PII) such as name, email, phone number and other target organization’s business sensitive data.

Increasing Finding’s Impact

Every bug hunter’s goal is to achieve the highest possible impact, first, because it’s challenging, and second, to demonstrate the criticality of the vulnerability. Unless the program rules restrict interactions, it is a good reflex to go further and perform additional non-destructive tests. In this case, I determined that no rate limiting was applied to the API endpoints. This allowed brute-forcing the simple numeric id values used as GET parameters on various sensitive endpoints, leading to massive PII leaks including names, emails, addresses, and target organization-specific business information.

The API also exposed endpoints through other HTTP methods like PUT or DELETE. However, I always refrain from performing potentially destructive tests (such as modifying or deleting real data) on live/production web applications. Instead, I document these findings for the target organization’s security team to review. If the security team approves and requests further tests, ensure to create dummy records that do not impact application behavior, and avoid using content that could trigger alerts or appear suspicious to real application users (e.g., “hacking” keywords or alert popups). When in doubt, communicate with the program owner to clarify the scope of allowed testing.

Conclusion

This case study shows how minimal information disclosure can escalate into critical vulnerabilities. Effective bug hunting demands a solid grasp of web application architectures and their specific implementations. While many newcomers chase “magical” tools, success hinges on dedication, methodical analysis, and attention to often overlooked details.

Here are three actionable takeaways:

• Spend time understanding the web application: For narrow-scoped programs, take the necessary time to understand the web application. Read any available documentation, and observe how the application actually behaves.
• Do not make assumptions: Depending on the context, seemingly exposed credentials might be intentional and have highly restricted scopes. Always verify if discovered OAuth2 credentials can retrieve a valid access token AND determine the permissions attached to that token.
• Tools don’t guarantee success: While the bug hunting community offers many helpful tools, relying solely on them is a common beginner mistake. Simply running popular tools without proper understanding typically leads to false positives or duplicate reports in the competitive bug hunting environment. Tools are valuable when used strategically and contextually and customizing or developing your own tools to fit specific needs can be particularly effective and rewarding.
• Adopt the Security Team’s Perspective: When reporting vulnerabilities, view them through the lens of the security team responsible for triage and remediation. Provide clear context regarding the impact, precise steps for reproduction, and practical guidance on mitigation. This approach facilitates efficient processing. Before submitting, critically assess your report: Does it clearly convey significance, or might it leave the reader wondering, “So what?” Ensure your report presents valuable, actionable information.

Happy Hunting!