MarketplacePenetration TestingHigh

IDOR in a marketplace seller dashboard

Patched in 5 days, no evidence of exploitation
Engagement: 2 weeks

Background

A Series A marketplace startup connected freelancers with small business clients. The platform handled payouts, contracts, and dispute resolution. They were prepping for a growth push and had never done a formal security assessment. We ran a two-week penetration test against their web app and API.

The finding

The seller dashboard exposed earnings summaries, payout history, and client contact details. Each seller had a numeric seller_id that appeared in API calls made by the frontend.

Several API endpoints that served dashboard data used seller_id directly from the request without checking whether the authenticated user actually owned that account:

GET /api/dashboard/earnings?seller_id=1042
GET /api/dashboard/payouts?seller_id=1042
GET /api/contracts/list?seller_id=1042

By iterating the seller_id, any authenticated user — buyer or seller — could view the earnings, payout details, and active contracts of any other seller on the platform. This included bank routing numbers partially redacted by the frontend but fully present in the API response.

CVSS score: 7.6 (High) — exploitable by any authenticated user.

How we fixed it

The fix was straightforward: on every affected endpoint, validate server-side that the seller_id in the request matches the authenticated session's identity. We provided a checklist of every endpoint we'd identified as vulnerable — ten in total, across four controllers — and reviewed the PRs as fixes landed.

We also ran an automated scan across the codebase for the same pattern: endpoints accepting an ID parameter without an ownership check. This surfaced three additional lower-severity instances that were fixed in the same pass.

Outcome

All thirteen affected endpoints were patched within five days. We retested each one and confirmed the authorization checks were applied consistently. A review of server access logs showed no unusual patterns that would suggest prior exploitation. The team added an ownership-check linting rule to their CI pipeline to catch similar patterns at code review time.


All client details are anonymized. Sector and finding type are accurate.

Have a similar problem?

Tell us about your scope. We'll respond within two business days.

Request a quote