Laravel Goatcounter Laravel Package

Product Decisions This Supports

• Unblocks a strict CSP rollout. If your roadmap includes removing 'unsafe-inline' from script-src (a common requirement for SOC 2, pen-test remediation, or enterprise security questionnaires), this release removes a concrete blocker. You can now adopt the package and nonce-based CSP in the same quarter instead of sequencing them.
• Build vs. buy on security plumbing. The alternative is hand-rolling nonce injection into every place your app emits a <script> tag — an easy thing to get 95% right and then regress. If this package is already in the stack, nonce support is a reason to keep it rather than replace it with bespoke code.
• Enterprise / regulated-segment readiness. Nonce-based script-src is a standard line item in vendor security reviews and procurement gates. This is a "we can now sell into that segment without an exception request" decision, not just an engineering nicety.
• Compliance debt burndown. If there's an open finding or risk-register item about inline scripts, this release can close it without a dedicated sprint of work — a cheap trade against the backlog.
• Release/rollout sequencing. Because the change is additive (nonce only applied when the app sets one), it can ship on the normal release cadence with no coordinated cutover with the security-headers work.

When to Consider This Package

Adopt when:

• You render <script> tags server-side via this package and expect to run a nonce-based script-src policy — with Laravel's Vite nonce or a headers package like laravel-security-headers.
• Your CSP direction is nonces rather than hashes. Hash-based CSP does not benefit from this change.
• You are in a segment where CSP strictness is a sales or audit gate, and the cost of a bespoke solution exceeds the cost of a dependency.
• You already depend on the package for its rendering behaviour — the addition is low-risk and backwards compatible.

Look elsewhere or defer when:

• You have no CSP ambitions in the next 12–18 months; the benefit is real but not yet actionable, and the upgrade is not urgent.
• Your app's scripts are fully bundled by Vite with no server-emitted inline scripts — the surface area this touches may be zero for you.
• You use hash-based CSP, or a third-party tag manager that injects scripts outside this package's control — the nonce won't cover those paths, and adopting this may create a false sense of coverage.
• You need a formal guarantee (contractual SLA, security certification) rather than a code-level feature; verify the maintainer's support posture before making it a dependency of a compliance control.

Verify before committing: that the nonce is applied to every script path the package emits (not just the common one), and that behaviour is unchanged when no nonce is configured.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk upgrade to a dependency we already use that removes a known obstacle to tightening our browser security policy. Practically, it means we can tell enterprise customers and auditors that our script policy no longer relies on 'unsafe-inline' — a common procurement and security-review question — without funding a separate engineering project. No migration cost, no breaking change, no customer-visible behaviour change today.

To engineering: The package now propagates Laravel's Vite CSP nonce onto the <script> tags it renders whenever the app sets one (e.g. via laravel-security-headers). If no nonce is configured, behaviour is identical to before — it is purely additive. Upgrade on the normal cadence, then confirm nonce coverage across all script emission points and re-run your CSP report-only pass before enforcing.