Poisoning Analytics Through an Open Endpoint

The engagement covered the public-facing and API infrastructure of a cryptocurrency exchange. The scope included authentication mechanisms, trading API authorization controls, fund transfer restrictions, and the broader set of endpoints reachable from the internet without credentials.

Most of the infrastructure was well-defended. The authentication flow used proper token binding, the trading API enforced per-user authorization on every operation, and the withdrawal flow required multi-factor confirmation. The finding described here was not a path to fund theft or account takeover. It was a different kind of integrity problem — one that affected the platform's ability to trust its own data.

The Endpoint

During a pass through the application's JavaScript bundle, a network request intercepted by the proxy stood out. The trading interface, when a user completed an account registration step, dispatched a POST request to an endpoint on the platform's own domain:

POST /api/analytics/events
Content-Type: application/json

The payload was a structured JSON object containing an event name and a set of parameters:

{
  "event": "CompleteRegistration",
  "params": {
    "content_name": "exchange_signup",
    "currency": "USD",
    "value": 0
  }
}

The endpoint accepted the payload and returned HTTP 200 with an empty body. It had no authentication header requirement, no CSRF token validation, and no session cookie check.

The JavaScript that generated this request was not obfuscated. The bundle contained the full endpoint path, the list of supported event names, and the parameter structure for each event type. Reading the bundle was sufficient to construct a working client for the event proxy.

What the Endpoint Did

The endpoint was a server-side event forwarding proxy. The platform used a major advertising and analytics platform for conversion tracking. Rather than sending events directly from the browser — where they would be suppressed by ad-blocking extensions used heavily in the cryptocurrency user base — the frontend sent events to the platform's own backend, which forwarded them to the analytics provider using a server-side API.

This architecture is common and, when implemented correctly, provides meaningful advantages: server-side context can be attached to events that the browser cannot provide, verified user identifiers replace browser fingerprints, and the events reach the analytics provider regardless of browser privacy settings.

The flaw was that the backend proxy accepted the event payload from the frontend verbatim and forwarded it without modification. It did not attach a verified session identifier. It did not validate that the event name was one that could legitimately occur at the current point in a real user journey. It did not rate-limit requests to the number of events a single user could plausibly generate.

The proxy trusted the client completely. That trust was the vulnerability.

Reproducing the Issue

A request constructed outside the browser, with no cookies and no session token, was sent directly to the endpoint:

POST /api/analytics/events
Content-Type: application/json

{
  "event": "Purchase",
  "params": {
    "content_name": "btc_purchase",
    "currency": "USD",
    "value": 50000
  }
}

The server returned HTTP 200.

The analytics platform's event stream, accessible through the platform's dashboard, received the event. It appeared in the conversion tracking data alongside events from real users. The platform had no mechanism to distinguish this injected event from a genuine one.

The test was conducted against the assessment environment with a test account, using event names and values that would be clearly synthetic in the timeline. The finding was confirmed against the production endpoint structure using a single benign event to verify the same response behavior, and the test was stopped there.

What an Attacker Could Do With This

The most direct harm was to conversion tracking data. Platforms that advertise their product on social media and search networks measure the effectiveness of those campaigns by tracking conversion events — signups, deposits, completed purchases. If synthetic conversion events can be injected at volume, campaigns that are not performing can be made to appear as if they are. Budget allocated based on fabricated conversion data is wasted.

The more consequential downstream risk was in automated systems that acted on analytics signals.

Promotional logic. Some platforms tie welcome bonuses or referral credits to verified conversion events in their analytics pipeline. If a promotion credit is issued when the analytics platform records a qualifying event, and events can be injected without session authentication, the promotional system can be triggered for accounts that have not completed the qualifying action. This depends on how tightly the promotional logic is coupled to the analytics event stream rather than to verified backend state — but on platforms that use analytics events as a trusted signal, it is a real exposure.

A/B testing and feature rollout. The platform used the same analytics infrastructure to measure the results of product experiments. Feature variants were evaluated by comparing conversion rates across user segments. Injected events attributed to specific user identifiers can skew these measurements, causing the platform to incorrectly identify which variant performs better and roll out features based on fabricated results.

Fraud model poisoning. Behavioral analytics feeds into fraud detection in the form of baseline models for normal user activity. A sustained injection of synthetic normal-looking events can push the baseline in a direction that makes genuinely anomalous activity appear within the normal range.

How the Endpoint Was Found

The path to discovery was straightforward enough to warrant describing explicitly.

The JavaScript bundle was approximately 4.2 MB, a size typical for a modern single-page trading application. Searching the bundle for string patterns associated with API calls — /api/, fetch(, axios.post — returned a few hundred candidate strings. Most pointed to the trading and account management APIs that were already in scope.

The analytics endpoint was referenced in a module that handled post-registration tracking. The module's function names were not minified — the build configuration preserved them for stack trace readability — so the code block containing the endpoint reference was identifiable by function name before the string itself was read.

This is worth noting because teams sometimes assume that compiled JavaScript bundles offer meaningful protection for endpoint paths through obscurity. They do not. Any endpoint that the frontend needs to call must be reachable from the browser, and the path to that endpoint is present in the JavaScript the browser executes. The only meaningful protection is proper access control on the server side.

The Fix

The remediation moved event dispatch entirely to the server side, removing the client-facing proxy endpoint.

Rather than accepting a frontend-specified event payload, the backend now generates analytics events itself based on verified state transitions: when the user record in the database transitions to a new status, or when a transaction is marked complete by the settlement system, the backend dispatches the corresponding analytics event directly to the analytics provider using the server API key. No frontend involvement is required or accepted.

This approach is strictly better than the original architecture in every dimension relevant to the vulnerability:

• Events carry server-verified user identifiers rather than client-supplied parameters
• Events are only generated when the corresponding state transition is recorded in the database
• No network path from the internet reaches the event dispatch logic
• The analytics data accurately reflects platform activity rather than what clients report

The client-facing /api/analytics/events endpoint was removed entirely. The analytics JavaScript in the frontend was reconfigured to operate in a mode that suppresses direct browser-to-analytics-platform requests, since all event dispatch now happens server-side.

The Broader Pattern

This class of vulnerability appears frequently on platforms that migrate from client-side to server-side analytics forwarding. The migration is done to improve data quality and ad-blocker bypass rates — both legitimate engineering goals. The new server-side endpoint is designed to receive data from the frontend, and its developers think of it as an internal conduit rather than a public API. The authentication check is deferred because it seems unnecessary for something that is just forwarding data. The endpoint ships without it.

From the attacker's perspective, any endpoint that accepts data and does something useful with it is a candidate for abuse. The question is not whether the endpoint was intended to be public, but whether it enforces access control on every operation it performs.

An analytics proxy that forwards to a third-party platform is performing a write operation on behalf of the platform — inserting data into a system that informs decisions. That operation requires the same authorization checks as any other write. The authentication requirement cannot be waived because the data being written is analytics rather than account state.

The integrity of data used to make decisions has the same security requirements as the integrity of operational data. It just fails more quietly.

For a technical overview of authorization vulnerabilities across web application layers, see the OAuth 2.0 security knowledge article.