When API Trust Goes Wrong: Findings From an E-Commerce Security Assessment

Sometimes, the most interesting findings appear when an application trusts information supplied by the client without properly validating it on the server.

During an authorized security assessment of an e-commerce platform, I examined the application's cart, checkout, pricing, payment, and session-handling workflows.

Several issues stood out.

1. Cart Authorization Bypass

The cart functionality relied on a client-supplied cart identifier without adequately verifying that the authenticated user actually owned that cart.

This created an authorization flaw where cart operations could be performed against another user's cart.

The important distinction is:

_Authentication answers "Who are you?" Authorization answers _"What are you allowed to access?"

A valid authentication token should never automatically grant access to another user's resources.

2. Checkout Authorization Weakness

The checkout process did not sufficiently verify that the requested course was actually associated with the user's intended purchase flow.

By supplying course identifiers directly to the purchase endpoint, it was possible to create an order without relying entirely on the expected cart workflow.

A secure checkout should independently verify:

User
 ↓
Cart ownership
 ↓
Course ownership/availability
 ↓
Price
 ↓
Order

User
 ↓
Cart ownership
 ↓
Course ownership/availability
 ↓
Price
 ↓
Order

Each step should be validated server-side.

3. Client-Controlled Pricing

Another significant issue involved the way pricing was calculated.

The checkout process relied on client-supplied course information without sufficiently ensuring that the final price was derived from trusted server-side values.

This creates a fundamental risk:

Client → Course selection
          ↓
Server → Trusted database price
          ↓
Server → Calculate final amount

Client → Course selection
          ↓
Server → Trusted database price
          ↓
Server → Calculate final amount

The server, rather than the client, should always be the authority for prices.

4. Sensitive Payment Information Exposure

The assessment also identified exposure of sensitive information associated with the payment environment.

Payment-related credentials and configuration should never be unnecessarily exposed through client-accessible responses.

Even if a particular credential cannot directly perform a sensitive operation, exposing internal payment information increases the attack surface and can provide useful information to an attacker.

5. Customer Information Exposure

API responses also exposed customer information beyond what should normally be required by the requesting client.

The observed information included personally identifiable data such as:

Name
Email address
Phone number
Order-related information

This demonstrates why APIs should follow the principle of data minimization.

If an endpoint only needs to return an order status, there is no reason for it to also return unnecessary customer information.

6. Session Token Exposure

Another issue involved the transmission of checkout session tokens through request URLs and headers.

Sensitive session values appearing in URLs can create additional exposure through mechanisms such as logging, browser history, caching, and other infrastructure.

Session tokens should be treated as credentials and handled accordingly.

The Common Pattern

Although these vulnerabilities affected different parts of the application, they shared a common underlying problem:

Too much trust was placed in client-controlled information.

The security boundary should look like:

Client Input
     ↓
Authentication
     ↓
Authorization
     ↓
Input Validation
     ↓
Business Logic Validation
     ↓
Sensitive Operation

Client Input
     ↓
Authentication
     ↓
Authorization
     ↓
Input Validation
     ↓
Business Logic Validation
     ↓
Sensitive Operation

Skipping any of these checks can create unexpected security consequences.

What This Assessment Taught Me

The biggest lesson wasn't a particular payload or endpoint.

It was the importance of challenging application assumptions.

Don't assume:

A cart ID belongs to the current user.
A course ID is authorized for the current user.
A price supplied by the client is trustworthy.
Sensitive customer data should automatically be returned.
A session token is safe simply because it is transmitted over HTTPS.

Every security-sensitive decision should ultimately be enforced by the server.

Final Thoughts

The most interesting vulnerabilities are sometimes hidden inside completely normal workflows.

A cart.

A course ID.

A checkout request.

A session token.

Individually, these may look harmless.

But when an application trusts them without proper validation, they can cross security boundaries they were never supposed to cross.

Don't just test whether an API accepts a request. Test whether the server is actually enforcing the rules behind that request.

This write-up intentionally omits the affected website and sensitive production identifiers.

Contents