Cors Laravel Package

Product Decisions This Supports

• Unblocking front-end/back-end separation. CORS misconfiguration is a classic launch-day blocker when a SPA, admin console, or mobile webview starts calling an API from a different origin. This package turns that into a config-file change rather than a sprint of hand-rolled header logic.
• Public API / partner integration launches. Opening an API to third-party domains forces an explicit decision about which origins are allowed, whether credentials are permitted, and which headers/methods are exposed. A middleware package makes that policy a reviewable artifact instead of scattered header() calls.
• Build vs. buy (really: build vs. adopt vs. use the framework). CORS is ~50 lines of logic but the edge cases — preflight OPTIONS handling, Vary: Origin for cache correctness, the illegal Access-Control-Allow-Origin: * + credentials combination, per-route overrides — are where teams ship bugs. The decision is rarely "write it ourselves"; it's "use what the framework already gives us" vs. "add a dependency."
• Standardizing cross-service policy. If the PHP estate spans Laravel, Slim, ThinkPHP, and Swoft (as this package's support matrix implies), a single middleware with consistent semantics reduces the chance that one service quietly allows *.
• Tech-debt and migration planning. Because the package is archived, its presence in a dependency tree is itself a roadmap item — a candidate for consolidation into framework-native middleware during the next platform upgrade.
• Use-case triage. Good fit for internal tools, prototypes, and legacy services where CORS is a checkbox; poor fit for anything with a security review attached.

When to Consider This Package

Consider it when:

• You are on a PHP framework without first-party CORS support in the version you're pinned to — notably Slim, ThinkPHP, Swoft, or a plain PSR-15 pipeline.
• You need per-route CORS configuration (different origins for public vs. admin endpoints) and want it declaratively.
• The work is tactical: an integration is blocked this week and a config-driven middleware is the shortest safe path.
• You're already on the package and evaluating whether to keep it — the answer is "keep temporarily, schedule replacement."

Look elsewhere when:

• You're on Laravel 7+. CORS handling is built into the framework (HandleCors), descended from fruitcake/laravel-cors. Adding an archived third-party package to do what the framework already does is pure dependency risk with no upside.
• Your security posture requires a maintained dependency. The last release was May 2020 and the repository is archived. That means no PHP 8.x compatibility guarantees, no response to a future CORS-related CVE, and no fixes if a framework's middleware contract changes.
• You need strict, credentialed origin allowlisting with auditability. Verify the origin-echo behavior carefully; wildcard-with-credentials mistakes are the most common CORS vulnerability and an unmaintained package is a bad place to discover one.
• You're on Symfony — nelmio/cors-bundle is the maintained, idiomatic answer.
• You need active support, a security contact, or a release cadence. None of these exist here.

Adoption gate: treat it as a stopgap with a named owner and a removal date, not as a permanent dependency. Add it to the dependency-review list and require a migration ticket at adoption time.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that solves a narrow, well-understood problem — letting our web and mobile clients talk to our APIs from other domains. It costs nothing, it's a one-line install, and it removes a recurring source of launch friction. The caveat is maintenance: the project was last released in 2020 and is archived, so it will not receive fixes. My recommendation is not to make it a platform standard. Where our frameworks already handle CORS natively — which is true for current Laravel — we should use that and carry no extra dependency. Where we're on a legacy stack that doesn't, this is a reasonable short-term bridge, provided we log it as technical debt with a removal plan. Net: low cost, low strategic value, non-trivial long-term risk if left unattended.

To engineering: It's a PSR-15 middleware with adapters for Laravel/Lumen, Slim, Swoft, and ThinkPHP. It gives you config-driven origin/method/header rules and per-route overrides, which is more ergonomic than scattering headers in controllers. Two caveats before you adopt: (1) it's archived since 2020 — assume no PHP 8.x or modern framework support until you've verified it yourself, and pin the version; (2) if you're on Laravel 7+, use the built-in HandleCors middleware instead and skip the dependency entirely. If we do adopt it on a legacy service, open a ticket to migrate to framework-native middleware at the next upgrade and make sure Vary: Origin and the wildcard-plus-credentials rule are covered by a test.