Laravel Csp Laravel Package

Product Decisions This Supports

• Security roadmap prioritization. CSP is a discrete, scopeable work item that materially reduces the blast radius of third-party JavaScript supply-chain attacks (credential/keylogging injection via npm dependency or tag manager). This package lets you ship a defensible CSP milestone without building header-generation, nonce injection, or policy plumbing in-house.
• Compliance and procurement responses. SOC 2, PCI DSS 4.0 (req. 6.4.3 / 11.6.1), and enterprise security questionnaires increasingly ask about CSP. Adopting this package converts an open questionnaire item into a shipped control with a config file as evidence.
• Build vs. buy. The "build" alternative is a custom middleware plus nonce generator plus Blade directives plus report-only switching plus a preset library for ~40 third-party vendors. That is weeks of engineering plus permanent ownership. This is MIT-licensed, one composer require, one global middleware line — near-zero build cost and a small, well-bounded config surface.
• Rollout strategy / risk-managed launch. The report_only_presets and separate report_only_uri config means you can ship policy in observe-only mode, collect violations, then enforce — a phased rollout you can put on a roadmap with a clear graduation criterion rather than a big-bang flag day.
• Third-party integration onboarding. The preset catalog (Stripe, HubSpot, Intercom, Sentry, Google Analytics/Tag Manager, Cloudflare Turnstile, PostHog, etc.) turns "will this vendor break our site?" into a config lookup. This shortens the time-to-ship for marketing/sales/support tooling decisions and gives PMs a concrete checklist item for vendor evaluation.
• Feature/route-level scoping. Middleware can be applied globally or per route/group with a preset override — supports differentiated decisions, e.g. strict policy on authenticated app surfaces, looser policy on marketing pages with heavy tag-manager usage.
• Deployment/environment control. CSP_ENABLED and enabled_while_hot_reloading let you keep local DX intact while enforcing in production — avoids the classic "security feature that engineers disable locally and forget to verify."
• Nonce decision, explicitly. nonce_enabled makes the inline-script tradeoff (nonces vs. unsafe-inline) an explicit, documented product decision rather than an accident.

When to Consider This Package

Adopt when:

• You run a Laravel app rendering HTML server-side (Blade + Vite are the happy path), and responses pass through Laravel middleware.
• You have external JavaScript: analytics, tag managers, chat widgets, payment elements, captcha, session replay. This is where CSP earns its keep.
• You have a compliance driver or enterprise customer asking about CSP, XSS mitigation, or script governance.
• You want incremental adoption: report-only first, enforce later, per environment.
• You already lean on Spatie packages — consistent conventions, familiar maintenance model, MIT license, active releases and changelog.

Look elsewhere or defer when:

• API-only or SPA-behind-CDN architecture. If HTML is served by a static host, edge worker, or Next.js/Inertia front end outside Laravel's response cycle, this middleware never runs. Solve at the CDN/WAF layer (Cloudflare, Fastly) instead.
• You need CSP report ingestion and dashboards. This package emits headers and report endpoints; it does not collect, parse, or alert on violations. Budget for a collector (report-uri.com, Sentry, an internal endpoint) as part of the same initiative — otherwise report-only mode is theater.
• You expect the vendor to own your policy. Presets cover common services, but your first-party inline scripts, custom subdomains, and internal tooling are yours. Someone must own directive drift as the front end evolves.
• Non-Laravel or multi-framework estate. Value is concentrated in the Laravel integration; porting the concept elsewhere means re-solving it.
• Maturity caveat to flag in diligence. Public signals here are modest (871 stars) and the supplied metadata reports zero dependents, which likely understates real usage given Spatie's download volumes but is worth a quick sanity check. Treat this as a well-maintained, single-purpose utility from a reputable vendor — not a platform bet. Pin the version and read the changelog on upgrade; CSP config semantics (presets, directives, report_to, reporting_endpoints) have evolved across majors.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk security control for a specific, well-publicized failure mode — a compromised third-party script harvesting user data from our pages. CSP is the browser-enforced allowlist that stops that exfiltration even when our code is clean. We buy the implementation for free (MIT) and pay only in configuration and a phased rollout: observe violations in report-only mode, then enforce. It also closes a recurring item in enterprise security reviews.

For engineering: One Composer dependency, one middleware registration, one published config file. It handles header generation, nonce creation and Blade integration, per-route policy overrides, and report-only vs. enforced modes. Presets cover ~40 common vendors so we are not hand-writing directives for Stripe or Google Tag Manager. Costs to plan for: an initial audit of our own inline scripts and third-party domains, a report collection endpoint, and ongoing ownership when we add new front-end tooling. Deliberate tradeoffs are exposed as config (nonce_enabled, unsafe-inline, hot-reload bypass) so we can document our posture rather than assume it.

Recommended next steps: (1) Enumerate current third-party scripts and map to presets. (2) Enable report-only in staging with a collector. (3) Triage violations, add custom preset for first-party needs. (4) Enforce in production with a rollback via CSP_ENABLED. (5) Add "CSP directive review" to the vendor onboarding checklist.