July 11, 2026

From Hidden API to Paywall Bypass: Finding an Authorization Vulnerability in an Online Learning…

Everyone remembers their first accepted vulnerability report.

By BnSec

2 min read

Mine wasn't the most technically complex bug, but it reinforced one of the most important lessons in web application security:

Never trust the frontend to enforce authorization.

In this write-up, I'll walk through how a hidden API endpoint led to the discovery of a Broken Access Control vulnerability that allowed authenticated users to access premium course content without purchasing it.

The Target

While testing an online learning platform, I started with the usual reconnaissance:

  • Browsing the application
  • Inspecting JavaScript files
  • Exploring API endpoints
  • Looking for hidden functionality

One endpoint immediately caught my attention.

GET /api/products_all

The endpoint name suggested it might return every product available on the platform.

Reconnaissance

Request:

GET /api/products_all HTTP/2
Host: example.com

The response contained a list of products, including:

  • Free courses
  • Premium courses
  • Products not visible anywhere in the user interface

Among the returned fields was a unique identifier:

productTitleId

This identifier appeared to represent the internal course ID.

At this stage, nothing sensitive had been accessed yet, but the endpoint exposed valuable information that could be used for further testing.

Looking at the Course Player

When opening a normal course, the application used URLs similar to:

/path-player?courseid=<courseID>&unit=<unitID>

Immediately, a question came to mind:

What happens if I replace the course ID with another one?

This is a common authorization test whenever identifiers appear directly in URLs.

Testing Authorization

Using one of the premium course IDs obtained from the API, I modified the request.

Original:

/path-player?courseid=FREE_COURSE_ID&unit=UNIT_ID

Modified:

/path-player?courseid=PAID_COURSE_ID&unit=UNIT_ID

I expected one of several outcomes:

  • Access denied
  • Redirect to purchase page
  • HTTP 403 Forbidden
  • Error indicating missing entitlement

Instead…

The premium course loaded successfully.

No purchase verification.

No entitlement validation.

No authorization check.

Simply changing a parameter granted access to premium educational content.

Root Cause

The application appeared to trust the client-supplied courseid parameter without verifying whether the authenticated user actually owned the requested course.

In other words:

  1. The client requested a course.
  2. The server accepted the identifier.
  3. The server returned premium content.

The missing step was:

Verify that the authenticated user is entitled to access this course.

This is a classic example of Broken Access Control.

Why This Matters

Although the vulnerability required authentication, every authenticated user could potentially access premium content they had never purchased.

Possible impacts included:

  • Paywall bypass
  • Unauthorized access to premium educational material
  • Financial loss
  • Automated scraping of paid content
  • Unauthorized redistribution of premium videos

Authorization failures consistently rank among the most critical web application vulnerabilities because they directly expose protected resources.

How It Could Be Fixed

Several server-side protections would prevent this issue:

  • Validate user entitlement before serving course content.
  • Never rely on client-controlled identifiers for authorization.
  • Return HTTP 403 when the user lacks permission.
  • Avoid exposing unnecessary internal product information through public APIs.
  • Apply authorization checks consistently across all content endpoints.

Lessons Learned

This finding reinforced several important lessons for me.

1. Hidden APIs deserve attention

Endpoints that aren't linked in the UI often expose useful functionality or metadata.

2. Enumeration can lead to impact

An informational endpoint may seem harmless on its own, but combined with another weakness it can become a critical vulnerability.

3. Always test server-side authorization

Whenever you encounter identifiers like:

  • courseid
  • userId
  • accountId
  • projectId
  • documentId

ask yourself:

"What happens if I replace this with another valid identifier?"

That simple question often leads to authorization vulnerabilities.

Responsible Disclosure

The issue was responsibly disclosed through the vendor's vulnerability disclosure process. Details that could enable exploitation have been omitted or generalized until the issue was resolved.

Final Thoughts

One of the biggest misconceptions in bug bounty is that impactful findings always require advanced exploitation techniques.

In reality, many high-impact vulnerabilities come from understanding how applications are supposed to enforce authorization — and then verifying whether they actually do.

Sometimes, changing a single parameter is all it takes to uncover a serious security flaw.

Thanks for reading, and happy hacking!