How an Overlooked Request Header Exposed All My Transaction Records

Discovery: A Too‑Clean System

While monitoring traffic, the author noticed a request header X-Account-Id: <user_id_here> that appeared decorative. The system’s responses were uniform and showed no errors, giving a false sense of safety.

Validation: One Header’s Cost

Replaying the request with the original session returned normal transaction history. Changing only the X-Account-Id value to another account’s ID, while keeping the same session and cookies, caused the server to return the second account’s complete financial data—including transaction history, rewards, and billing preferences—without any authorization checks.

The backend trusted the client‑provided identifier instead of verifying ownership.

Root Cause: Backend Delegates Identity to the Client

Normally, after login the backend extracts the user identity from a JWT and queries data accordingly. In this case, the backend directly used the X-Account-Id header supplied by the client to fetch data, ignoring whether the ID matched the authenticated user.

In financial terms, this design is equivalent to leaving the vault key in the user’s pocket and trusting them not to open others’ vaults.

Impact Expansion: Multiple Endpoints Affected

After confirming the vulnerability on /user/past_transactions, the author examined related APIs and found the same issue on:

Rewards : other users’ points balances and redemption records.

Billing Preferences : other users’ payment methods and billing settings.

Account‑linked data : various associated information.

All these endpoints relied on the client‑provided ID without server‑side verification.

Boundary Testing: Staying Within Ethical Limits

The author used only two of their own accounts, never guessed or enumerated other user IDs, and avoided bulk data extraction, demonstrating responsible security research practices.

Report and Remediation: Fast Response and Reward

After submitting the report, the vendor quickly engaged, discussed the attack surface, and re‑evaluated the severity as the vulnerability exposed sensitive financial data. The issue was patched, and the researcher received a bounty within 24 hours.

Post‑mortem: A Simple Workflow Mistake

A developer added the header for routing convenience, and another developer later used that header directly in database queries without integrating it into the authentication flow. The oversight persisted for months because the system silently trusted the client.

Key Takeaways

Trust Your Instincts : Even a seemingly clean system can hide over‑trusting designs.

Request Headers Are Not Secure : All client‑supplied data, including headers, must be validated server‑side.

IDOR in Finance Is Critical : Changing a single ID can instantly expose another user’s data.

Responsible Testing Matters : Use only your own accounts and minimal data to prove a flaw.