Laravel Cookie Guard Laravel Package

Product Decisions This Supports

• Keeping consent in-house vs. buying a CMP. v5.1.0 materially improves the package’s fitness as a first-party consent mechanism: server-validated consent payloads, config-driven consent lifetime, cookie erasure on rejection/withdrawal, and consent written only after server confirmation. These are the behaviours a PM needs before treating the package as the system of record for cookie consent.
• Security remediation, not just feature work. The missing web middleware on POST /guard-settings/save meant the CSRF token sent by the JavaScript was never checked since the first release. This is a real vulnerability in a state-changing consent endpoint. Upgrading is a risk-reduction decision, not a nice-to-have.
• Roadmap: consent correctness and auditability. The release aligns browser behaviour with documented config (cookie_lifetime, including session-only consent at 0), fixes use_separate_page so optional categories are actually stored as accepted, and makes “Reject optional” respect every required category. That improves the accuracy of the consent record you may need to rely on.
• SPA / modern Laravel stack support. Sending XSRF-TOKEN as X-XSRF-TOKEN and adding data-csrf-token fallbacks makes the package usable on Inertia, Livewire, and Turbo pages that never fully reload. This widens the set of products where the package is a viable default.
• Build vs. buy boundary. For a standard Laravel app with category-based consent, this is a credible “buy vs. build” avoidance: it removes custom consent-banner maintenance. If you need IAB TCF strings, Google Consent Mode integrations, or legal-template depth, those remain buy-side decisions.
• Maintenance and confidence signal. Test coverage moved from 45 to 60 Pest tests and from 22 to 51 JavaScript tests with 100% line coverage of the bundle. That supports keeping the dependency and planning smaller, regular upgrades rather than a later rewrite.
• Upgrade as a product task, not a composer-only task. Re-publishing assets is required; published Blade components need the new root attributes (data-cookie-lifetime, data-cookie-categories, data-required-categories, data-csrf-token), otherwise erasure does nothing and lifetime falls back to 365 days. Swedish apps using locale se must move to sv. Published translations must move to lang/vendor/cookies_consent/{locale}/messages.php; the old path is read with a log warning until v6. These are migration items that should be scheduled and verified.

When to Consider This Package

Consider it when:

• You run a Laravel application that needs a cookie consent banner with configurable categories, required categories, and consent persistence.
• You want a first-party consent UI rather than adding a third-party CMP, and your requirements are category-based consent, cookie erasure on rejection, translation overrides, and a separate consent page option.
• You are on a Blade, Inertia, Livewire, or Turbo front end and need CSRF-safe consent saving without a full page reload.
• You can own the upgrade mechanics: re-publish public assets, maintain overridden Blade components against the documented data attributes, and keep translation overrides in the new lang/vendor/cookies_consent/ path.
• You need the package’s behaviour to match its documentation closely enough that consent lifetime and rejection/erasure behaviour can be defended in a privacy review.

Look elsewhere when:

• You need IAB TCF v2.2 consent strings, Google Consent Mode v2 out of the box, or a vendor-provided compliance dashboard and legal indemnity.
• You need consent orchestration across multiple frameworks or non-Laravel services, not just a Laravel package.
• You have heavily customised published Blade components and cannot absorb the new required root attributes; the fallback behaviour in v5.1.0 is less safe than the documented behaviour.
• You are unwilling to re-publish assets and audit any of your own code that posts directly to /guard-settings/save; this release requires that work.
• Your product is multilingual in ways that depend on the removed enabled config or the old lang/se Swedish locale path and you cannot make the corresponding config and locale changes.

How to Pitch It (Stakeholders)

For executives: v5.1.0 is a minor release with a security fix and meaningful consent-correctness improvements. The package’s consent-save endpoint was previously missing CSRF protection; this release fixes that and should be taken. It also makes the banner honour the configured consent lifetime, erases rejected cookies as documented, and fixes the separate-page consent flow where optional categories were not being stored as accepted. There is no new vendor cost and no replacement of the consent approach. The upgrade requires re-publishing assets and a short configuration/translation check, so it should be scheduled as a small maintenance release rather than treated as a drop-in composer update. From a risk perspective, the CSRF fix and the more reliable consent record are the reasons to prioritise it.

For engineering: Minor release, no breaking changes to Blade components, routes, or config keys, but there are operational upgrade steps: re-publish cookies-consent-public; re-publish or patch published components with the new data-* attributes; move translation overrides to lang/vendor/cookies_consent/{locale}/messages.php; change locale se to sv if used; remove reliance on the removed enabled config; and send a CSRF token if your own code posts to /guard-settings/save. The old translation path still works with a log warning until v6. Test coverage is substantially improved, including 100% line coverage of the JavaScript bundle.

For product/legal reviewers: The release closes gaps between documented and actual behaviour: consent lifetime now follows cookie_lifetime (0 means session-only), rejected categories erase declared cookies on the host and parent domains down to the registrable domain, and the banner stays open until the server confirms the save. The consent payload is validated server-side: one boolean per configured category plus locale; unknown keys are dropped; non-booleans return 422; required categories are always stored as accepted. The main caveats are migration-related, not conceptual: published component overrides must be updated to get erasure and lifetime behaviour, and the Swedish locale identifier changed from se to sv.