- How do I install mulertech/csp-bundle with Composer?
- Run composer require mulertech/csp-bundle:^3.2 and register the bundle in config/bundles.php for Symfony applications. Then add the package configuration under config/packages and define your CSP policy in YAML. The 3.2 release is additive, so existing builder calls keep working without changes.
- How do I configure CSP directives, nonces, and reporting in YAML?
- Policies, directives, nonces, and reporting endpoints are declared in the bundle's YAML configuration rather than in PHP. The bundle builds the Content-Security-Policy header from that configuration and applies it to responses automatically. Keep environment-specific overrides such as when@dev in separate config blocks so production policies stay strict.
- Why is upgrade-insecure-requests missing from my CSP header on localhost?
- Version 3.2.0 omits upgrade-insecure-requests when the request host is a plain-HTTP loopback address such as localhost, *.localhost, 127.0.0.0/8, or ::1. This avoids forcing HTTPS upgrades on local development servers. The behaviour is automatic and requires no application code changes. If your dev host is app.test, a LAN IP, or a container hostname, it is not treated as loopback.
- What does the plainLoopbackOrigin argument in CspHeaderBuilder::build() do?
- It is an optional, opt-in argument added in 3.2.0 that lets you control how plain-HTTP loopback origins are handled during policy construction. Calls to build() with no arguments produce the same policy as before, so the default behaviour is unchanged. Treat it as a public API only if the maintainers confirm long-term support; otherwise it is primarily a test and internal affordance.
- Can I use mulertech/csp-bundle in a Laravel application?
- The package is published as a Symfony bundle, so it does not ship a Laravel service provider or middleware out of the box. Laravel teams can still reuse the policy-construction approach or port the builder logic into a middleware that sets the CSP header on responses. If you need a drop-in Laravel package, check for Laravel-native CSP middleware instead.
- How do per-route CSP rules work?
- The bundle supports per-route rules so different paths can emit different Content-Security-Policy headers. You define the route-specific policy in configuration, and the bundle selects it during response handling. This is useful for separating admin, API, and public-facing areas that need different directive sets.
- How should I test CSP headers that differ between dev and production?
- Because the emitted header now depends on the request host and scheme, assert against both a loopback request and a public-host request in your test suite. Do not rely on a single hard-coded header string if you run tests in different environments. Also verify the four loopback forms and the negative cases: a public host on plain HTTP and a proxy missing from trusted_proxies.
- What happens behind a TLS-terminating proxy if trusted_proxies is misconfigured?
- The loopback fix is host-based, not scheme-based, so a request from a proxy that is not listed in trusted_proxies can appear as plain HTTP. In that case the app keeps upgrade-insecure-requests, which is correct from a security standpoint. It can surface as a production breakage if the site is actually served over HTTP. Fix the proxy configuration rather than disabling the directive.
- Does a BuildCspHeaderEvent listener override the builder output?
- Yes. A policy set through BuildCspHeaderEvent is sent exactly as the listener wrote it. That means listener output wins verbatim over the builder's result. If your listener post-processes the builder output, confirm it still receives the values you expect after upgrading.
- Is the 3.2.0 header change a breaking change, and what are the alternatives?
- It shipped as 3.2.0, a minor release, which implies the maintainers consider the dev-only loopback header change non-breaking; record that semver decision for your team. Review composer.json for supported PHP and framework versions before upgrading. Alternatives include framework-native CSP middleware and other CSP header packages; choose based on whether you need YAML-driven policies, nonces, reporting, and per-route rules.