The consent-gated stack: reading what the CMP config hides

The scanner reads the publicly served Borlabs config and decodes its opt-in codes: container IDs and custom loaders that only load after consent become visible, no click needed.

What gets tested

Borlabs Cookie 3 stores an opt-in code for each service in a publicly served config file, base64-encoded. The scanner reads that file and decodes the codes. What becomes visible is everything that loads only after consent: GTM containers, GA4 properties and custom-loader hosts, even when the page HTML shows none of it. No click, no browser.

Why it matters

A cleanly blocking CMP makes the tag stack invisible to static scans. That is deliberate and correct. It also blinds the site owner: whatever sits in the config was entered at some point, and nobody re-checks it. This finding surfaces the stored stack so you can compare it against the setup you actually want. Orphaned containers otherwise keep loading for years, on every opt-in.

Common causes

Test containers or second properties from the setup phase that were never removed.
After an agency change, the old loader stayed in the config.
A server-side loader on your own subdomain that the team simply forgot sits behind the CMP.

The fix

Hold the listed IDs and loader hosts against the intended setup. Remove every ID nobody can attribute, then click through the opt-in flow once. For a custom loader on your own subdomain, also check whether the server container behind it is still maintained.

Matching template

CMP and GTM Consent QA Template

The repeatable test plan for default-denied, consent update and reject, across all four signals.

Get the QA template →

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →

Asked often

What does the "consent-gated stack" finding mean?

Your CMP blocks tags correctly until consent, so a static look at the HTML shows none of them. The CMP config itself is publicly served, though, and carries the opt-in codes. The scanner decodes them and lists what loads after opt-in: container IDs and loader hosts. The finding is a note, not a judgement.

Is it a problem that the config is publicly readable?

No. Every client-side CMP works this way, the browser needs to know which scripts to run after consent. What matters is something else: you should know what is stored there too.

Why do IDs show up that I do not recognise?

Typical candidates are test containers from the setup phase, properties left behind by a previous agency, or a loader on a subdomain nobody maintains anymore. Every unknown ID in the config is a cleanup candidate.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.

To the service Request an Audit Sprint