Consent at the edge: the scripts your CDN and edge workers inject before the page loads
Consent tooling was built for a world where all the JavaScript arrived in the HTML the server sent. That world is ending. Edge middleware, CDN transformation rules, and server-side includes now inject scripts into pages at the network edge, after your origin responds and before the browser receives anything. Your consent wrapper runs in the page. The injection happens before the page exists.
This is not a theoretical gap. Personalization at the edge, A/B testing at the CDN layer, edge-side analytics, and bot management rules all modify responses in flight. When any of them inject a script tag, that script loads under the page's authority, fires its requests, and sets its cookies, all without passing through the consent logic that governs everything your own templates emit.
What edge injection looks like in practice
The common cases are easy to picture. An edge function adds an analytics snippet to every HTML response for funnel reporting. A CDN A/B testing product injects its experiment script at the edge so tests run before first paint. A personalization rule inserts a content-recommendation widget for certain visitor segments. A bot management layer injects a challenge script on suspicious requests. Each one is configured in a dashboard far from the codebase, by teams that may not know a consent program exists.
The injected markup is indistinguishable from first-party HTML by the time the browser parses it. There is no marker that says this script tag came from the edge. Your consent wrapper, which scans the DOM or intercepts known script patterns, sees just another script tag and applies whatever default policy it has, which is usually allow, because the script was not in its blocklist.
Why page-level gating cannot see it
Consent wrappers operate at the document level: they scan scripts in the page, intercept network requests from the page, and manage cookies the page can access. Edge-injected scripts enter below that level. By the time the wrapper's first scan runs, the injected script may have already executed, already fired its beacon, and already set its cookies. The wrapper is checking the doors after the delivery came through the loading dock.
Timing makes it worse. Edge injection often targets the earliest possible moment, sometimes before the consent banner's own script loads. The race is not close: infrastructure beats application code to the browser every time. Even a perfectly configured wrapper loses a race it does not know it is running.
The specific places to look
Audit the edge layer the same way you audit the page. That means the edge function and middleware code, CDN page rules and transformation rules, any HTML rewriting features, server-side includes, and the bot management configuration. Ask each platform team for a list of every response modification rule that touches HTML, and check each one for script injection.
Then verify from the outside. Fetch a page through the CDN and diff it against the origin response. Any script tag present in the CDN version and absent from the origin version is edge-injected, and each one needs a consent decision. Do this for the main page templates and for any segmented or personalized variants, since edge rules often apply conditionally and a single fetch may not trigger all of them.
How to gate what you find
Once inventoried, edge-injected scripts need gating at the edge, not in the page. The practical options: make the injection conditional on the consent state, which the edge can read from the consent cookie on the request; move the injection decision into the page where the wrapper can govern it; or classify the script as strictly necessary with a written justification, which is only valid for a narrow set of genuinely essential functions.
Reading the consent cookie at the edge is the cleanest pattern. The edge function checks for the consent state before injecting, and skips injection when the relevant category is not granted. This keeps the performance benefit of edge injection while respecting the visitor's choice. Whatever pattern you choose, it must be re-verified on the same schedule as page-level consent, because edge rules change through dashboards, and dashboard changes do not go through code review.
The bottom line
The consent perimeter has to move to where the scripts actually enter, and increasingly that is the edge, not the page. Inventory the edge injections, gate them on consent state at the edge, and verify with an origin-versus-CDN diff. The wrapper in the page is still necessary. It is just no longer sufficient.