Csrf Route Bundle Laravel Package

Product Decisions This Supports

• Feature scoping: closing the "non-form mutation" gap. Laravel's VerifyCsrfToken protects form-driven POST/PUT/DELETE out of the box, but many real products still ship state-changing actions as GET links (logout, delete, archive, toggle, "mark all read", one-click unsubscribe) or as XHR calls that bypass the token in a refactor. This package's core idea — per-route opt-in CSRF protection that does not require a form — is a valid roadmap item called "harden non-form mutation paths," and it is worth scheduling whether or not this repo is ever installed.
• Build vs. buy → build. For a Laravel codebase the decision collapses almost immediately: the package is a Symfony 3 bundle with no ServiceProvider, no config/ publish target, no facade, and no Laravel middleware, so it cannot be composer required into a Laravel app without a port. The realistic estimate for a native equivalent (a route-group middleware, a token issuance helper using csrf_token(), hash_equals comparison, and a 401/419 response) is 1–2 engineer-days plus tests. The package's real contribution is a proven API shape — per-route annotation/option, token attached at URL-generation time, validated before the controller — which de-risks that estimate. Buy the pattern, build the code.
• Security/compliance backlog prioritization. If there is a pentest finding, a SOC 2 / ISO 27001 control line ("state-changing requests are protected against CSRF"), or an upcoming audit, this repo is useful evidence for scoping: it lets a PM size the remediation as a contained hardening ticket rather than an auth-platform project. It also gives a concrete control narrative to hand to security reviewers.
• Use cases that justify the roadmap item: legacy admin panels where destructive actions are still <a href> links; internal tools where "it's behind SSO" is the only current control; HTML endpoints that aren't form-driven; migrating a form-based flow to fetch/XHR without losing the token guarantee; logout via GET.
• Scoring caveat for prioritization. Opportunity score 25.31 signals an unmet ecosystem need, but 0 stars, 0 dependents, and README-only maturity say nobody has validated this implementation. Treat the problem as validated and the solution as unvalidated. Fund the ticket on the pentest/control rationale, not on the package's popularity.
• What it should not drive: it is not a reason to introduce a Symfony dependency, not a reason to touch framework choice, and not a build-vs-buy data point in favor of "buy" — the stewardship signals (abandoned, EOL platform, repo-name/packagist-name mismatch) rule that out.

When to Consider This Package

Consider it — as reference material, not a dependency — only if:

• You are on Symfony 3.x (or maintaining one) and want a working precedent for route-level CSRF opt-in.
• You have a concrete inventory of non-form, state-mutating routes with no token check today — not a hypothetical.
• You intend to read, fork, or reimplement it, with the security posture of "auditable and owned by us." Zero dependents means zero downstream bug reports and zero incidental patches; you are the maintainer.
• Your team wants a syntax reference (annotation + options: { csrf_token: true }) to align an internal design doc before writing middleware.

Look elsewhere — decisively — if:

• You are on Laravel. This is a Symfony bundle and cannot be installed as a Laravel package. Laravel already ships the answer: VerifyCsrfToken middleware, the @csrf Blade directive, csrf_token() for programmatic URLs, X-XSRF-TOKEN for Axios/XHR, and Sanctum for the SPA/API case. For non-form routes the work is a middleware/route-group configuration decision, not a package decision. This framework mismatch is the single most important line in this assessment.
• You are on Symfony 4+ / 5+ / 6+ / 7+. Symfony 3 hit EOL in November 2021. Adopting an EOL-pinned bundle to fix a security problem means inheriting security debt — use symfony/security-csrf plus a small route/kernel listener.
• The endpoints are a real API. Token-in-page CSRF is the wrong control for machine-to-machine or token-authenticated surfaces; use bearer tokens / signed requests / SameSite cookies with explicit origin checks.
• You cannot tolerate the supply-chain signals. Resolve the identity drift first: repo is enumag/csrf-route-bundle, README installs genedys/csrf-route-bundle. Combine that with 0 stars, 0 dependents, README-only maturity, and no releases/issues/CVE feed — the MIT license is fine, the stewardship is not. That mismatch is exactly what flags in a lockfile review.

One-line rule: relevant as design input for a Laravel middleware; never as a dependency.

How to Pitch It (Stakeholders)

To executives (30 seconds): We found a small open-source project that solves a real, narrow security problem — protecting state-changing routes that aren't form submissions, a common blind spot in older web apps. The project itself is not safe to depend on: it targets an end-of-life framework version, has zero users, and has no active maintainer. My recommendation is to adopt the idea, not the code. We can implement the equivalent in our own Laravel stack in a day or two, fully owned by us — cheaper than the risk of inheriting an abandoned dependency. Small upfront cost, meaningful reduction in a class of vulnerability an auditor or pen-test would otherwise find.

To engineering leads: The value here is the pattern, not the package. It shows a per-route opt-in surface (annotation/route option), token attached at URL-generation time, validation in a listener before the controller runs, plus configurable field name, intention, and covered HTTP methods. Two takeaways: (1) that API shape is a good template; (2) "no form" is not "no CSRF exposure." Do not add the Composer dependency — it's a Symfony 3 bundle, Symfony 3 is EOL, the repo name doesn't match the install target, and there are no dependents to shake out bugs. Instead please scope native work in Laravel: a route-group middleware extending our CSRF handling, a helper for generating protected URLs, hash_equals comparison, a 419 response contract, and a test matrix covering link-triggered destructive GETs, XHR deletes, and the logout path. Estimate 1–2 days plus tests. Definition of done: every state-changing route in the inventory is behind the middleware or explicitly documented as exempt.

To security/compliance: This is a validated gap with an unvalidated fix. It supports the control narrative "all state-changing requests require a token, including non-form routes," which is defensible to an auditor. The shipped implementation must be ours, with a documented token lifetime, rotation on privilege change, and an exemption list that is reviewed rather than implicit. Please confirm whether scope is HTML routes only or also the XHR/SPA surface — the latter changes the header strategy (X-XSRF-TOKEN / SameSite + origin checks) and the test plan.

Bottom line for the decision log: Reject as a dependency — framework mismatch (Symfony 3 bundle in a Laravel codebase), EOL platform, no stewardship, package-identity mismatch. Accept as a design input for a native Laravel middleware. Owner: platform team. Timeline: next hardening sprint. Success metric: zero state-changing routes without token enforcement or a documented exemption.