Csrf Route Bundle Laravel Package

Product Decisions This Supports

Verdict first: this is not a Laravel package, and it is not a candidate for adoption. fantoine/csrf-route-bundle is a Symfony2 bundle — Symfony2 reached end-of-life in November 2019, and the bundle itself shows no meaningful traction (2 stars, 0 dependents, a 0.13 health score). Treat this assessment as a decision to close the evaluation, not as a vendor shortlist entry.

With that framed, here's what the underlying problem space can still inform:

• CSRF token placement as a product surface. The bundle's premise — declaratively attaching CSRF tokens to specific routes rather than wiring them per-form — maps to a real design question: should token enforcement be a framework convention (secure by default) or an opt-in per route (flexible, easier to forget)? This is a genuine architecture decision worth recording in your ADR log.
• Build vs. buy is moot here — it's "buy vs. use what we already have." Laravel ships VerifyCsrfToken middleware and the @csrf Blade directive out of the box, applied to all POST/PUT/PATCH/DELETE routes automatically. There is no capability gap this package fills that Laravel's default does not already cover, and Laravel's default is strictly safer (deny-by-default vs. opt-in).
• Roadmap impact: none. Do not allocate engineering time to spikes, integration work, or migration planning around this package.
• Use case scoping for adjacent needs. If a future requirement is route-level security metadata (e.g., per-endpoint auth tiers, signed URLs, request throttling), the pattern of "annotate the route, enforce centrally" is worth borrowing — but implement it with Laravel's native middleware/route groups or a maintained package (e.g., spatie/laravel-route-attributes for declarative route configuration), not with a Symfony2-era bundle.
• Risk register entry. If this package surfaced from a legacy codebase audit or a vendor proposal, log it as a supply-chain finding: abandoned dependency, no security response path, no upstream patch stream.

When to Consider This Package

Adoption criteria for any CSRF-adjacent package — apply these as a gate, and note that this package fails the majority:

• Framework match. Must target Laravel/PHP 8.x+ as its primary platform. This fails — Symfony2 only.
• Maintenance signal. Commits within the last 12–18 months, responsive issue triage, tagged releases. This fails.
• Security posture. CSRF is a security control; an unmaintained dependency in that path is a liability, not a convenience. Frameworks EOL'd in 2019 receive no CVE patches. This alone is disqualifying.
• Adoption evidence. Meaningful dependent count and real-world usage as a proxy for battle-testing. 0 dependents means zero external validation of edge cases.
• Non-duplication. Must not reimplement a framework primitive. Laravel's built-in CSRF middleware is maintained by the core team and covers this surface completely.

Look elsewhere — specifically, look nowhere. For CSRF in Laravel, the correct answer is the built-in VerifyCsrfToken middleware plus @csrf in forms and X-XSRF-TOKEN for SPA/API clients. For SPA architectures, use Sanctum. Exclusions: do not use this bundle, and do not invest in a Symfony2 compatibility layer to make it work.

If the actual need is Symfony: the maintained equivalents are Symfony's native csrf_protection form configuration and the _token mechanism in the Security component — again, no third-party bundle required. If your team is genuinely on Symfony and evaluating migration, scope that as a platform decision, not a package decision.

How to Pitch It (Stakeholders)

To executives: We evaluated a candidate library for cross-site request forgery protection and are recommending against it. It is built for an obsolete version of the underlying framework (Symfony2, unsupported since 2019), has negligible community adoption, and no maintenance path — meaning any future security flaw would go unpatched in a security-critical code path. Our framework already provides this protection natively and is maintained by the core team. Recommendation: no adoption, no spend, no roadmap change. Cost of this decision: zero. Cost of the alternative: an unpatched security dependency.

To engineering: This is a Symfony2 bundle, not a Laravel package — it does not fit our stack, and Symfony2 is EOL. Laravel's VerifyCsrfToken middleware is deny-by-default and already active on all state-changing routes; adding a third-party layer would reduce coverage by making enforcement opt-in per route. No spike required. If the appeal was declarative route-level configuration, that pattern is worth exploring via route groups, custom middleware, or a maintained attributes package — file it as a separate, low-priority exploration, not a dependency decision.

The one-line version: Wrong framework, no maintenance, duplicates a native control, fails the security-dependency bar — close the ticket.