Skip to main content
drupalreleases

Use direct release data with your AI assistant.

Learn more

Consent Audit

Security covered Under active development 1 sites

This module audits your Drupal site to check if it's contacting third parties or setting cookies before a visitor gives consent or after they've refused it. It acts as a diagnostic tool, reporting on which third parties are contacted and which cookies are set, helping you identify failures in your consent management system. The module records findings for each visitor, providing detailed reports that show the origin of any leaks without storing personally identifiable information.

Consent Audit checks whether your cookie consent manager blocks what it should. While a visitor has not decided on consent, or has refused it, a small script in the page records every request to another site and every new cookie, and the report names the library, Asset Injector asset or markup that caused each one. It runs on your own pages, with your own trackers, and blocks nothing: it shows where the blocking fails.

Features

  • ๐Ÿ“Š Every leak, with its cause. Each finding names the host or the cookie, the script that made the request or set the cookie, and what that script belongs to: a library of an installed module, an Asset Injector asset, one of core's aggregated files, or markup in the page. Repeated findings add to one row's count, so the table grows with the kinds of leaks a site has, not with its traffic.
  • ๐Ÿ›ก๏ธ Undecided and refused, told apart. A finding records the phase the visitor was in when it happened. Visitors who accepted contribute nothing, and auditing visitors who refused can be turned off.
  • โš™๏ธ Act from the report. Filter by attribution, kind and phase. Allow this host adds a host the site depends on, such as a payment provider or a CDN, to the first-party hosts and removes its finding. Delete one finding or all of them, and recompute the attribution after installing a module.
  • ๐Ÿ“ˆ How many visitors decide, and what. Optional, off by default: per day, how many page views arrived undecided, having accepted or having refused, and how many of the undecided ones ended in accepting all, accepting in part or refusing. The report shows the decision rate and the acceptance rate per day, and every counter can be exported through Views. Only the date and the outcome are stored.
  • ๐Ÿ“Š A status report entry. Reports > Status report shows an error while anything was found in the last seven days, and a warning when no consent source is enabled or collection is paused.
  • ๐Ÿงฉ Klaro! sub-module. Reads the decision from Klaro. Services Klaro marks as required are left out, because declining grants them consent, and the status report says when every service is required or on by default, in which case a refusal cannot be observed.
  • ๐Ÿงฉ EU Cookie Compliance sub-module. Reads the decision from EU Cookie Compliance, in categories mode too, and warns on the status report for the two configurations in which a refusal cannot be observed.
  • ๐Ÿงฉ COOKiES sub-module. Reads the decision from the cookiesjsr cookie that COOKiES writes.
  • ๐Ÿ”Œ Any other consent manager. Drupal.consentAudit.registerSource() takes a state() function answering undecided, accepted or refused, and an optional change callback. With several managers on one page, the visitor counts as accepted only when all of them say so.

Quick start

composer require drupal/consent_audit
drush en consent_audit consent_audit_klaro
  1. Enable the sub-module for the consent manager the site runs: Consent Audit: Klaro!, Consent Audit: EU Cookie Compliance or Consent Audit: COOKiES.
  2. Go to Configuration > System > Consent audit and list under First-party hosts any other domain the site depends on, one per line. Click Save configuration.
  3. Open the site in a private window, leave the consent notice unanswered and browse a few pages.
  4. Go to Reports > Consent audit: each row is a request or a cookie made before consent, with the script that caused it.

The status report entry while something is leaking.

Good to know

  • It is a diagnostic. Every finding still needs a change elsewhere: in the tracker's loading condition, in the consent manager's configuration, or in the module or theme that adds the tracker.
  • Nothing about the visitor is stored: no IP address, user agent, identifier, cookie value or query string. A request is stored as its host and a cookie as its name, with the page path and the script responsible, which is a full URL when that script is on another site. The module sets no cookie and uses no browser storage.
  • Findings not seen again within 90 days, a setting, are deleted on cron, and so are daily counts older than that.
  • With the daily counts on, every page view sends one small request to /consent-audit/tally, and one more if the visitor decides on that page. Administration pages and browsers that identify as crawlers are not counted. The counts are page views, not visitors: nothing tells one visitor from another.
  • The observer is the same on every page and for every visitor, so pages stay in the page caches.
  • The browser reports its findings to /consent-audit/report, which accepts anonymous posts from the site's own pages only, with a per-site token, a size limit and a rate limit per IP address.
  • With JavaScript aggregation on, a finding from an aggregated file is attributed to every library in it that has a script. Turning aggregation off pins it to one.
  • Requests made inside a frame from another site and HttpOnly cookies cannot be seen from the page, so they are not reported.
  • A consent manager is read as a whole: the first acceptance ends the audit for that page, even where the manager separates analytics from marketing.
  • The report and the settings have separate permissions, View consent audit report and Administer consent audit. The row actions and the buttons need the second.

Additional requirements

Recommended modules/libraries

Community documentation

  • README: what is stored, the report and its attribution, the consent decisions table, the status report, every setting, registering another consent manager and the limitations.
  • The READMEs of the Klaro!, EU Cookie Compliance and COOKiES sub-modules: how each reads its manager's decision, checked against that manager's code.

Supporting this module

Developed and maintained by Bloomidea. Bloomidea offers support and custom development for this module.

Drupal 10โ€“11

Ask your assistant about Consent Audit

Check compatibility with your Drupal and PHP version, maintenance and security coverage, from current release data. How it works

Depends on

Dependencies of the latest stable release

  • views Drupal core

Required by

Tracked projects that depend on this one

No tracked projects depend on this one yet.

Activity

Tracked releases
3
Tracked since
Sep 2026
Latest release
3 weeks ago
Releases (12 mo)
3 ▲ from 0
Maintenance
Active

Release Timeline

Releases

Version Type Core PHP Release date
1.1.0 Stable 10โ€“11 Oct 8, 2026
1.0.0 Stable 10โ€“11 Sep 28, 2026
1.0.0-beta1 Pre-release 10โ€“11 Sep 16, 2026