Raised by CodeRabbit on PR #40 (scripts/dns-origin-audit.sh, the CNAME-target
allow-list). Deliberately not fixed in that PR: it is off the critical path to
the incident's closure condition, and CodeRabbit's own label for it was "Heavy lift".
Filing it so it is tracked rather than rediscovered.
The defect
The allow-list accepts an origin by DNS suffix. Three of the suffixes on it are
multi-tenant platforms:
github.iopages.devworkers.dev
On those platforms the suffix says nothing about ownership. anyone-at-all.pages.dev
matches the same rule as ours does. So for those three, the check answers "this origin
is on the allow-list" when the question it is supposed to answer is "this origin is
one we control".
This is an instance of the estate's recurring shape: a guard that asks a different
question than its consumer. It does not make the audit report a false clean on the
incident itself — a record aimed at 65.181.113.13 is still caught by the deny entry
and by the unlisted-IP path — but it means a record repointed at a stranger's Pages or
Workers site would pass.
Why it is a heavy lift
The correct check is per-zone expected targets: for each zone, the specific
<name>.pages.dev / <user>.github.io / <name>.workers.dev hostname that zone is
supposed to CNAME to. That is a data problem, not a code problem — the expected
mapping does not exist anywhere yet and has to be built from the Cloudflare zone list
plus the Pages/Workers project inventory, then kept in step with them.
A cheaper interim that is strictly better than today: allow-list the exact
hostnames rather than the suffixes, accepting that each new Pages project needs a
one-line addition. That converts a silent acceptance into a loud, obvious failure the
first time the list is out of date, which is the right direction for this estate.
Acceptance
- No bare multi-tenant suffix remains in the allow-list.
- A fixture aimed at
not-ours.pages.dev produces a finding, and one aimed at a real
estate target does not — i.e. the change is proven by a control, not by a green run
(a green run is what let this through).
🤖 Generated with Claude Code
https://claude.ai/code/session_019ggwBcC2PHLMn5ZSfma1eR
Raised by CodeRabbit on PR #40 (
scripts/dns-origin-audit.sh, the CNAME-targetallow-list). Deliberately not fixed in that PR: it is off the critical path to
the incident's closure condition, and CodeRabbit's own label for it was "Heavy lift".
Filing it so it is tracked rather than rediscovered.
The defect
The allow-list accepts an origin by DNS suffix. Three of the suffixes on it are
multi-tenant platforms:
github.iopages.devworkers.devOn those platforms the suffix says nothing about ownership.
anyone-at-all.pages.devmatches the same rule as ours does. So for those three, the check answers "this origin
is on the allow-list" when the question it is supposed to answer is "this origin is
one we control".
This is an instance of the estate's recurring shape: a guard that asks a different
question than its consumer. It does not make the audit report a false clean on the
incident itself — a record aimed at
65.181.113.13is still caught by the deny entryand by the unlisted-IP path — but it means a record repointed at a stranger's Pages or
Workers site would pass.
Why it is a heavy lift
The correct check is per-zone expected targets: for each zone, the specific
<name>.pages.dev/<user>.github.io/<name>.workers.devhostname that zone issupposed to CNAME to. That is a data problem, not a code problem — the expected
mapping does not exist anywhere yet and has to be built from the Cloudflare zone list
plus the Pages/Workers project inventory, then kept in step with them.
A cheaper interim that is strictly better than today: allow-list the exact
hostnames rather than the suffixes, accepting that each new Pages project needs a
one-line addition. That converts a silent acceptance into a loud, obvious failure the
first time the list is out of date, which is the right direction for this estate.
Acceptance
not-ours.pages.devproduces a finding, and one aimed at a realestate target does not — i.e. the change is proven by a control, not by a green run
(a green run is what let this through).
🤖 Generated with Claude Code
https://claude.ai/code/session_019ggwBcC2PHLMn5ZSfma1eR