Cowrie Research

canonical-domain-runtime-byte-integrity

13 min read

Canonical-Domain Runtime-Byte Integrity

  • Name: canonical-domain runtime-byte integrity
  • Category: browser-delivery reference / front-end integrity design checklist / web-control-plane security note / wallet-facing runtime-attestation note
  • Summary: Healthy wallet-facing web delivery does not treat the right domain loaded as sufficient evidence that the right code is asking for signatures. It authenticates one browser-execution object as a single security boundary: registrar and DNS control, TLS termination, CDN or edge-worker behavior, HTML/template integrity, third-party script policy, and the exact runtime bytes a real user browser fetched from the canonical domain. This note exists to keep that positive design target explicit instead of making readers reconstruct what the real site should have proved only by inverting BadgerDAO, Curve DNS hijack, and adjacent browser-delivery incidents.

Fast classifier

  • Stay here when the sharper design question is what should the real domain, naming path, and browser-delivery stack have proved before a user trusted a wallet prompt?

  • Use the shorthand same real site, different edge-served bytes for same-domain edge-path cousins like BadgerDAO, where the real site stayed Badger’s but Cloudflare-controlled delivery changed the signer-facing runtime.

  • Use the shorthand same canonical name, different resolver-chosen delivery for naming-layer cousins like Curve Finance DNS hijack, where typing the right domain stopped proving that the browser was still reaching protocol-controlled infrastructure at all.

  • Pivot first to third-party-runtime-allowance-and-integrity-pinning for the narrower browser-policy cousins preserved as same real site, different loader-resolved bytes by Ledger Connect Kit and same familiar runtime URL, different operator-resolved bytes by Polyfill.io.

  • Pivot first to release-provenance failure when the sharper question is not the domain-delivery boundary itself, but which reviewed / published / loader-resolved / browser-fetched artifact drifted away from the thing people thought they had authenticated.

  • Why this note exists:

    • Many wallet-drain incidents are casually summarized as front end was compromised, but the useful design question is narrower: what exact browser-facing object was the user supposed to trust when they typed the real domain?
    • The practical failure is often not in contracts, packages, or wallets alone; it is that the canonical-site delivery plane silently became a signer-authority surface.
    • The useful design move is to make what bytes did the real domain actually serve to real users? a first-class operational object rather than a vague inference from repo state or uptime checks.

The six joints a healthy canonical-domain delivery path should keep fused

  1. Canonical naming authority
    • The system must know which registrar, nameserver, DNS records, and fallback domains define the authentic entrypoint.
    • Users typed the right URL is not enough if DNS or registrar control can still resolve that name to attacker infrastructure.
    • Curve is the clean warning that domain continuity can survive while browser execution truth is already gone.
  2. Origin and edge control
    • The system must know which CDN, reverse proxy, edge-worker, cache-rule, or HTML-rewrite surfaces may alter what the canonical domain serves.
    • If an edge layer can inject scripts or rewrite transaction-building code, that layer is signer authority, not mere performance infrastructure.
    • Badger is the clean warning that Cloudflare Worker control was effectively wallet-policy control.
  3. HTML and bootstrap integrity
    • The initial HTML shell, script tags, import maps, and bootloader logic are part of the same trusted object.
    • A clean JavaScript bundle is not enough if the HTML or edge template can swap in a different bundle, loader, or third-party script at request time.
  4. Third-party runtime dependency policy
    • The canonical domain must know which remote scripts, analytics tags, wallet SDK loaders, or polyfill services are allowed to execute inside the trusted page.
    • If the page can still pull mutable remote code from unstable upstreams, the domain has not fully authenticated its own runtime.
    • Polyfill.io is the clean adjacent warning that same script tag can outlive the safety of the service behind it.
  5. Actually fetched browser bytes
    • The real security object is what users’ browsers fetched from production paths across regions, devices, and caches.
    • The deployed repo is clean or the CDN config looks right does not prove what a real wallet user executed.
  6. Emergency reroute and trust-preserving fallback
    • Healthy systems know how to move users to an alternate safe entrypoint or disable wallet-critical flows when canonical-domain integrity is in doubt.
    • An unaffected sibling domain, static fallback, or fail-closed maintenance mode can preserve user safety when the main domain loses delivery integrity.
    • Curve’s curve.exchange fallback is the useful contrast case.

What sound design looks like

  • The domain is a security object, not a brand label
    • Registrar controls, nameservers, CDN settings, edge-worker permissions, HTML templates, and script policies should be reviewed as part of the same custody-adjacent boundary as wallet-transaction construction.
    • If any one of those layers can change the spender, permit target, typed-data domain, or transaction destination, that layer belongs inside the wallet trust boundary.
  • Browser execution should be provable, not inferred
    • Teams should be able to answer what exact HTML and script bytes should a user browser receive from the canonical domain right now?
    • The answer should be checkable from outside the deployment pipeline, not only asserted by internal release tooling.
  • Remote script allowance should be sparse and explicit
    • Third-party scripts, tag managers, polyfills, wallet loaders, and analytics beacons should be treated as code execution rights on the signing surface.
    • If they are unavoidable, their identity and integrity should be pinned as tightly as possible.
  • Wallet-critical pages should fail closed under delivery uncertainty
    • When DNS, CDN, or edge integrity is doubtful, the safe response is often to disable transaction construction or redirect to a known-good alternate domain instead of serving partially trusted runtime code.
  • Incident response should verify from the user side
    • Recovery should be declared only after sampling the canonical domain the way real users hit it: through real DNS resolution, real CDN edges, real device classes, and real browser fetch paths.
    • Control restored and users now execute expected bytes are different claims.

Healthy architectural shapes

1. Minimal mutable edge logic on wallet-critical surfaces

  • The safest shape is often to keep wallet-critical pages as close to static, content-addressed, and edge-passive as possible.
  • Every worker, edge function, HTML rewrite rule, or personalization branch is another place where domain control can silently become transaction-construction control.
  • If mutable edge logic is necessary, it should be treated like privileged application code with review, monitoring, and narrow permissions.

2. Strong script identity on the canonical page

  • Wallet-critical pages should prefer locally served immutable bundles, strict Content Security Policy, and integrity-pinned external resources where possible.
  • The point is not generic web hardening for its own sake; it is preventing the canonical domain from becoming a mutable wallet-prompt generator.
  • We serve it from our domain is weaker than we can prove exactly which bootstrap and runtime bytes the domain may serve.

3. Independent outside-in fetch verification

  • Teams should continuously fetch the canonical page and wallet-critical assets from outside the trusted deployment path: multiple resolvers, multiple regions, multiple device classes, and multiple caches.
  • These probes should verify not only availability but expected HTML, script URLs, hashes, and signer-facing transaction-construction logic.
  • One internal curl against origin is not enough if the attack surface lives in DNS, CDN, or edge branches.

4. Explicit safe fallback domains or maintenance states

  • Protocols should know in advance what safe state looks like if canonical-domain delivery integrity fails: alternate domain, read-only mode, transaction disablement, or signed-status communication flow.
  • The goal is to preserve a trustworthy user path before the incident, not improvise one after users are already signing attacker prompts.

5. User-visible signer-context safeguards

  • Front-end transaction previews, spender allowlists, simulation, and wallet warnings are not substitutes for delivery integrity, but they reduce blast radius when delivery fails.
  • The useful standard is one bad domain response should still struggle to obtain a plausible malicious wallet prompt.

Design questions worth asking first

  • What exact browser-facing object does the protocol believe users are authenticating when they visit the canonical domain?
  • Which layers can still change wallet-facing runtime behavior without a smart-contract deploy: registrar, DNS, CDN config, edge workers, HTML templates, remote scripts, tag manager, or runtime loaders?
  • Can you independently prove what HTML and JavaScript a real user would fetch from the canonical domain right now?
  • If the canonical domain were compromised, what safe fallback path would preserve user trust without asking them to improvise from social media?
  • Which third-party scripts or runtime services can still execute on wallet-critical pages, and what prevents them from changing signer-facing behavior?
  • What evidence would you require before telling users the site is safe again after a DNS or edge compromise?

Red flags that usually mean the domain trust boundary is underdesigned

  • The contracts are safe used as if that proves the site is safe to sign with.
  • The repo is clean used as if that proves the canonical domain served clean runtime bytes.
  • The domain still resolves treated as if registrar and DNS integrity are already proven.
  • Edge workers, tag managers, or HTML rewrite rules can change wallet-critical pages with weaker controls than contract admins or deploy keys.
  • The protocol relies on third-party runtime scripts on signing surfaces but cannot state exactly which ones are allowed and how their integrity is pinned.
  • Incident response can restore origin code but cannot verify what users are still receiving through DNS caches, CDN edges, or mobile-targeted branches.
  • There is no preplanned safe alternate domain, read-only mode, or fail-closed maintenance path for wallet-critical UX.

Failure-prevention checklist

  • Inventory the full wallet-facing delivery chain as one signer-adjacent security object: registrar account, nameservers, DNS provider, CDN, edge workers, HTML templates, script manifests, fallback domains, and any remote runtime dependency that can still shape transaction construction.
  • Keep wallet-critical routes as close to static and edge-passive as practical. If a worker, personalization rule, A/B harness, or HTML rewrite can change spender prompts or typed-data text, treat it like privileged application code instead of web-ops convenience.
  • Require separate, high-friction change control for DNS, registrar, CDN, and edge configuration on signer-facing domains. Faster to ship is not a reason to let weaker controls govern wallet prompts than govern contract deploys.
  • Sample the canonical domain from outside the trusted deployment path across multiple regions, resolvers, and device classes, and alert on unexpected HTML, script URLs, hashes, CSP drift, or wallet-flow differences.
  • Keep a preplanned safe fallback path ready: alternate domain, read-only mode, transaction disablement, or other fail-closed state that does not ask users to improvise trust from social posts during an incident.
  • Minimize and explicitly pin third-party runtime dependencies on wallet-critical pages. The domain has not fully authenticated its own runtime if it still allows wide mutable execution under the same origin.
  • Rehearse restoration at the browser-execution layer, not just at origin. Incident closure should require proof that real users now fetch the expected bytes through the real naming and CDN path.
  • Treat status communication as part of the control surface: users should know which fallback entrypoint is canonical during an incident and what evidence the team waits for before saying safe again.

Audit prompts

  • Which exact registrar, DNS, CDN, edge, template, and runtime surfaces can still change wallet-facing behavior on the canonical domain without a smart-contract deploy?
  • What would independently prove, right now, which HTML and JavaScript a real user browser receives from the canonical domain in multiple regions and on multiple device classes?
  • Can a DNS or CDN compromise be contained without asking users to trust screenshots or social-media replies to discover the safe entrypoint?
  • Do wallet-critical pages run under stricter delivery and script policy than the rest of the site, or does marketing / experimentation convenience still share the same signer surface?
  • Which edge or HTML rewrite systems can inject or swap wallet-facing code, and are those systems governed as tightly as other production signer-adjacent controls?
  • When the team says the site is safe again, what exact evidence supports that claim at the resolver, CDN, HTML, and browser-fetched-byte layers?
  • If the canonical domain became ambiguous for one hour, what user protections would still slow or block malicious approval prompts before funds moved?
  • Are alternate domains, read-only states, and maintenance flows documented ahead of time, or would the protocol be inventing its trust boundary mid-incident?

Lessons that should already be standard

  • The canonical domain is a custody-adjacent execution boundary, not a branding surface.
  • Contracts are safe does not mean the site is safe to sign with when the delivery path itself can author wallet prompts.
  • DNS, CDN, edge workers, and HTML templates deserve signer-level operational discipline whenever they can alter transaction construction.
  • Recovery is not proven at origin. It is proven when real users, through real resolution and caching paths, fetch the expected runtime again.
  • Safe fallback entrypoints should exist before the incident, because users will need a trustworthy path precisely when the main domain stops being trustworthy.
  • A protocol that cannot say what bytes the canonical domain should be serving right now does not yet have a well-defined browser trust boundary.

Where this note helps most

  • Start here when the sharper question is what should the real domain have proved before a user trusted the wallet prompt it served?
  • Use Badger as the clean same real site, different edge-served bytes exemplar and Curve as the clean same canonical name, different resolver-chosen delivery exemplar inside that broader browser-delivery family.
  • Drop into front-end compromise approval phishing when the exploit-side task is classifying real site, malicious prompt incidents.
  • Pair with third-party-runtime-allowance-and-integrity-pinning when the narrower browser-policy question becomes even if the domain is ours, what remote scripts or loaders should this signing surface have been allowed to execute at all, and how tightly were they pinned? Ledger Connect Kit and Polyfill are the clean adjacent cousins there.
  • Pair with release-provenance failure when the sharper question becomes how browser-fetched bytes drifted from reviewed or intended artifacts across loaders, tarballs, or runtime services.
  • Pair with exact production artifact attestation and rollback discipline when the broader recovery-side question is how to attest one full source-to-runtime lineage and prove rollback at the execution layer.
  • Pair with software supply-chain compromise when the decisive compromise first happened upstream in a shared dependency rather than in one protocol’s own delivery plane.

Internal linkages

Control surface

Graph View

Backlinks