Don’t Trust the Response: How Client-Side Assumptions Broke Core Business Logic

December 24, 2025 • 7 min read

A deep dive into response manipulation vulnerabilities and how trusting client-side flags led to verification bypass and subscription abuse through broken business logic.

Disclaimer

This article is published strictly for educational and defensive security purposes.
All techniques discussed here must only be tested on applications you own or are explicitly authorized to assess (for example, under a bug bounty program).
The goal of this write-up is to help developers, security engineers, and researchers understand why trusting client-side responses is dangerous, and how to design systems that cannot be bypassed through simple manipulation.

Introduction

When people think about serious web vulnerabilities, their minds usually jump to things like SQL injection, remote code execution, or deserialization bugs. But in real-world applications-especially SaaS platforms-some of the most damaging flaws are not technical exploits at all.

They are business logic failures.

This write-up walks through a real-world case where an application trusted response values sent to the client to enforce critical controls like:

Email and phone verification
Subscription and plan restrictions

By intercepting and modifying server responses in transit, it was possible to bypass verification checks and even defeat the entire subscription enforcement model-without exploiting the backend directly.

This is a story about why the server must never trust what the client believes to be true.

What Is Response Manipulation?

Response manipulation is a class of attack where an attacker:

Intercepts a server response (HTML or JSON).
Modifies values inside that response.
Forwards the altered response to the browser.
Lets the client-side application behave as if the server approved an action.

This is typically done using tools like Burp Suite, which allow attackers to intercept, edit, and forward traffic between the browser and the server.

The critical condition for exploitation is simple:

The application relies on client-side values (flags, booleans, counters, or messages) to enforce security or business rules.

If that condition exists, response manipulation becomes not just possible-but trivial.

A technical diagram illustrating the HTTP request and response flow being intercepted and viewed through Burp Suite proxy between the client browser and the web server.

Target Application Overview

The affected application was a SaaS platform that allows users to:

Build websites using a drag-and-drop editor
Manage projects from a central dashboard
Publish sites and manage subscriptions

Key characteristics of the system:

New users receive a 14-day free trial with full Business Plan features
After the trial ends, the account downgrades to a Free Plan
Some features require email and phone verification
Subscription limits are enforced via UI gating and API responses

At first glance, everything looked normal. Verification gates existed. Subscription limits were clearly defined.

The problem was not what the server said.

The problem was what the server trusted.

Bug #1: Verification Bypass via Response Manipulation

The Intended Flow

Screenshot of a JSON API response showing critical status flags like 'userverified' and 'userphone' set to true.

Certain features were restricted unless the user had:

Verified their email address
Verified their phone number

From the UI perspective, attempting to access those features showed a warning message:

“Access to this function is restricted. Please verify your email address.”

So far, so good.

Observing the Traffic

While browsing the application with Burp Suite running, one request stood out:

POST /projects/get/getheadcode/
{
  "project_id": "12345"
}

The response was a JSON object that included verification-related fields:

{
  "userverified": "",
  "userphone": "",
  "data": { ... }
}

When a fully verified account made the same request, the values changed:

{
  "userverified": "y",
  "userphone": "y",
  "data": { ... }
}

At this point, an important question emerged:

What if the application is trusting these values on the client side?

The Exploit

Using Burp’s Match and Replace feature, two simple rules were added:

Replace "userverified":"" with "userverified":"y"
Replace "userphone":"" with "userphone":"y"

No requests were altered. No backend logic was touched. Only the response was changed.

After forwarding the modified response, the browser behaved as if the account was fully verified.

Restricted features unlocked
No email verification required
No phone verification required

From the server’s perspective, nothing had changed.

From the client’s perspective, everything had.

Root Cause

The frontend trusted verification flags returned in the response to determine access.

There was no secondary server-side check enforcing verification status when sensitive actions were performed.

Bug #2: Subscription Downgrade and Plan Enforcement Bypass

The first issue was serious, but what came next exposed a much deeper architectural flaw.

Subscription Logic Overview

Business Plan users can create multiple websites
Free Plan users are limited to one website
At the end of the trial, users must downgrade or renew

The downgrade flow included a safeguard:

If the user had more than one website, the downgrade would fail with an error message telling them to delete extra projects.

The Blocked Downgrade

When attempting to downgrade after the trial expired, the application displayed:

“You must manage your plan first.”

Clicking Don’t Renew triggered a backend request that returned:

{
  "projects_cnt": 2,
  "success": false,
  "error_message": "There are [2] websites in your account. The Free plan allows only one website per account.",
  "error_code": "popup_go_free_too_many_projects"
}

The UI correctly blocked the downgrade.

The Manipulation

The response was intercepted and modified before reaching the browser:

{
  "projects_cnt": 2,
  "success": true
}

That was it.

No project deletion. No server-side enforcement. No recalculation.

After forwarding the modified response, the UI proceeded as if the downgrade had succeeded.

The Result

The account was downgraded to Free Plan
All projects remained accessible
Business Plan features continued to work
Subscription limits were completely bypassed

The entire billing and plan enforcement system was effectively client-controlled.

Why This Happened: Root Cause Analysis

Both vulnerabilities stem from the same fundamental mistake:

The application trusted client-visible state to enforce server-side rules.

Specifically:

Verification checks were enforced in JavaScript, not on the server
Subscription eligibility was decided by a boolean in a response
No backend validation re-confirmed eligibility during critical actions

Once the response reached the browser, the system assumed it was authoritative.

That assumption was wrong.

Impact Assessment

User interface screenshot showing premium or restricted features becoming accessible on the web application after successfully bypassing the verification logic.