Weave Code
Security Csrf Laravel Package
symfony/security-csrf
The Symfony Security CSRF component provides a CsrfTokenManager class for generating and validating cross-site request forgery tokens, helping protect your PHP applications from forged form submissions and malicious requests.
Symfony Security Component - CSRF Library
Frequently asked questions about Security Csrf
- Is symfony/security-csrf a Laravel package?
- No. It is a framework-agnostic, low-level component from the Symfony Security suite that provides a CsrfTokenManager class for generating and validating tokens. Laravel already ships first-class CSRF protection through the VerifyCsrfToken middleware, the csrf_token() helper, the @csrf Blade directive, and the XSRF-TOKEN cookie consumed by Sanctum. Adopting this package is therefore a decision to replace or supplement a working in-house control, not a decision to add CSRF protection.
- Why would I use symfony/security-csrf instead of Laravel's built-in CSRF protection?
- For ordinary Laravel web forms, the cost of swapping out VerifyCsrfToken for a hand-written bridge is higher than the benefit. The one genuinely differentiated capability is SameOriginCsrfTokenManager, which validates requests statelessly via Origin, Referer, and Sec-Fetch-Site headers instead of a session token. Secondary reasons include per-intention tokens with independent lifecycles and pluggable TokenStorageInterface storage such as Redis or a database instead of the session.
- Which version of symfony/security-csrf works with Laravel 11 or Laravel 12?
- Laravel pins Symfony components per major release: Laravel 10 uses symfony/* ^6.2, Laravel 11 uses ^7.0, and Laravel 12 uses ^7.2. That makes symfony/security-csrf ^7.4 installable on Laravel 11 and 12 without a resolver conflict. Version 8.x requires PHP 8.4 and will almost certainly conflict with Laravel's Symfony floor until the framework adopts Symfony 8, so treat it as out of scope for now.
- How do I install symfony/security-csrf in a Laravel application?
- You install it with Composer, for example composer require symfony/security-csrf:^7.4 on Laravel 11 or 12, but installation is the easy part. There is no Laravel integration layer shipped with the package or maintained elsewhere, so you have to build the wiring yourself. Expect to write a service provider, a storage adapter, a middleware, and Blade helper shims before anything actually works.
- Does symfony/security-csrf conflict with Laravel's VerifyCsrfToken middleware?
- Technically no, because the classes live in different namespaces and can coexist in the same application. Operationally, running both means two parallel token systems: Laravel's single global session token and Symfony's per-intention tokens with independent lifecycles. You need to decide explicitly which guard protects which route group, because leaving both active produces duplicate token handling and confusing failure modes.
- What is SameOriginCsrfTokenManager and when should I use it?
- SameOriginCsrfTokenManager, available in Symfony 7.4 and 8.0, validates requests statelessly using Origin, Referer, and Sec-Fetch-Site headers rather than a stored session token. It depends on those headers being present and intact, so proxies and CDNs that strip Origin, native mobile clients and webviews that omit it, older Safari versions without Sec-Fetch-Site, and same-origin GET flows all need a documented fallback. Any fallback to a session token reintroduces exactly the state you were trying to remove.
- How much work is integrating symfony/security-csrf with Laravel?
- It is real engineering, not configuration. A working integration requires a service provider, a TokenStorageInterface adapter bridging Illuminate\Session\Store or Redis to Symfony's session contract, a custom middleware registered in the web group, and Blade helper shims to replace csrf_token() and @csrf. Note also that Laravel middleware is not PSR-15 middleware, so any claim of native PSR-15 fit does not translate to Laravel.
- How do I migrate existing Laravel forms to Symfony CSRF tokens?
- Plan for a graceful dual-accept window, because Laravel uses one global session token while Symfony keys tokens by an intention string with its own lifecycle. A direct cutover invalidates every in-flight form submission and every cached page containing an embedded token. Rolling out per form class, accepting both token types temporarily, and only then removing the Laravel middleware is the lower-risk path.
- Is symfony/security-csrf safe to use in production in a Laravel app?
- The underlying primitives are solid: Symfony's random token generation and constant-time comparison are battle-tested and maintained by the Symfony core team. The risk sits in the bridge you write, where wrong middleware ordering, tokens validated against the wrong intention, or storage silently falling back to a non-persistent driver can create the appearance of protection with none of it. For a security control, we wrote our own adapter and it passes our own tests is a weaker assurance posture than we use the framework default.
- Is symfony/security-csrf actively maintained, and what are the alternatives?
- Yes, it is part of the Symfony Security component and is released and maintained alongside Symfony itself. Star counts and dependents figures on the standalone repository understate real usage because most consumption happens through symfony/framework-bundle and the symfony/security-* meta packages rather than this package directly. For Laravel applications, the mainstream alternatives are simply the built-in VerifyCsrfToken middleware and Sanctum's cookie-based XSRF-TOKEN flow for SPAs.
Weaver
How can I help you explore Laravel packages today?