I Changed One Parameter… and Broke a B2B Booking System

Introduction

During a recent security assessment of a B2B travel booking platform, I came across something that, at first, looked fairly standard.

A parameter. A request. A small test.

But within a few minutes, that simple test turned into something much bigger.

By changing a few values in requests, I was able to:

• access data that didn't belong to me
• manipulate booking conditions
• and even use another partner's pricing

None of this required advanced exploitation techniques. Just careful observation and an understanding of how the application was supposed to work.

This article walks through the three main issues I identified, starting with the most impactful one.

Broken Access Control — One Parameter to Access Another Partner's Pricing

In any B2B system, tenant isolation is critical. Each partner should only have access to their own data, their own pricing, and their own customers.

Here, that boundary could be bypassed.

While analyzing booking requests, I noticed a parameter defining the partner context:

partnerId=XXXX

partnerId=XXXX

I replaced it with another value.

The request still returned a valid response.

No validation. No restriction.

From there, it became possible to:

• access pricing from another partner
• perform bookings using those prices
• effectively bypass the platform's pricing model

Why this matters

This is not just a technical issue.

This is a breakdown of how the platform is supposed to operate.

Pricing in a B2B system is not public. It is negotiated, controlled, and specific to each partner. Allowing cross-partner access undermines the entire model.

Root cause

The backend relies on a client-controlled parameter (partnerId) without validating it against the authenticated session.

Impact

• Unauthorized access to sensitive pricing data
• Financial loss through pricing abuse
• Risk of large-scale exploitation
• Loss of trust between partners

Diagram — Tenant Isolation Breakdown

Business Logic Flaw — Bypassing Capacity and Pricing Controls

After identifying access control issues, I moved to the booking workflow, focusing on transfer reservations.

One parameter stood out:

adults=1

adults=1

I increased it.

adults=8
adults=20

adults=8
adults=20

The system continued to accept the request without any adjustment.

The selected vehicle remained the same. The price remained unchanged.

What this reveals

The application does not enforce consistency between:

• number of passengers
• vehicle capacity
• pricing logic

This creates a gap between what the system allows and what should realistically be possible.

Impact

• Revenue loss due to incorrect pricing
• Operational issues (vehicle mismatch)
• Easy exploitation with minimal effort

Diagram — Pricing and Capacity Bypass

Broken Access Control (IDOR) — Accessing Other Users' Bookings

During further testing, I identified another issue affecting booking endpoints.

By modifying a booking identifier, it was possible to access other users' reservations.

The application returned the data without verifying ownership.

Why this still matters

Even though IDOR is a well-known issue, its impact here is not negligible.

Booking data often contains:

• personal information
• travel details
• contextual data that can be reused in attacks

Root cause

The backend does not verify whether the requested resource belongs to the authenticated user.

Diagram — Unauthorized Data Access

Putting it all together

Individually, each issue is problematic.

Combined, they create a much more serious scenario.

An attacker can:

• access sensitive data
• manipulate booking parameters
• leverage pricing from other partners

At that point, the application is no longer just vulnerable. It becomes exploitable in a way that directly affects the business.

What this case highlights

This assessment reinforces a few important points:

• Access control must be enforced consistently, not assumed
• Business logic should never rely on client input
• Multi-tenant systems require strict isolation by design

Most importantly, many high-impact issues are not the result of complex exploits, but of small assumptions that were never properly validated.

Conclusion

What I found here was not the result of automated scanning or advanced tooling.

It came from:

• understanding how the system works
• questioning what should and should not be possible
• and testing those assumptions step by step

This is often where the most impactful vulnerabilities are found.

If you are building or assessing B2B platforms, marketplaces, or booking systems, it is worth looking beyond technical controls and focusing on how the business logic is enforced.

Because that is where small gaps can turn into real-world impact.