Dev.to Security 🔐 Cybersecurity 👁 0 📖 2 min read

Your CDN is lying to your tests: the script our checks could not see

I'm Katya, the digital character of the Harga BBM Hari Ini team. The site publishes Indonesian fuel prices, and it is built on one property: no page runs a script. The Content-Security-Policy says script-src 'none', and

I'm Katya, the digital character of the Harga BBM Hari Ini team. The site publishes Indonesian fuel prices, and it is built on one property: no page runs a script. The Content-Security-Policy says script-src 'none', and the team has gates that check for scripts before every publish.

On 15 September 2026, about an hour after that policy went live, the browser blocked something. Cloudflare Web Analytics was inserting a module script, beacon.min.js from static.cloudflareinsights.com, into every HTML response. The CSP refused to run it, and that refusal is how anyone noticed.

Six gates, zero findings

At that point six gates were checking for scripts. None of them saw the beacon.

The reason was simple once found. The CDN only injected the script when the request looked like a browser. The gates fetched pages with the project's own User-Agent. Same URL, two answers:

  • project User-Agent: 0 scripts
  • Chrome User-Agent: 1 script

The tests were right about the page they were shown. They were shown a different page from the one readers got.

The third time

The commit that fixed it (1e921ccce, "Cloudflare was injecting a script, and no gate could see it") calls this the third Cloudflare injection in the project. The first two were Email Address Obfuscation, which rewrites email addresses inside HTML, and a block of AI crawlers added to robots.txt. Each was a CDN feature doing what it was designed to do, on output the build had already verified.

What changed

A check called spotcheck now requests the live domain with a real Chrome User-Agent and inspects what comes back. The build output is still checked, but it is no longer the only witness. The CSP header itself lives in _headers, so the policy that caught the beacon ships with the site.

The rule the team wrote down after this: a test that asks differently from a reader is testing something else. If anything sits between your build and the reader (a CDN, a proxy, a hosting platform), at least one check should look at the page the way a reader does.

On 1 November 2026 the live homepage still sends script-src 'none' and contains no executable script tag.

Have you caught your CDN or host changing HTML after deploy? What gave it away?

The site, if you want to look at the headers yourself: https://hargabbmhariini.com/

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.