Filament Csp Nonce Laravel Package

Product Decisions This Supports

• Build vs buy on security headers. Nonce plumbing, error-view rewriting, and Reporting API endpoint management are small but edge-case-dense. This package removes roughly 2–4 weeks of build plus an ongoing tail of browser-quirk maintenance from a "CSP enforcement" epic.
• Roadmap: CSP enforcement without unsafe-inline. The package's core value is injecting a per-request nonce and rewriting inline <script>/<style> so script-src 'nonce-…' can be enforced. That is the prerequisite that clears most security-review, pen-test, and compliance-questionnaire findings around missing or permissive CSP.
• Roadmap: violation observability. Because the release notes describe a Reporting API batch (20 entries), a report body cap, report-uri, report-to, and Reporting-Endpoints, this package is a reporting producer, not just a header setter. That makes "collect and dashboard CSP violations" a shippable follow-on epic rather than a separate integration project.
• Admin surface quality (Filament). Panel 403/404/419/500 pages now keep their inline styles under the nonce policy. Previously an expired session or a permission denial would render an unstyled page — a visible quality regression that generates support tickets and erodes trust in the admin surface. This is now a non-issue.
• Vendor choice for reporting. A user-defined report-to group is no longer overwritten, and null keeps report-uri/report-to removed. This means you can point reporting at Sentry, an internal collector, or a commercial CSP reporter without forking — a real build-vs-buy lever on the observability side.
• Deployment topology. report-uri and Reporting-Endpoints now include the app base path, which unblocks path-prefixed/subdirectory deployments. If your roadmap includes multi-tenant or path-segmented Laravel installs, this was previously a blocker for trustworthy reporting.
• Data-quality caveat worth flagging in your metrics plan. In v1.0.0, a full 20-entry batch exceeded a 16 KB cap and was dropped whole with a 204 — i.e., silent zeroing of violation telemetry. Any dashboard or alerting built on 1.0.0 would have shown false "all clear." Budget a re-baseline of violation volume after upgrading.
• Do not commit to v1.0.0 anywhere. v1.0.1 is a patch release, but it fixes three production-severity behaviors (unstyled error pages, silently discarded reports, broken reporting on subdirectory installs) plus a nonce-detection false positive. Standardize on ^1.0.1.

When to Consider This Package

Adopt when most of the following hold:

• You serve Blade-rendered HTML with inline scripts/styles and want nonce-based CSP without unsafe-inline. This is the sweet spot; the package's nonce injection and attribute rewriting assume server-rendered markup.
• You run Filament (or Livewire/Alpine panels) and need panel pages and error pages to stay styled while a nonce policy is enforced.
• You want violation reporting, not just headers — you have (or plan) a collector endpoint and someone who will read the data.
• You deploy under a subdirectory / path prefix, or you plan to.
• You need to keep a user-defined report-to group or deliberately disable reporting via null; both are now respected.
• A patch-level upgrade path is acceptable to your release process. The upgrade from 1.0.0 is composer update with no API changes.

Look elsewhere — or plan to configure around it — when:

• Your front end is a detached SPA/SSR app not rendered by Blade. Nonce injection buys you little; set CSP at the edge/CDN or in the JS framework's build pipeline instead.
• You terminate security headers at a CDN or reverse proxy (Cloudflare, Fastly, nginx) and want the policy owned there. Two sources of truth for CSP is a debugging trap; pick one.
• You need hash-based CSP generated from a build pipeline or heavy strict-dynamic configurations — a Blade nonce injector is the wrong tool.
• You need report analysis, aggregation, and alerting. This package emits reports; it does not interpret them. Pair it with a collector or choose a reporting product instead.
• You rely on custom resources/views/errors pages and want them untouched. Error views are now rewritten by default — verify your custom error pages survive, and confirm the opt-out if not.
• You need the framework debug exception page to be styled inside a panel. The release notes explicitly document that it is blocked inside a panel; treat it as a known limitation, not a bug to be fixed on your timeline.
• Verify first: PHP and Laravel version constraints in composer.json, and whether your CSP needs exceed what the package's config surface exposes. We have no dependency metadata in hand for this review.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, single-purpose dependency that closes a recurring security finding — our Content Security Policy is currently permissive or absent — and, unlike a hand-rolled header, it also produces the violation telemetry we need to prove the policy is working. The release under review, v1.0.1, is a patch release with no API changes: a composer update, no migration, no feature work. It is nonetheless the first version I would ship, because it fixes three issues in v1.0.0 that would have surfaced as production incidents — unstyled 403/404/419/500 pages in the admin panel, CSP violation batches silently discarded instead of reported, and reporting endpoints generated incorrectly for subdirectory installs. Recommendation: adopt, run in report-only for one week in staging, then enforce.

For engineering (the honest tradeoffs):

• Upgrade risk: low. Semver patch, no signature changes. Do not deploy 1.0.0; pin ^1.0.1.
• One intentional behavior change: views under resources/views/errors are now rewritten by default. If we have custom error templates with their own inline styles, confirm they render correctly or opt out. This is the only item that can affect us without a code change.
• One correctness fix that changes runtime behavior for the better: a Blade echo inside another attribute's value (src="{{ asset('nonce.js') }}") previously counted as an existing nonce, so those scripts were treated as already-sanctioned and then blocked. Nonce detection is now accurate — expect fewer "mystery blocked script" reports, and expect our violation counts to change on upgrade (they were previously undercounted in two independent ways).
• Reporting config is now respected: user-defined report-to groups survive, and null keeps report-uri/report-to removed. Our endpoint choice is no longer fighting the package.
• Base-path handling is fixed, so subdirectory deploys report to a resolvable URL.
• Known limitation, documented, not fixed: the debug exception page is blocked inside a Filament panel. Accept it; don't file it.
• Integration gotchas from the docs: published Filament view overrides need blade.paths; Filament's ->font() pulls Bunny Fonts, so font-src must allow it or typography will silently fall back.

Ask: approve the dependency, standardize on ^1.0.1, and schedule one staging week in report-only mode before flipping to enforcement. Budget a short task to re-baseline violation metrics post-upgrade, since the previous numbers were not trustworthy.