Laravel Cookies Consent Laravel Package

Product Decisions This Supports

• Build vs. buy for consent management. A maintained, MIT-licensed Laravel package with Blade components, configurable categories, and server-confirmed consent storage removes a two-to-four week build from the roadmap. Treat "buy" here as "adopt and own the published surface," not "add a dependency."
• Compliance-driven feature work. v5.1.0 makes consent behavior match its documentation: CSRF-protected save route, validated payload (one boolean per configured category, unknown keys dropped, required always stored as accepted), cookie_lifetime actually governing the stored cookie, and cookie erasure on reject/withdraw across parent domains. This is the release that makes the package defensible in a GDPR/ePrivacy review rather than merely present on the page.
• Roadmap sequencing for consent-adjacent features. Because the package now enforces required categories, per-category erasure, and server-confirmed state, features that depend on consent state (analytics gating, marketing pixels, regional banners, preference centers) can be scoped against a stable contract instead of a best-effort client-side flag.
• Regional and localization rollout. Translations now publish to lang/vendor/cookies_consent/ with per-key merging, so we can ship only the strings we override and still inherit upstream fixes. Multi-locale launches stop being a fork-and-maintain exercise.
• SPA/Inertia/Livewire architecture choices. The X-XSRF-TOKEN cookie path plus data-csrf-token fallback means consent works on pages that never reload, and use_separate_page mode is now functional (it previously posted an empty selection, silently failing to store optional categories as accepted). Teams can choose the separate-page consent flow without a custom workaround.
• Accessibility and UX quality bar. Single-press floating button activation and hash-link behavior (#consent-settings opens rather than toggles) are small but real signals that the package is being exercised against actual user journeys — useful when deciding whether to accept its UX as-is or budget design work.
• Test coverage as a procurement input. 60 Pest tests and 51 JS tests at 100% line coverage on the bundle, plus CI on PRs to any branch, is the kind of evidence that shortens internal security/quality review.

When to Consider This Package

Consider adopting when:

• The product is Laravel/PHP and consent needs are the standard shape: a banner, a settings view, per-category opt-in, required/strictly-necessary categories, and a stored consent record.
• We need per-category cookie erasure on rejection or withdrawal — v5.1.0 handles host and parent domains down to the registrable domain, and never touches required categories. That is tedious to build correctly and easy to get wrong.
• Consent lifetime must be a policy decision rather than a hardcoded constant. cookie_lifetime now genuinely controls the stored cookie, including 0 for session-only consent.
• We serve multiple locales and want to override a handful of strings without forking the package.
• We use Inertia, Livewire, or Turbo, or otherwise have long-lived pages where a stale CSRF token would break the save.
• We want an MIT-licensed, self-hosted solution with no vendor data processor to add to the DPA and subprocessor list.

Look elsewhere or build custom when:

• Consent must be a system of record with audit trails, consent receipts, versioned policy text, and per-user history. This package stores browser-side consent; it is not a compliance archive.
• We need server-side consent enforcement tied to authenticated users, CRM sync, or downstream activation (tag managers, CDPs, warehouse events). That is integration work this package does not do.
• The product is not Laravel, or the front end is a decoupled app that cannot consume Blade components.
• We cannot accept a publish-and-own upgrade model. The v5.1.0 upgrade requires re-publishing public assets, and — if Blade components were published — either re-publishing them or manually adding four new root attributes (data-cookie-lifetime, data-cookie-categories, data-required-categories, data-csrf-token). With stale markup, erasure silently does nothing and lifetime falls back to 365 days. Silent degradation on missed upgrade steps is the main ongoing cost.
• We have already published and heavily customized the Blade views; each release becomes a three-way merge we own.
• Regulatory scope demands features not present here (IAB TCF strings, age gating, jurisdiction detection).

Adoption preconditions worth stating explicitly:

• Any of our own code posting to /guard-settings/save must send the CSRF token — this route previously had no middleware, so custom integrations may be silently relying on the unprotected behavior.
• Locale se must move to sv if used.
• The enabled config option is gone; audit config files for it.
• Published translations must move to lang/vendor/cookies_consent/{locale}/messages.php; the old lang/vendor/scify/laravel-cookie-guard/ path still works but logs a warning and is slated for removal in v6.

How to Pitch It (Stakeholders)

To executives: We can close a genuine compliance gap without building a consent system. The current minor release fixes a save endpoint that had no CSRF protection since the first release and a separate-page flow that silently failed to record opt-ins — the kind of defect that shows up in an audit, not in a demo. It is MIT-licensed and self-hosted, so there is no new vendor, no procurement cycle, and no data processor to add to our agreements. Cost is adoption plus a defined upgrade cadence, not a license.

To engineering leadership: v5.1.0 is a behavior-alignment release with no breaking changes to Blade components, routes, or config keys, but the upgrade is not free: re-publish public assets, and if views were published, either re-publish or add four new data attributes. Miss that and erasure quietly no-ops and lifetime reverts to 365 days — silent, not loud. Budget a half-day and a manual verification pass on the reject-and-withdraw path. The payoff is a package that now validates its consent payload server-side, writes the consent cookie with SameSite=Lax and Secure on HTTPS, respects cookie_lifetime (including session-only at 0), and ships 60 Pest and 51 JS tests at 100% line coverage on the bundle. That is a materially better baseline than the version it replaces.

To security and legal reviewers: The save route now runs in the web middleware group and checks the token the JavaScript already sends; a same-origin request on Laravel 13 is also accepted without one. The payload is validated against configured categories — unknown keys dropped, non-booleans rejected with 422, required categories always stored as accepted — so the server no longer trusts client-supplied structure. Rejecting or withdrawing erases the declared cookies on the host and parent domains, never touching required categories. Note the deliberate trade-off: consent is stored in a browser cookie, not a server-side audit log; if review requires receipts or per-user history, that is a scoping decision to make now, before we build on top of this.

To product and design: Users get a banner that only closes when the server confirms the save, a settings link that opens rather than dismisses for first-time visitors, and a floating button that responds to a single Enter press. Consent lifetime now means what the copy says. Translations merge per key, so we can correct a string in one locale without carrying the whole file — worth knowing when legal asks for wording changes late in a launch.