Laravel Clarity Laravel Package

Product Decisions This Supports

• Unblocks a security-gated segment. The headline change — every rendered <script> now inherits Laravel's Vite CSP nonce, so nonce-based script-src policies work without 'unsafe-inline' — turns a common enterprise/regulated procurement objection into a supported configuration. This is an adoption enabler, not a nice-to-have.
• Build vs. buy tilts toward buy. Keeping script injection compatible with Laravel's Vite nonce pipeline and laravel-security-headers is fiddly, security-sensitive plumbing that must be re-validated on every Laravel/Vite upgrade. Paying for (or standardizing on) a package that owns this is cheaper than maintaining a bespoke wrapper plus CSP regression tests.
• Roadmap signal: CSP compliance is now a first-class capability. Treat it as a supported integration surface going forward — document the compatibility matrix (nonce present / absent, laravel-security-headers on/off, hash- vs. nonce-based policies), and add automated tests that assert the nonce attribute is present when a nonce exists and absent (not empty/broken) when it doesn't.
• Use cases unlocked: embedded third-party widgets, chat/support embeds, analytics and tag-manager snippets, consent-gated scripts, and any tenant-configurable script injection in multi-tenant apps where a strict CSP is enforced centrally.
• Release posture: 1.1.0 is a minor, additive release. It is a low-risk upgrade path for existing adopters and a credible "yes" answer in security questionnaires.

When to Consider This Package

Adopt when:

• Your app enforces (or plans to enforce) a nonce-based script-src policy without 'unsafe-inline' — typically via Laravel's Vite nonce or laravel-security-headers.
• You already use this package to render scripts, and today you are either patching outputs, allowlisting inline scripts, or accepting CSP violations.
• You want vendor-maintained nonce handling rather than a custom wrapper that breaks silently on framework upgrades.
• Your buyers or auditors require CSP evidence as a release gate (enterprise, fintech, health, public sector, multi-tenant SaaS).

Look elsewhere or defer when:

• You have no CSP, or use host-allowlist/hash-only policies — the feature is harmless but delivers no incremental value, so it's not a reason to adopt on its own.
• You need nonce coverage beyond scripts (styles, iframes, preload links) or attributes this release doesn't claim, such as SRI integrity, async/defer, or dynamic client-side injection.
• You would rather ship scripts through a first-party Vite entry point and avoid third-party script rendering entirely.
• Verify scope before committing: confirm the nonce is applied to all script emission paths the package exposes (including any conditionally or dynamically rendered tags), and test in a browser with a strict policy in report-only mode first. If coverage is partial, treat 1.1.0 as progress rather than a completed capability.

How to Pitch It (Stakeholders)

For executives: Version 1.1.0 closes a security-review gap that has historically stalled deals with customers who enforce strict browser security policies. Scripts this package renders now automatically carry the app's security nonce, which means those customers can adopt us without weakening their policy with 'unsafe-inline'. It is a minor, backward-compatible upgrade — no migration cost — and it broadens the addressable market into enterprise and regulated accounts.

For engineering: The package now reads the framework's Vite CSP nonce and stamps it onto every <script> it renders, interoperating cleanly with laravel-security-headers. Upgrade is additive and low risk. Recommended follow-ups: add a regression test asserting nonce presence when configured and correct omission when not, document the supported CSP configurations, and smoke-test under a report-only policy before flipping to enforce.