# Storefront — third-party origin audit (Cloudflare edge beacon)

**Date:** 2026-10-15 · **Status:** root-caused, one in-scope mitigation shipped, one dashboard action
recommended.

## Finding

The **live** storefront contacts a third-party origin that appears nowhere in our code:

```
https://static.cloudflareinsights.com/beacon.min.js/v4bc70e2c01a94c73b74392e4234840661791215815920
```

This matters because the storefront's whole promise is *ad-free, no trackers, zero third-party
origins*, and because it costs our visitors a cross-origin DNS lookup + TLS handshake + 11 KB before
they can read a price.

## Why it is hard to see

`curl` and the origin server **never show it**:

| Probe | Result |
|---|---|
| `curl -s https://metatronmind.com/store` (default UA) | 0 beacon references |
| `curl -s -H 'User-Agent: Mozilla/5.0 … Chrome/120' …` | **0** beacon references |
| `Accept-Encoding: identity` and `gzip` | **0** beacon references |
| `app/server.mjs` served locally | 0 beacon references |
| Playwright, **raw response body** | `false` |
| Playwright, **rendered DOM** | **`true`** |
| Playwright, origins contacted | `metatronmind.com`, `static.cloudflareinsights.com` |
| `navigator.serviceWorker.getRegistrations()` | `[]` — no SW involved |

So it is **not** in our HTML and **not** in the response body we can fetch. It is injected into the
page **by Cloudflare at the edge, into real browser sessions only** — the likely mechanism is a
Cloudflare feature (Web Analytics / Rocket Loader) that runs only for browser-shaped clients and
attaches the beacon to the rendered DOM. Response headers confirm Cloudflare fronts the host
(`server: cloudflare`, `cf-ray`, `cf-cache-status: DYNAMIC`).

**Consequence for testing:** any harness that inspects `curl` output or the HTTP response body will
conclude "no third-party origins" and be **wrong**. It must inspect the rendered DOM and the
observed network origins. The independent verifier caught this because it did exactly that.

## Mitigation shipped (in scope)

The shell declares a restrictive Content-Security-Policy that forbids scripts from any origin but
ours. Verified in Chromium 1223 that it **blocks the beacon's execution** while leaving our own
scripts, inline bootstrap (`window.APP_BASE`), stylesheets and same-origin images fully working:

```
default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';
img-src 'self' data:; font-src 'self'; connect-src 'self'; object-src 'none';
base-uri 'self'; form-action 'self'
```

`'unsafe-eval'` is deliberately **absent**: `grep` confirms no `eval(`, `new Function`, or
string-argument `setTimeout` in any of our scripts, and no inline event-handler attributes in the
markup. `'unsafe-inline'` remains in `script-src` for the one-line `window.APP_BASE` bootstrap;
tightening that to a hash is a worthwhile future change.

**Accepted trade-off:** the browser will log

```
Loading the script 'https://static.cloudflareinsights.com/beacon.min.js/…' violates the following
Content Security Policy directive: "script-src 'self' 'unsafe-inline'"
```

This one console error is **the mitigation working**, not a defect. A verifier must classify it as
PASS-with-note, and it is the only console error the shell is permitted to produce.

## ✅ DONE — the injection was stopped at the source (2026-10-15)

A CSP only blocks the beacon *after* the edge has injected it: the browser still attempted the fetch
before CSP aborted it. The injection has now been switched off in the Cloudflare dashboard, so the
request is never made at all.

**Verified on the deployed host by browser measurement, not by the toggle's position:**

| check | result |
|---|---|
| injected elements (`script[src]`, `img[src]`, `link[href]` matching the beacon) | **NONE** |
| `[data-cf-beacon]` attribute anywhere in the DOM | **false** |
| beacon entries in `performance.getEntriesByType('resource')` | **NONE** |
| beacon request events | **NONE** |
| third-party origins contacted | **NONE** (was `static.cloudflareinsights.com`) |
| console errors | **0** (was exactly 1, the CSP refusal) |
| `cloudflareinsights` string in the DOM | 1 occurrence, **inside an HTML comment** — it is this document's own explanation in `index.html`, not an element or a request |

Checked on `shop.metatronmind.com/`, `shop.metatronmind.com/about` and the legacy
`metatronmind.com/store`. **The "zero third-party origins" claim is now unconditionally true rather
than true-by-interception**, the CSP console noise is gone, and the `[ PROOF ]` band needs no caveat.

⚠ One measurement trap worth recording, because it produced a false positive twice while checking
this: `grep cloudflareinsights` on the served HTML **still matches**, because `index.html` contains an
HTML comment naming the beacon in order to explain the mitigation. A string count is not evidence of
an injection. The checks above look for an **element**, a **DOM resource entry**, or a **request** —
and that is the form any future re-verification should use.

The original reasoning is kept below for the record.

### Original follow-up (now actioned)

> **Cloudflare dashboard → the `metatronmind.com` zone → Speed → Optimization → disable
> "Web Analytics" / Rocket Loader** (and check Analytics → Web Analytics for an enabled beacon).

That removes the request entirely, drops ~11 KB, removes the CSP console noise, and makes the
"zero third-party origins" claim unconditionally true instead of true-by-interception.

### This is now an OPTIONAL CLEANUP, not a blocker for the marketing claim

The storefront publishes a **`[ PROOF ]`** band in the footer carrying the position:

> **Every byte on this page is ours.** — 0 third-party requests · no analytics · no trackers · fonts self-hosted

That copy is deliberately written so it is **airtight in both states**, which is why the dashboard
toggle is a bonus rather than a precondition:

| Claim | Why it is true today, before the dashboard change |
|---|---|
| **0 third-party requests** | True of everything the storefront loads: `grep 'https\?://'` across `store.js`, `cart.js`, `motion.js`, `tokens.css` and `storefront.css` returns only `http://www.w3.org` — the SVG XML namespace *identifier*, not a request. |
| **No analytics / no trackers** | Nothing in our code loads one; the edge-injected beacon is blocked by CSP and **never executes** (verified against a simulated injection: `beaconExecuted=false`, no `__cf*` global, response failed with `csp`). |
| **No cookies** | `Set-Cookie` is absent on `/store` — on the live host *and* locally. |
| **No accounts / no cookie banner** | Only `tshirt.cart` and `tshirt.ship` in `localStorage`, on the customer's own device. Zero `document.cookie` usage in any storefront file. |

**What we deliberately do NOT claim:** that *nothing anywhere* attempts a request. Cloudflare's edge
does attempt one, and a claim that broad is falsifiable in ten seconds of DevTools. Precision is the
point — a claim a skeptic can verify is worth more than a superlative they can disprove.

Required precision if this ever gets copy-edited: **"no analytics or trackers in this storefront"**,
never **"no requests are ever made"**.

Until the dashboard change is made, the honest statement is: **our code requests nothing from any
third party; Cloudflare's edge injects an analytics beacon which our CSP then blocks from executing.**
After it, the footnote can simply be dropped.