Stack Cors Laravel Package

Product Decisions This Supports

• Feature enablement for browser clients. Any decision to support a SPA, embedded widget, white-label frontend, or partner-hosted UI on a different origin than the API is a CORS decision. This package is the enforcement point for that decision: which origins, methods, headers, and credentials are permitted, and for how long preflights are cached.
• Partner and multi-tenant integration roadmap. Expanding from "our domain only" to "customer domains / partner portals" turns CORS configuration into a product contract. The library's support for multiple origins, patterns, and per-route policies is what makes that roadmap cheap rather than a bespoke engineering project.
• Build vs. buy (buy, and buy small). CORS looks trivial and is not: preflight handling, Vary headers, credentialed-request rules, wildcard-with-exceptions, and origin reflection are all easy to get subtly and dangerously wrong. A 1.2k-star MIT library that already underpins mainstream Laravel CORS packages is a "buy" with near-zero procurement cost.
• Security and compliance posture. CORS is an access-control boundary and a recurring finding in pen tests and SOC 2 / vendor reviews. Standardizing on a vetted engine — rather than per-team header code — gives you one place to review, one config to audit, and a defensible answer to "how do you prevent origin reflection with credentials?"
• Platform standardization and support cost. One policy layer across services means support tickets about "blocked by CORS" get resolved against a known config surface instead of ad hoc middleware in five repos.
• Developer experience. Frontend teams unblock themselves via config rather than backend tickets; measurable as reduced cycle time on cross-origin integrations.

When to Consider This Package

Consider it when:

• You run a PHP backend serving browsers from a different origin, and you need credentialed requests, multiple or wildcard-with-exceptions origins, pattern matching, exposed headers, or per-path policies.
• You are on a non-Laravel or legacy PHP stack using double-pass ("stack") middleware, where this library is the intended integration style.
• You are building your own framework integration and want the CORS engine separated from the framework glue.

Look elsewhere or do not adopt directly when:

• You are on modern Laravel. CORS handling ships in the framework (built on a library such as fruitcake/php-cors), and older barryvdh/fruitcake Laravel CORS packages pulled asm89/stack-cors in transitively. In that case your decision is "accept it as a transitive dependency," not "adopt it." Verify against composer.lock before you write it into an ADR.
• Your need is narrow and static — one public, read-only API with Access-Control-Allow-Origin: *. Edge/CDN or gateway configuration is cheaper and closer to the traffic.
• You need PSR-15 middleware or gateway/WAF-level enforcement. This is stack-style middleware, not a PSR-15 implementation, and application-layer CORS is not an authorization control.
• Maintenance risk is unacceptable for your tier. Single-maintainer projects with modest star counts warrant a version pin, an advisory watch, and a fallback plan — mitigated here by a very small, well-understood surface area. Confirm the recent release date in the repo metadata reflects genuine tags and security-relevant fixes rather than routine dependency bumps.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is small, free (MIT), widely used plumbing that already sits underneath the CORS packages in most Laravel stacks. Adopting it is a dependency decision, not a project — roughly zero cost, low risk, no lock-in. Its value is defensive: it lets us safely open our APIs to browser clients on other domains — partner portals, embedded widgets, customer-hosted frontends — without hand-rolling security-sensitive header logic. It is infrastructure, not a differentiator; approve it as a dependency and move the roadmap conversation to which origins we choose to allow.

For engineering: Don't hand-roll preflight logic. Centralize the allow-list and policy in configuration, treat origin lists as reviewed config rather than code, and add tests for credentialed requests, origin reflection, and Vary behavior. Pin the version, watch advisories, and confirm whether the framework already provides this transitively before adding a direct dependency. Budget a short spike to map the dependency path and produce a one-page CORS policy owned by a named team.