Laravel Gtag Laravel Package

Product Decisions This Supports

• Security & compliance roadmap: This release removes the single biggest blocker to shipping a strict Content-Security-Policy. Teams that previously had to allow 'unsafe-inline' for this package's inline scripts can now use a nonce-based policy, which is the difference between "CSP deployed on paper" and "CSP that satisfies a pen test, SOC 2 reviewer, or enterprise security questionnaire."
• Build vs. buy: The alternative is hand-rolling nonce propagation into every inline script your app emits — ongoing maintenance, easy to regress on a new feature, and a recurring audit finding. The package absorbing this is a strong argument for buying/adopting rather than building.
• Feature prioritization: Treat "works under a strict CSP" as a check-box requirement for any script-injection surface in the product (analytics snippets, JSON-LD, feature-flag bootstrapping, per-page config hydration). This release closes that gap, so it can be marked done in the security workstream rather than tracked as bespoke engineering work.
• Delivery sequencing: Because nonce support is opt-in and inert without a nonce, you can ship the dependency upgrade independently and ahead of the CSP rollout. That decouples two risky changes — a nice de-risking story for the release plan.
• Enterprise / regulated sales enablement: Nonce-based CSP is frequently a hard requirement in security reviews for SaaS buyers. This becomes a demonstrable capability in the security appendix rather than an exception to explain away.

When to Consider This Package

Adopt when:

• The app renders inline scripts (or scripts the framework must coordinate) and you intend to enforce a CSP — now or within the next couple of quarters.
• You already run (or plan to run) a CSP/security-headers layer that issues a nonce, e.g. laravel-security-headers 2.1+ with Vite::cspNonce(). The value here is entirely dependent on a nonce actually being set; the two are a package deal and should be evaluated together.
• Your threat model or compliance regime penalizes 'unsafe-inline' — anything customer-facing with an external security review.
• You want the nonce behavior handled by the library rather than re-implemented per script call site.

Look elsewhere (or defer) when:

• You have no CSP ambition and no inline script surface — the v3.1.0 change is a no-op for you and shouldn't drive adoption.
• Your CSP strategy is hash-based rather than nonce-based; confirm fit before assuming compatibility.
• Your nonce is produced by a bespoke middleware that doesn't populate Vite::cspNonce() — verify the integration point or you'll buy the feature and not get the benefit.
• You're on a version pinned below 3.x and the upgrade cost (major-version surface) outweighs a security-only win; stage it with your next planned upgrade instead.

How to Pitch It (Stakeholders)

To executives: A small upgrade that unlocks a meaningful security posture improvement — we can enforce a strict Content-Security-Policy without weakening it with 'unsafe-inline'. That's a recurring finding in customer security reviews and a common procurement gate; closing it reduces sales friction and audit exposure at essentially zero product risk, since behavior is unchanged for apps that don't set a nonce.

To engineering: v3.1.0 propagates the CSP nonce (Vite::cspNonce()) onto the scripts this package emits, so a nonce-based policy validates them without an inline-script exemption. No migration, no behavior change when no nonce is present. The only real work is confirming our nonce source feeds Vite::cspNonce() — if it does, this is a version bump plus a CSP header change, and we can ship the bump well before the policy tightening.