~/blog/error-tracking-telemetry-exposurePOSTED
by Shady Nathan Tawfik · July 18, 2026 · 4 min

Error Tracking Telemetry Describes Your Architecture To Anyone With A Browser

A platform provider running a Java backend behind two reverse proxies with a modern front end. The interesting finding was not a vulnerability but an inventory: error tracking revealed the internal structure.

Interactive[blog-2.0]

TL;DR: Error tracking solved an engineering problem and created a recon channel: the telemetry endpoint accepted unauthenticated events and the payloads described my three-tier architecture. I explain the fix at the edge.

The scenario

I ran this as a black-box review: no credentials, only the publicly visible surface. Here is what I saw before I touched anything.

A platform and infrastructure provider operating a multi-tier estate: an outer reverse proxy, an inner application server, an additional gateway for one service, and a component framework front end. Scope covered header posture across all tiers, telemetry exposure, error handling and version disclosure.

I removed all identifying information. The target is described only by sector and technology class so the pattern can be reused.

The pattern

The pattern I recognised — and that I keep finding in similar estates:

Error tracking solves a real problem and creates a specific one. To report an exception, the browser needs an endpoint and a project key. Both are embedded in the delivered bundle, because the frontend is the component collecting the error. That key is not a credential in the classical sense, but it is an invitation: with it, anyone can submit events, and depending on the configuration, read them back.

The second-order effect is architectural. Frontend errors carry request context, and request context carries hostnames, internal identifiers and occasionally session identifiers. Reading other projects’ events is therefore a reconnaissance channel that costs one bundle download and yields the tier structure that three proxy hops were supposed to hide. In an estate running an outer proxy, an inner server and a per-service gateway, the telemetry data described all three tiers while the public surface described one.

This is why observability belongs in the same threat model as authentication. It is infrastructure, it is configured once by whoever installed the agent, it usually has no authentication requirement because it is assumed to be a build-time concern, and it is never revisited. The exception handler is the part of an application most likely to render a secret into a log.

TL;DR: A platform provider running a Java backend behind two reverse proxies with a modern front end. The interesting finding was not a vulnerability but an inventory: error tracking revealed the internal structure.

Findings

SeverityFindingEvidence
HIGHError reporting endpoint accepts unauthenticated submissionsThird-party event injection into the project
MEDIUMProject and release identifiers in the bundleEnvironment and release naming visible
MEDIUMInternal hostnames in telemetry payloadsTier structure readable from event context
MEDIUMException details rendered to visitorsInternal paths and types in the response
LOWTunnel and gateway software version exposedPlatform stack identifiable
LOWContent security policy inconsistent across tiersPolicy present on some hosts, absent on others

The attack path

Browser bundleError reporting endpointEvent projectBackend request contextInternal hostnames in telemetryReadable tier structureTargeted reconnaissance

Reproduction in my lab

Every command below targets a lab container I control. Nothing here is aimed at a live system.

Find telemetry endpoints in a bundle you own

~/code/bash bash
$ for f in $(curl -s https://example.org/ | grep -oE '/assets/[A-Za-z0-9._-]+\.js' | sort -u); do
    curl -s "https://example.org$f"
  done > /tmp/bundle.txt

$ grep -oiE 'sentry|datadog|bugsnag|newrelic|rollbar|raygun|glitchtip' /tmp/bundle.txt | sort | uniq -c
$ grep -oE 'https://[a-z0-9.-]*(sentry|ingest|observe|collect)[a-z0-9./-]*' /tmp/bundle.txt | sort -u | head
$ grep -oE '[a-f0-9]{32}' /tmp/bundle.txt | sort -u | head

Detection in your own estate

Read the tier structure out of your own error payloads

~/code/bash bash
# trigger a harmless error and inspect what your own telemetry would record
$ curl -so /dev/null -w '%{http_code}\n' 'https://example.org/api/does-not-exist'

# read the proxy chain
$ curl -sI https://example.org/ | grep -iE '^(via|x-powered-by|x-generator|server|x-aspnet|front-end)'

# list every host in the chain by certificate name
$ echo | openssl s_client -connect example.org:443 -servername example.org 2>/dev/null \
  | openssl x509 -noout -text | grep -i 'subject alternative name' -A1

Remediation

Gate telemetry ingestion and never trust client context

~/code/nginx nginx
# require an ingestion key at the edge, not just in the SDK
location = /monitoring/client-api/{project}/envelope/ {
    if ($http_x_telemetry_key != "<server-held-key>") { return 403; }
    proxy_pass http://telemetry-backend;
    proxy_hide_header Set-Cookie;
}

# and stop advertising the chain
server_tokens off;
proxy_hide_header X-Powered-By;

Once an attacker gains access, they can perform the following actions:

Error reporting endpoint accepts unauthenticated submissions
Project and release identifiers in the bundle
Internal hostnames in telemetry payloads
Exception details rendered to visitors

Takeaways

  • The exception handler is the part of an application most likely to render a secret.
  • A telemetry project key is an invitation, not a credential you can ignore.
  • Error context describes the tiers your proxies were meant to hide.
  • Give observability the same review cadence as authentication.

For educational purposes only. Every reproducible command targets my own lab environment (localhost), never a live system. © 2026