Symapi Security Bundle Laravel Package

Product Decisions This Supports

• Correcting a mis-scoped inventory item. This is catalogued as a "Laravel/PHP package," but expertcoder/symapi-security-bundle is a Symfony bundle. It will not install into a Laravel application: Symfony bundles depend on the Symfony Kernel, DI container compilation passes, bundle extensions, and the Symfony EventDispatcher—none of which Laravel provides. Any roadmap or vendor list that assumes this is Laravel-ready should be corrected before it drives a build decision.

• Adopt vs. build vs. buy in the authentication path. Authentication is a component where a defect is an incident, not a bug ticket. This repository is archived, 0 stars, 0 dependents. That is a product signal rather than a vanity metric: no maintainer, no security patch channel, no downstream evidence that anything runs it in production. It fails a reasonable "do we want a third party in this path?" test on maintenance posture alone.

• Sizing the real alternatives. API authentication is a solved problem in both ecosystems—Laravel Sanctum/Passport/Fortify, Symfony's native Security component, API Platform's built-in auth, or a managed identity provider (Keycloak, Auth0, Cognito, Entra ID). The decision worth putting on the roadmap is which maintained option, not whether to use a bespoke bundle.

• Prior-art input to a spec, not a dependency. The description implies a useful capability set—firewall and access-control rules per API route, token/API-key authentication, centralized rules across multiple API entry points, environment-consistent configuration. If we are writing requirements for API auth (token vs. API-key flows, per-firewall access rules, stateless 401 JSON responses instead of login redirects), this repo is worth an hour of reading as a design artifact. Read the behavior, spec it, reimplement natively.

• Trigger for a legacy migration ticket. If any Symfony service in our estate still depends on this bundle, the archive status converts "leave it alone" into "we now own it forever, including PHP upgrades and security patches." That should be an explicit, prioritized migration item toward the native Security component.

When to Consider This Package

Consider it only in these narrow cases:

• You maintain a legacy Symfony application already wired to this bundle and need to understand it before removing it—the archive status is the argument for migration, not against it.
• You need prior-art examples of Symfony API security configuration for a design document and are comfortable reading unmaintained code under a permissive license.
• That is the full list. There is no defensible scenario for adding it to a new build in either framework.

Look elsewhere when:

• You're on Laravel. This is the expected case. Use Sanctum for token/SPA auth, Passport for OAuth2, Fortify for auth scaffolding. None require a Symfony bundle, and none can be satisfied by one.
• You're on Symfony. Use the native Security component plus a maintained JWT/token bundle, or API Platform's auth, or delegate to a managed IdP.
• You require anything a security dependency normally implies: a patch cadence, CVE response, a supported PHP/framework matrix, a disclosure channel, or a support contract. An archived repo guarantees none of these, and in security code the failure mode is quiet—drift against a newer runtime can fail open rather than loudly.

Adoption criteria worth standardizing internally: active release within the last 12 months, tests present, semver releases, an explicit supported PHP/framework matrix, and a documented security disclosure path. This package scores zero on every one. Writing those criteria down is the durable output of this evaluation.

How to Pitch It (Stakeholders)

To executives: We evaluated this package and recommend against adoption. Two facts decide it: it targets Symfony, not our Laravel stack, so it cannot be installed without a port; and it is archived—no maintainer, no community, no downstream users. Putting an unmaintained dependency in our authentication path converts a solved problem into an unowned security and maintenance liability, where any future PHP upgrade or vulnerability becomes entirely our cost. The recommendation is a maintained first-party option (Laravel Sanctum or Passport) or a managed identity provider—both of which we can support, patch, and staff.

To engineering: Treat the repository as reference material only; do not add it to composer.json. It is a Symfony bundle (Kernel, DI compilation passes, bundle extensions) and has no adapter path into Laravel's service-provider model, so the only portable part is the underlying security logic—and only by reimplementation. If the behavior is worth having, read the source, write a short spec (inputs, outputs, failure behavior, every security-relevant decision), map each piece to a native primitive (auth guards, route middleware, Gates/Policies, Sanctum/Passport, framework header handling), reimplement with tests, and record the decision in an ADR. If any legacy Symfony service still uses it, open a migration ticket to the native Security component. State the disqualifying criteria—maintenance status, framework compatibility, security response—in the ADR so future evaluations are consistent. Note also that zero dependents means no community memory of pitfalls; onboarding cost is a senior engineer reading security code line by line, which typically exceeds the cost of building the native equivalent.