Case Study: E-Commerce Platform

Independent Application Security Assessment

Engagement Type: Bug Bounty (Managed Program)
Assessment Period: February 2026
Vulnerability Class: Broken Object Level Authorization (BOLA/IDOR)

---

Executive Summary

During a structured black-box assessment of an e-commerce platform as part of a bug bounty program, an Insecure Direct Object Reference (IDOR) vulnerability was identified in the platform's GraphQL basket API. The vulnerability allowed any unauthenticated actor to read the contents of any user's active shopping basket by supplying a known basket UUID — with no credentials, session token, or account required.

The finding was confirmed through a clean proof of concept demonstrating cross-user basket access with no authentication required. Further testing revealed that basket IDs are assigned and stored in the browser's local storage before any login or account creation occurs, broadening the affected population to all site visitors including guests.

The finding was assessed as P4 — Information Disclosure and marked as a duplicate of a report submitted in 2024 against a related target now removed from the program scope.

---

Scope and Methodology

Target Overview

The platform is a high-traffic UK beauty and lifestyle e-commerce platform. The platform is built on modern web architecture with caching and exposes a GraphQL API at two primary endpoints:

• /account/graphql — account management, authentication, and loyalty operations
• /api/graphql — storefront operations including basket, products, and content

The platform serves a broad consumer audience including unauthenticated guest shoppers, making any pre-authentication vulnerability particularly high impact in terms of affected population.

Methodology

Testing followed a structured black-box GraphQL assessment approach:

Phase 1 — Passive Recon — Network traffic observation to identify API endpoints, request patterns, and technology stack.

Phase 2 — Schema Enumeration — Confirmed GraphQL introspection was enabled in production with a single unauthenticated __schema query. Retrieved the full schema and categorised the attack surface by sensitivity.

Phase 3 — Authorization Testing — Systematically tested high-priority mutations and queries for object-level authorization failures.

Phase 4 — Basket IDOR Exploitation — Identified that the basket query accepts an optional id parameter with no ownership validation. Confirmed unauthenticated read access to arbitrary baskets.

Phase 5 — Impact Escalation Attempts — Attempted to query richer fields and test checkout flow for escalation. All escalation paths reached their ceiling without producing additional confirmed impact.

---

Validated Vulnerabilities

Finding 1: Unauthenticated Cross-User Basket Read (IDOR)

Severity: Low (P4)
Category: Broken Object Level Authorization
CWE: CWE-639 — Authorization Bypass Through User-Controlled Key
Status: Duplicate (original report 2024, out-of-scope target)

Technical Detail

The GraphQL basket query accepts an optional id parameter representing a basket UUID. The server resolves and returns basket state based solely on the client-supplied UUID, with no verification that the requesting session owns or has permission to access the referenced basket.

Basket IDs follow the format <UUID>:<unix_millisecond_timestamp>. The UUID is the stable server-side identifier; the timestamp is a revision counter. The server resolves the latest basket state for any UUID supplied, regardless of the timestamp suffix.

Basket IDs are written to browser localStorage before any login or account creation occurs, meaning every site visitor is assigned a basket ID that can be used to retrieve their basket contents by any third party who obtains the UUID.

A request sent with no cookies and no session tokens, using a UUID belonging to a different user, returned the target basket's contents — SKU, quantity, and price — in full. The response confirmed the request was fully unauthenticated.

Additional behaviors observed:

• Submitting another user's basket UUID while authenticated caused the server to merge or associate that basket with the requesting session
• Item removal on one session was reflected on the other session sharing the UUID
• The same vulnerability was confirmed to exist on at least two other properties due to shared codebase

Business Impact

An attacker who obtains a victim's basket UUID can read the products the victim is actively considering purchasing. Basket UUIDs could be obtained via XSS, shared devices, browser extensions, referrer header leakage, or network interception.

The pre-authentication nature of basket creation means the affected population is every site visitor, not only registered users.

The data exposed is shopping intent only — no PII, payment data, delivery addresses, or account credentials were accessible through this endpoint.

---

Finding 2: GraphQL Introspection Enabled in Production (Noted, Not Submitted)

Severity: Informational
Category: Server Security Misconfiguration
CWE: CWE-1188 — Insecure Default Initialization
Status: Not submitted (below program submission threshold)

Technical Detail

The GraphQL endpoint has introspection enabled in the production environment, allowing any unauthenticated client to retrieve the complete API schema including all types, queries, mutations, field names, and argument signatures.

Business Impact

Introspection accelerates reconnaissance, reducing the effort required to identify authorization gaps and sensitive mutations. It does not constitute a direct vulnerability on its own but materially lowers the barrier to discovering other issues.

---

Security Controls Assessment

API Security

✅ Delete address, cancel order, and logout session mutations properly authenticated
❌ Basket query lacks any ownership validation
❌ Replace address mutation returned internal server error on cross-user ID — inconsistent error handling
❌ Introspection enabled in production

Application Architecture

❌ Basket IDs assigned pre-authentication with no server-side ownership binding
❌ Basket state merges when authenticated user submits another user's UUID
❌ Shared codebase across properties means vulnerability persists across targets

---

Methodology Evaluation

What Worked

• Structured GraphQL recon (introspection first, schema categorisation, systematic authorization testing)
• Testing from guest/unauthenticated baseline before adding session context
• Recognising basket IDs are assigned pre-authentication (strengthened impact narrative)
• Impact escalation testing before submission (established accurate severity ceiling)

What Could Be Improved

• Time spent on escalation after core finding confirmed (~2-3 hours, no new impact)
• Checking for existing disclosed reports before deep-diving on the finding
• Testing all in-scope targets before submission (reduced duplicate risk)

---

Key Takeaways for Security Teams

1. Pre-Authentication Object Creation Broadens Impact

Guest baskets, sessions, and other objects created before login are frequently overlooked in IDOR testing. Always test ID-based queries from a zero-auth baseline before adding session context.

2. Shared Codebases Mean Persistence

A vulnerability found on one target in a shared-codebase program likely exists across all properties. Testing the same vector across all in-scope targets before submission reduces duplicate risk and may increase severity.

3. Impact Ceiling Matters

IDORs on low-sensitivity data (shopping carts, wishlists) without PII or payment data will trend toward P4 regardless of exploit chain elegance. Know the severity line before investing time in escalation.

4. GraphQL Methodology Is Replicable

Introspection first, schema categorisation, then systematic authorization testing produces confirmed findings efficiently. This pattern is transferable across GraphQL assessments.

5. Duplicate Is Not Invalid

A duplicate classification confirms the finding's validity and methodology soundness. The finding existed and was findable — it had simply been found before.

---

Recommendations

Immediate

1. Bind basket resolution to the authenticated session server-side — if a session exists, verify the basket belongs to that user before returning data
2. For guest baskets, implement server-side ownership binding rather than relying solely on UUID secrecy
3. Disable GraphQL introspection in production across all endpoints

Strategic

1. Audit all GraphQL queries and mutations accepting an id argument for consistent ownership validation
2. Apply fixes across all properties sharing the codebase simultaneously
3. Implement consistent authorization checks across the entire API surface

---

Conclusion

This engagement successfully identified a real vulnerability through structured black-box methodology, confirmed by the program's duplicate classification against a prior valid report. The core lesson was one of timing and target prioritisation: the vulnerability existed and was findable, but had already been found.

The engagement produced a clean, reproducible proof of concept with accurate impact scoping — neither underselling the finding nor overstating it. That discipline, more than the finding itself, is the transferable skill this engagement reinforced.

---

Assessment conducted under authorized bug bounty program. All testing performed ethically using researcher-owned test accounts. No real user data was accessed, modified, or exfiltrated.