The ‘Exposed API Secret’ My Vulnerability Scanner Found Was a Cloudflare Beacon Token

The short answer

My scanner flagged a MEDIUM “Generic API secret exposed” finding. It was a false positive: the high-entropy value was a Cloudflare Web Analytics beacon token, which is public by design and ships to every visitor’s browser. The finding was also unactionable because it recorded the scanned host instead of the exact URL. I fixed both problems: record the full resolved URL, and suppress known public client tokens.

The symptom

The finding came from the secret-detection module in my web vulnerability scanner, a generic high-entropy detector that looks for values that statistically resemble credentials. It reported one MEDIUM issue: Generic API secret exposed.

The immediate problem was not whether the finding was true. It was that I could not act on it at all. The finding showed only the base host, with no path. I had no idea which page the supposed secret was on, so there was nowhere to even begin looking. A security finding you cannot locate is close to worthless, regardless of whether it is real.

The environment

This was my own tooling running against a site I was scanning. The scanner walks a target, follows redirects, and runs several detection modules over the responses, one of which is the generic secret detector. Nothing exotic in the stack; the interesting part is entirely in how the finding was produced and reported.

What I suspected first

My first assumption was the boring one: a real leaked key. A high-entropy string on a live page is exactly what you want a secret detector to catch, so I took it seriously and went looking for the source. That is when the missing path stopped me. I could not reproduce the finding by eye because I did not know where to look.

Root cause 1: the finding was unactionable

The first problem was in how the module labelled its own output. It tagged findings with the scanned host rather than the final URL after redirects. The target I was scanning was a bare IP that issued a 301 redirect to a virtual host. By the time the finding was recorded, the location had collapsed down to just the IP.

On top of that, the module truncated URLs longer than roughly 80 characters. So even in cases where a path survived, a long one was mangled. Between the redirect collapse and the truncation, the single most important field on a web finding, the exact location, was either missing or corrupted.

Root cause 2: it was never a secret

Once I reconstructed the actual page, the “secret” turned out to be a Cloudflare Web Analytics beacon token. Cloudflare injects a snippet like this into the page, client-side:

<script defer src="https://static.cloudflareinsights.com/beacon.min.js"
  data-cf-beacon='{"version":"...","token":"..."}'></script>

That token is public by design. It ships to every visitor’s browser as part of the analytics beacon, because the browser needs it to report analytics back to Cloudflare. It is not a credential. There is nothing to rotate, nothing to hide, and no way to treat its presence on the page as a leak. Flagging it as an exposed secret is simply wrong.

The network-vantage subtlety

There was one more twist worth recording, because it nearly sent me down a rabbit hole. The finding only reproduced from the scanner’s own network vantage point. When I ran an external curl of the page, I got zero findings. Running the same detector from the scanning host returned one.

The explanation is that an edge, cache, or analytics variant of the page, the one carrying the beacon, was being served on some network paths and not others. This is a useful reminder in its own right: content can genuinely differ depending on who is asking and from where. A finding that reproduces from one vantage point and not another is not necessarily a bug in your scanner. It can be the honest truth about what the site serves to different clients.

The fix

Two changes, one for each root cause.

Record the exact resolved URL

Every web finding now records the final URL after all redirects, untruncated. No collapsing back to the scanned host, no 80-character cut-off. A finding without its precise location is barely a finding at all, so this is now non-negotiable in the reporting path.

Suppress public client tokens

I added a suppression list for known public client tokens. A high-entropy "token":"..." sitting inside a recognised public marker is public by design and should not be reported as a secret. The concrete markers I suppress:

• Cloudflare data-cf-beacon
• Google reCAPTCHA, hCaptcha, and Cloudflare Turnstile site keys
• Google Analytics and Google Tag Manager IDs
• PostHog project keys

All of these are client-side, public-by-design tokens. They belong in the page, the browser needs them, and there is no secret to protect.

Reusable lessons

1. A web finding is worthless unless it records the full resolved URL: post-redirect and untruncated. Fix your reporting before you argue about detection quality.
2. Generic high-entropy secret detectors must be context-aware. If they cannot tell a real credential from a public analytics token, real findings drown in noise and people stop reading the report.
3. Content can vary by network vantage. Confirm a finding reproduces from an external viewpoint before you trust it.

When this may not apply

The point is not to suppress every token. A genuine server-side secret, a real API key, or a private token that was only ever meant to live server-side, is a real finding and should stay one. Suppression applies only to the known-public client markers above. If a token is not on that list, treat it as real until proven otherwise. The suppression list is an allowlist of things known to be safe, not a blanket excuse to ignore high-entropy strings.

Reusable checklist

• Does the finding record the final URL after all redirects, untruncated? If not, fix that first.
• Is the value inside a known public marker (data-cf-beacon, a captcha site key, a GA/GTM ID, a PostHog project key)? If so, suppress it.
• Does the finding reproduce from an external vantage point, not just the scanning host?
• If the token is not on the public-marker list, treat it as a real secret until you have proven otherwise.

Takeaway

Half the value of a scanner is telling you exactly where something is; the other half is knowing what is genuinely a secret and what is public by design.

AI assisted with drafting this write-up; the investigation, tooling, and findings are from my own real vulnerability scanner.