Secure Controller Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for action-level authorization. This is a single-purpose bundle whose whole job is: read an @Secure("ROLE_X") annotation on a controller action, compare it to the current token's roles, throw an access-denied if not. That is a few dozen lines of glue code. The "buy" decision is really "borrow," and the honest comparison is borrow 100 lines vs. own an unmaintained dependency. Use this package's size as the benchmark that pushes the decision toward "build/inline" or "use the framework's native feature."
• Choosing an authorization model on the roadmap. Annotation-on-controller security is coarse-grained RBAC applied at the HTTP boundary. Adopting it bakes in a decision: roles live next to routes, not next to domain objects. That constrains later work on ownership checks, multi-tenancy, and row-level rules — all of which need voters/policies, not role strings. Decide this deliberately now; it's expensive to reverse.
• Legacy framework freeze-vs-migrate. A dependency last released in 2016 is a symptom, not a cause. If this is in the tree, you are on Symfony 2.x/3.x, and the real roadmap item is the framework upgrade — this package gets replaced as a side effect of that work, not as its own initiative.
• Dependency approval policy input. 14 stars, 0 dependents, last release 2016-03-08, no visible security-response process. This is a clean worked example for calibrating your allow-list: state the threshold (maintained within N months, has a CVE channel, non-trivial adoption) and show that this fails it.
• Security review staffing. Annotation-based access control is invisible to string search and most static analysis; you cannot grep for it the way you grep for middleware. That changes how much manual review you budget for controller surface area, and it argues for migrating to attribute-based checks that tooling can see.
• Correcting the request framing. This is a Symfony bundle, not a Laravel package — it hooks Symfony's DI container and annotation reader. If the originating ask was "find me a Laravel authorization package," the decision is already made: this is out of scope.

When to Consider This Package

Consider it (narrowly):

• You are on an existing Symfony 2.8/3.x codebase that already depends on it, and removing it mid-cycle carries more risk than leaving it. Retention here is a deferral, not an endorsement.
• The application is internal, low-traffic, and low-blast-radius, and the org has explicitly accepted framework EOL.
• Requirements are strictly "does this user hold ROLE_ADMIN?" — no ownership, tenant, or attribute conditions.
• You are reading it as a reference implementation for how to wire an annotation listener, not installing it as a dependency. This is its highest-value use today.

Look elsewhere:

• Any greenfield build. Native equivalents are strictly better and maintained: Symfony 5.2+ #[IsGranted], or first-class voters for anything conditional; Laravel Gates/Policies with authorize(), can: middleware, or Gate::authorize(). Same capability, zero added dependency.
• You need anything beyond flat roles. Ownership (is_granted('EDIT', $post)), expression language, tenant scoping, or ABAC — annotations of this shape cannot express it, and stretching them produces authorization logic smeared across controllers.
• You need a maintained dependency. No release since March 2016 means no CVE response path. For anything touching auth, that is disqualifying on its own, independent of code quality.
• You are on Laravel. Not applicable — wrong framework, wrong extension points.
• You need static-analysis or audit visibility into the auth map. Attribute-based or centralized policy config wins.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed Symfony add-on that does exactly one thing — it lets a developer mark a controller action with a required role and blocks users who lack it. It is not a strategic component. It has 14 GitHub stars, no downstream dependents, and has not been released since March 2016, so it has no security-response process. Recommendation: do not adopt it for new work, and if it is already in a product, fold its removal into the next framework upgrade rather than funding a standalone migration. Direct cost is zero and direct risk is low; the reason to say no is opportunity cost and the absence of a maintenance path, not licensing or capability. Its low opportunity score reflects that it offers no differentiation — the same outcome is a built-in feature of every modern framework. The one genuinely useful thing we can take from it is the pattern itself, which we can reimplement in-house in under a day if we ever need it.

To engineering (one paragraph): Mechanically, it is an annotation reader plus a kernel event listener that maps @Secure("ROLE_X") to a role check on the security token — no domain logic, no persistence. Replacing it is a per-controller refactor that can ship incrementally: enumerate every annotated action, map each role string to an #[IsGranted] attribute (or a voter where the check is conditional), and lock current behavior with integration tests before touching anything, since the annotations are not discoverable by grep. The real cost is the enumeration and test backfill, not the code change. Treat it as reference material for how the listener was wired, not as a runtime dependency worth defending.