Finding 4 Logic Vulnerabilities in a Single E-Commerce Target

Today, I'm excited to share my discovery of 4 vulnerabilities within a single external Bug Bounty program.

Grab your cup of coffee, sit back, and let's dive right in! ☕👇

Vulnerability #1: Bypassing Phone Registration Limits via Response Manipulation

Another interesting logic issue I encountered was a Client-Side Controls Bypass via response modification.

The Scenario

When a user attempts to associate a phone number that is already linked to another account, the backend correctly identifies the conflict and returns an error. However, the application relies heavily on the client-side code to enforce the UI state transition.

Step-by-Step Exploitation Flow

1. Input Submission: Navigated to the profile edit section and submitted a phone number that was already registered to a different account.
2. Server Rejection: The backend returned an HTTP 400 Bad Request status along with a JSON payload explicitly stating: "This phone number is already registered".
3. Response Interception: Using Burp Suite, I intercepted the incoming response before it reached the browser.
4. Payload Modification:

• Changed the status line from HTTP/2 400 Bad Request to HTTP/2 200 OK.
• Cleared the error JSON object from the response body.

5. Execution: Forwarded the modified response to the client.

The Result

By tricking the front-end into believing the request succeeded, the application bypassed the registration restriction and immediately transitioned the UI to the OTP Verification step.

Vulnerability #2: Full OTP Bypass via Reusable Verification Response (Response Replay)

During my testing of the authentication process, I uncovered a business logic flaw that allows an attacker to bypass OTP verification indefinitely using a single captured success response.

The Core Issue

The server does not validate session-specific or time-bound tokens within the OTP verification response. Instead, it relies on a static response structure to confirm successful authentication. Once a single valid verification response is captured, it can be replayed to bypass OTP verification for any login attempt, completely eliminating the need to access the email.

Step-by-Step Exploitation Flow

1. Initial Capture: Performed one legitimate OTP verification on a test account, intercepted the server's successful verification response, and copied the complete response payload (headers and body).
2. Initiate New Authentication: Triggered a new login attempt
3. Submit Dummy OTP: Entered any random/invalid OTP code (e.g., 0000).

4. Intercept Error Response: Intercepted the resulting error response from the server (e.g., 422 Unprocessable Entity).

5. Replay Success Response: Replaced the error status and body entirely with the previously copied successful response payload.

6. Forward Response: Sent the modified response to the client.

Impact

The application accepted the replayed response, bypassed the OTP check, and granted full access to the account. This effectively allows persistent authentication bypass without ever knowing the actual OTP sent to the target's email

Vulnerability #3: Information Disclosure via Excessive API Data Exposure

While inspecting the network traffic during product browsing, I noticed an Excessive Data Exposure issue in the product details API.

The Scenario

Modern front-end applications often fetch full data objects from the backend and filtering/rendering only specific parts for the end-user. However, returning raw backend data model fields directly to the client can lead to sensitive business logic exposure.

Step-by-Step Discovery

1. Navigated to a standard product page on the platform.
2. Intercepted the background API request fetching product details using Burp Suite.
3. Inspected the raw JSON response returned by the backend.

Exposed Payload

While the web interface only rendered standard product details (title, image, price), the underlying API response contained internal operational parameters:

{ "availableQuantity": 1178, "storeId": "DK02", }

Impact

Although rated as Low severity, exposing internal inventory metrics (availableQuantity) and warehouse/store mappings (storeId) allows competitors or malicious users to map out internal stock levels, monitor sales velocity, and gain insights into backend logistics without proper authorization.

Vulnerability #4: Server-Side Input Validation Bypass via Invisible Unicode Characters

To wrap up the findings, I tested the profile customization logic for improper input handling and found an Input Validation Bypass using invisible Unicode characters.

The Scenario

Web applications often enforce mandatory fields (like a user's firstName) on the front-end to prevent blank or empty profiles. However, if the backend lacks proper normalization and sanitization (such as stripping whitespace and non-printable Unicode characters), users can bypass client-side restrictions.

Step-by-Step Exploitation Flow

1. Initial Input: Navigated to the profile edit section and entered a standard valid name to pass client-side form validation.
2. Request Interception: Intercepted the profile update HTTP request in Burp Suite.
3. Payload Injection: Replaced the value of the firstName parameter with an invisible Unicode character (such as Zero-Width Space U+200B or similar invisible whitespace formatting).
4. Execution: Forwarded the request to the server.

The Result

The server accepted the request with an HTTP 200 OK status, updating the user profile with an effectively blank display name. This confirmed that validation was strictly enforced on the client side without proper server-side sanitization.

Impact

While categorised as Low severity, improper input sanitization can lead to UI rendering issues, user identification confusion, or potential abuse in community/social features where anonymous or unidentifiable accounts are prohibited.

"Feel free to reach out to me on Facebook, LinkedIn or instagram if you'd like to connect or discuss anything."💕

Thanks for reading 🙌 Happy hacking 🐞