Business Logic Bypass: The Export Limit Bypass

Business logic vulnerabilities don't always involve complex exploits. Sometimes, all it takes is changing a single value that an application assumes users will never tamper with.

While performing a security assessment on a healthcare platform, I noticed an interesting business rule around exporting prescription records. The application claimed that a standard user could export no more than 300 records at a time. Exporting larger datasets required elevated privileges or a higher-tier subscription. Naturally, I wanted to verify whether this restriction was actually enforced by the server.

Test

Using Burp Suite, I analyzed the application's export flow.

Before initiating the export, the application received a response from the server that contained the maximum number of records the user was allowed to export.

The response resembled the following:

HTTP/1.1 200 OK
Content-Type: application/json
{
  "Limit": 300
}

HTTP/1.1 200 OK
Content-Type: application/json
{
  "Limit": 300
}

Instead of leaving the response untouched, I intercepted it and modified the value:

{
  "Limit": 10000
}

{
  "Limit": 10000
}

The modified response was forwarded to the browser. The client then used the manipulated value when initiating the export request. Rather than validating the requested limit on the server, the application processed the request successfully and generated an export containing thousands of healthcare records.

At first glance, this may seem like a simple export limit bypass. In reality, the security implications are much broader.

Impact

This is where the finding goes from "interesting" to serious. A few things made this especially concerning:

• Bulk exposure of sensitive healthcare data. By bypassing the export limit, a standard user could extract significantly more prescription records than intended. Depending on the application's deployment and regulatory environment, such records may constitute protected health information (PHI) or other sensitive healthcare data, increasing the impact of a compromised account.
• Business rule bypass. The 300-record limit was intended to restrict how much data a standard user could export. Because the server trusted a client-controlled value instead of enforcing the limit itself, the restriction could be easily bypassed.

Root Cause

The server relied on a client-controlled value to enforce a security-sensitive business rule.

Any value that determines permissions, quotas, limits, or entitlements should always be validated on the server, regardless of what the client sends.

A client should never be responsible for deciding how much data it is allowed to access.

Remediation

• Enforce export limits entirely on the server.
• Determine the maximum export size based on the authenticated user's permissions or subscription level.
• Ignore or reject client-supplied values that exceed the server-defined limit.

Takeaway

This bug didn't require chaining exploits or bypassing authentication.

The application appeared to enforce a 300-record export limit.In reality, it only enforced it until someone changed a single value.

Business logic vulnerabilities often aren't about breaking the application — they're about proving that the application's assumptions can be broken.

The lesson is simple: never trust the client to enforce business rules.