Unauthenticated BOLA in tRPC API Allows Bulk Cross-User Receipt Extraction
The Risk
The platform's internal data API let anyone, with no login at all, ask for any user's full activity history just by changing a number in the request. One sample pulled more than three thousand records totalling around 6 megabytes for a single account. By scripting that request across a range of account numbers, an outsider could quietly scrape the platform's entire user activity dataset, including wallet addresses, signatures, and a record of every reward each user has claimed.
The Vulnerability
The web application exposed user-scoped tRPC procedures that did not require authentication and did not enforce object-level authorization. The primary procedure accepted a caller-controlled integer user ID and returned that user's full activity dataset to any unauthenticated requester.
Several related procedures followed the same pattern, including procedures with "debug" in their names that were still reachable in production.
The Attack
Bulk Cross-User Read
Sending a GET request with no cookies, tokens, or API keys, and an arbitrary userId in the query, returned a large JSON array of receipt objects belonging to that user. Setting userId=0 returned an empty dataset, which proved the server was selecting data based on the caller-supplied identifier rather than from a session.
For one tested account, the response contained 3,154 records totalling roughly 6.4 MB. Each record included wallet address, signature, nonce, and references to the campaign and reward associated with the user's activity.
Pattern Across Related Procedures
The same authorization gap was present on several related endpoints:
- A count procedure returning the total number of records per user.
- An XP/level procedure returning experience and level data for any user ID.
- A debug procedure that accepted a single receipt ID and returned the underlying record, including its owner.
- A debug fee procedure exposing internal token and fee metadata per claim.
Iteration Strategy
Because user IDs were sequential integers, an attacker could iterate through the ID space and harvest activity data at scale. No rate limits or authentication challenges interrupted the requests.
The Impact
- Unauthenticated cross-user data access at scale, with no login required.
- Bulk extraction of receipts containing wallet addresses, signatures, and campaign metadata for correlation across contexts.
- Internal debug endpoints reachable in production, exposing additional fields not normally surfaced to end users.
- Pattern-level authorization gap, indicating missing or insufficient auth middleware across the router rather than a single oversight.
Remediation
- Require authentication on every user-scoped procedure.
- Derive the acting user identity server-side from the authenticated session. Do not accept client-supplied user IDs for user-scoped data.
- Enforce object-level authorization on receipt and claim ID lookups by verifying ownership before returning data.
- Remove debug procedures from production, or gate them behind environment checks plus admin authorization.
- Audit every tRPC router and procedure for missing auth middleware and over-broad response fields.