How I Discovered a Business Logic Vulnerability That Bypassed a Paid Subscription

My name is Montaser Mohsen, and I'm a web security researcher with a strong interest in web application security, particularly business logic flaws, authorization issues, and vulnerabilities that can have a real-world business impact.

Recently, while participating in a public Vulnerability Disclosure Program (VDP), I discovered an interesting business logic vulnerability in a SaaS platform that allowed free users to bypass the intended subscription restriction and continue using premium functionality without purchasing a paid plan.

To respect the vendor's responsible disclosure policy, I won't mention the company's name or reveal any identifying information. Instead, I'd like to share how I discovered the issue, why it happened, and what developers can learn from it.

Understanding the Intended Business Logic

The platform offered two subscription tiers:

• Free Plan
• Paid Plan

According to the intended business model, free users were allowed to create a maximum of three models.

Once the third model had been created, any attempt to create a fourth model should require upgrading to a paid subscription, which costs approximately $75 per month.

This is a common monetization model for SaaS applications, and the backend should strictly enforce these limits.

However, while analyzing the application's behavior, I noticed something unusual.

Inspecting the Request

Whenever I encounter a feature restriction implemented through the user interface, I like to inspect the requests exchanged between the browser and the server.

When attempting to create a fourth model, the frontend sent a request similar to the following:

{
  "data": {
    "activatePaidPlan": true
  },
  "method": "POST"
}

{
  "data": {
    "activatePaidPlan": true
  },
  "method": "POST"
}

One parameter immediately caught my attention:

activatePaidPlan

activatePaidPlan

It seemed unusual that the client was sending a value that appeared to determine whether a paid subscription should be activated.

Subscription validation should always be enforced on the server — not delegated to data coming from the client.

That observation was enough to justify further testing.

Testing the Assumption

To verify whether the backend actually trusted this parameter, I intercepted the request using Burp Suite before it reached the server.

I modified a single value.

From:

"activatePaidPlan": true

"activatePaidPlan": true

To:

"activatePaidPlan": false

"activatePaidPlan": false

No other fields were modified.

I then forwarded the request.

To my surprise, the server accepted the request and successfully created a fourth model, even though the account was still using the free plan.

The subscription was not upgraded.

No payment was required.

The premium restriction was bypassed simply by changing a single boolean value.

Why Did This Happen?

The vulnerability existed because the backend appeared to trust a client-controlled parameter while making an authorization and billing decision.

Instead of independently verifying:

• Whether the user had an active paid subscription.
• How many free models had already been created.
• Whether the request should be authorized.

The server relied on information supplied by the client.

This is a classic Business Logic Vulnerability combined with Improper Trust in Client-Side Parameters.

The client should never be responsible for determining whether premium functionality is available.

Security and Business Impact

Although no sensitive user data was exposed, the business impact could be significant.

An attacker could:

• Bypass subscription enforcement.
• Access premium functionality without paying.
• Create unlimited models using a free account.
• Consume platform resources without cost.
• Automate the attack using simple scripts.
• Cause direct financial losses by avoiding subscription fees.

Since exploitation required changing only a single boolean parameter, the attack complexity was extremely low.

No privilege escalation or advanced exploitation techniques were necessary.

Root Cause

The root cause was straightforward.

The backend trusted the following client-controlled parameter:

activatePaidPlan

activatePaidPlan

Instead of retrieving the user's subscription status from trusted backend records, the application allowed the request itself to influence the billing workflow.

Critical authorization and billing decisions should never depend on values supplied by the client.

The server — not the browser — must always be the source of truth.

Recommended Remediation

To prevent similar vulnerabilities, subscription validation should be enforced entirely on the backend.

Recommended improvements include:

• Ignore any subscription-related parameters supplied by the client.
• Retrieve the user's subscription status directly from the database.
• Enforce free-tier quotas on the server.
• Validate the current model count before creating a new one.
• Reject requests that exceed the allowed free limit.
• Require successful payment before enabling premium functionality.
• Log suspicious attempts to bypass subscription restrictions.
• Monitor repeated abuse attempts through auditing and anomaly detection.

Lessons Learned

This vulnerability highlights an important lesson in application security.

Many developers spend considerable time defending against technical vulnerabilities such as SQL Injection, Cross-Site Scripting (XSS), or Remote Code Execution (RCE).

However, business logic vulnerabilities can be just as damaging because they directly affect the application's core business model.

In this case, there was no sophisticated exploit.

The issue existed simply because the backend trusted information provided by the client.

One boolean parameter was enough to bypass an entire subscription workflow.

Responsible Disclosure

This issue was responsibly reported through the platform's Vulnerability Disclosure Program.

Testing was performed exclusively on my own account.

No unauthorized data was accessed, modified, or exposed during the research.

The purpose of this research was solely to help improve the platform's security.

Final Thoughts

One of the biggest lessons I've learned during bug bounty hunting is that impactful vulnerabilities are not always highly technical.

Sometimes, the most valuable findings come from understanding how an application is supposed to work and asking a very simple question:

What happens if the client lies?

If the backend trusts that answer, the consequences can extend far beyond security — they can directly affect revenue, operational costs, and the integrity of an entire subscription system.

For developers, the takeaway is simple:

Never trust the client. Every authorization, billing, subscription, and entitlement decision must be enforced entirely on the server.

Thanks for reading 🙏 I'll keep sharing more from my bug bounty journey.

Feel free to connect or share your thoughts

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