- How do I install opctim/symfony-csp-bundle?
- Install it with Composer using composer require opctim/symfony-csp-bundle. Because it is a Symfony bundle rather than a native Laravel package, you register it through the Symfony bundle registration mechanism (or wire its services manually in a Laravel service provider) instead of relying purely on Laravel package discovery. Version 2.x requires PHP 8.1 or newer and Symfony 6, 7, or 8 components. Confirm your framework versions before requiring it so Composer does not fail resolution.
- Can I use this Symfony CSP bundle in a Laravel application instead of spatie/laravel-csp?
- It can work in Laravel, but only as a Symfony bundle consumed through Symfony components, which means manual service registration and configuration rather than Laravel-native config publishing. If you want a first-class Laravel experience with a service provider, config file, and middleware, a Laravel-specific CSP package is usually the smoother choice. Use this bundle when your stack already standardizes on Symfony components or you are sharing CSP configuration between Symfony and Laravel services. Expect extra wiring work either way.
- Which PHP, Laravel and Symfony versions does opctim/symfony-csp-bundle 2.x support?
- Version 2.x requires PHP 8.1 or newer and supports Symfony 6, 7, and 8, while dropping Symfony 5.4 support entirely. Since Laravel versions are tied to Symfony component versions, that drop effectively excludes Laravel 8-era applications, which still depend on Symfony 5.4. Laravel 9, 10, 11, and later on PHP 8.1+ are the realistic targets. Always verify against the package's published compatibility matrix before upgrading.
- How do I configure Content-Security-Policy directives with this bundle?
- You declare your policy directives in the bundle's configuration, which in Symfony is a YAML config file, and the bundle attaches the resulting CSP header to responses. Directives such as default-src, script-src, style-src, img-src, and connect-src are listed with their allowed sources. Keep the starting policy tight and loosen individual directives only where you have a concrete need, so you do not silently re-open XSS vectors.
- How do I generate a nonce for inline scripts and styles with this bundle?
- The bundle generates a per-request nonce that you add to the script-src and style-src directives and then echo into the nonce attribute of each inline script or style tag. Because the value changes on every request, an attacker cannot predict a nonce to bypass your policy. Make sure the nonce exposed to your templates is the exact same value used in the header, otherwise browsers will block the inline content. Nonces are generally preferred over allowlists for inline code because they avoid unsafe-inline.
- When should I use hashes instead of nonces for inline scripts and styles?
- Hashes work well when your inline scripts or styles are static and you can compute their digest at build or render time, since the hash for a given snippet never changes. Nonces are better for dynamic inline content or server-rendered pages where recomputing hashes is impractical. Using hashes lets you keep a strict policy without unsafe-inline and without per-request state. The bundle supports generating hashes for inline content so you can choose per directive.
- How do I collect CSP violation reports with this bundle?
- You point the report-uri or report-to directive at an endpoint you control, and the bundle helps you collect the violation reports that browsers POST there. Reports tell you which directives are too strict for real traffic, which is essential before enforcing a policy. Roll out in report-only mode first, watch the reports for a while, then switch to enforcement. Store or forward the reports so you can spot regressions after deployments.
- What are the breaking changes in 2.0 and how do I upgrade from 1.x?
- The 2.0 release is a platform shift: it raises the minimum to PHP 8.1 and removes Symfony 5.4 support while adding Symfony 8. The release notes do not document public API changes beyond these platform requirements, so hidden behavioral risk from the PHP 8.1 refactor is possible. Upgrade PHP first, then the framework, then the package, and run the change in staging before production. Applications still pinned to Symfony 5.4 should stay on the 1.x line.
- How do I test that the Content-Security-Policy header is applied correctly?
- Write feature tests that assert the CSP header is present on representative responses, including HTML pages, error pages, and any streaming or JSON endpoints that should or should not carry it. If you use nonces, assert the nonce in the header matches the one rendered into the markup. Add a browser-level smoke test or use report-only collection in staging to catch violations that unit tests cannot see. Also verify your policy does not contain unsafe-inline unless you explicitly accept that risk.
- Is Symfony 8 support in this bundle production-ready, and how long will the 1.x line be maintained?
- The release notes state Symfony 8 support was added, but that alone does not prove it has been tested against a stable Symfony 8 release rather than a dev or RC build. Ask for test evidence and a compatibility matrix before putting it into a critical path. The 1.x line is expected to move toward security-only maintenance for legacy Symfony 5.4 consumers, so teams on that line need a dated exit plan. For anything runtime-critical, treat this as a dependency upgrade program with staging and canary rollout rather than a routine patch.