Csp Bundle Laravel Package

Product Decisions This Supports

• Local development fidelity, not just production hardening. v3.2.0 fixes a Safari-only breakage where the upgrade-insecure-requests directive forced loopback-host asset requests over HTTPS, leaving local pages unstyled. This means the package now supports a credible "dogfood the real CSP in dev" workflow rather than forcing teams to disable CSP locally and discover problems only in staging. That directly informs whether you can keep Content-Security-Policy enabled on local/dev environments in your Laravel app config.
• Environment-specific policy without forking the package. The new README guidance (upgrade-insecure-requests: false under when@dev) plus the CspHeaderBuilder::build() plainLoopbackOrigin argument gives PMs a supported path for the common case of a dev server reached at a custom name (app.test, a Laravel Sail/Valet hostname, a LAN IP for device testing). Decide whether your team standardises on the automatic loopback exemption or opts out explicitly per environment — the second is what you'd require if your local hostnames are non-loopback.
• Build vs. buy. This is a narrow, well-scoped concern (header construction and policy assembly) that is cheap to adopt and expensive to maintain correctly across browser quirks. The Safari/loopback divergence is exactly the kind of detail an in-house implementation would miss for months. Leans clearly toward buy/adopt.
• Bug triage and support-cost reduction. If your support or DX backlog contains "CSP breaks local dev" reports, this release likely closes them. Worth checking whether the Safari-only symptom was misattributed to your asset pipeline or Vite config.
• Security posture decisions. The fix is deliberately narrow: the exemption keys on the host, never the scheme alone. Public HTTP sites keep the directive, and so does a site behind a TLS-terminating reverse proxy missing from trusted_proxies (which the framework perceives as plain HTTP). This is a decision you should consciously accept — it means the package prefers a slightly over-strict policy over silently weakening CSP for a misconfigured production proxy. That's the right default, but confirm your proxy configuration is correct rather than relying on the fix to cover it.
• Roadmap signal for extension points. BuildCspHeaderEvent now sends a policy exactly as the listener wrote it, which makes event-based customisation a dependable escape hatch. If your roadmap includes nonce handling, reporting endpoints, or per-route policies, this is the hook to build on.

When to Consider This Package

Adopt when:

• You ship a Laravel app with a browser-facing UI and need a Content-Security-Policy header set consistently across responses.
• You want CSP managed in PHP/config alongside the rest of your application config rather than in web-server config or a separate middleware you maintain yourself.
• You need environment-differentiated policies (strict in production, relaxed in dev) without duplicating header logic.
• You value correct handling of browser-specific edge cases — this release is evidence the maintainer tracks them, including Safari's divergence from Chrome and Firefox on loopback hosts.

Look elsewhere or pause when:

• Your CSP is generated at the edge (CDN/edge worker, reverse proxy, or a WAF) and PHP-side headers would conflict or be overwritten.
• You have no browser UI (API-only service) — the value is close to zero.
• You require per-response or per-tenant policies driven by runtime data the package's builder and event don't expose; verify the extension points before committing.
• You cannot tolerate behaviour changing across patch/minor releases. Worth noting: v3.2.0 changes observable output — upgrade-insecure-requests is now omitted automatically for plain-HTTP loopback hosts. The release describes existing calls as unaffected, and they are at the API level, but if you assert on exact header strings in tests running against localhost, expect those assertions to need updating. Pin versions and review minor releases if your test suite is strict about header contents.

How to Pitch It (Stakeholders)

To executives: This is a small, focused library that applies a security header (Content-Security-Policy) to our Laravel app's responses. The latest release fixes a real defect: on local development servers, Safari was blocking our stylesheets and images, so developers saw broken pages and lost time. It's fixed with a tightly scoped rule that only affects genuine local development addresses (localhost, 127.0.0.1, ::1) — production policies are unchanged, including for sites served over HTTP or sitting behind a proxy. Investment: minimal. Return: fewer "works on my machine" incidents and a security header we can keep switched on everywhere, including during development.

To engineering: v3.2.0 is additive at the API level — build() takes an optional plainLoopbackOrigin argument, existing calls compile and behave the same. The substantive change is that upgrade-insecure-requests is now omitted when a page is served over plain HTTP to a loopback host, because Safari applies the directive there and Chrome/Firefox don't. The exemption checks the host, not the scheme, so public HTTP sites and TLS-terminating proxies not listed in trusted_proxies keep the directive — if you see the directive unexpectedly retained behind a proxy, fix trusted_proxies rather than working around the package. Policies set via BuildCspHeaderEvent are now sent verbatim. If you run a dev server under a non-loopback name (app.test, LAN IP), set upgrade-insecure-requests: false under when@dev as the README describes. Check any tests that assert on exact header strings for loopback hosts.