Insecure Routes Bundle Laravel Package

Product Decisions This Supports

• A build-vs-buy decision, and the answer is build. The capability — relax HTTPS scheme enforcement in dev/test only, keep it on everywhere else — is roughly a conditional URL::forceScheme() call plus one middleware. Vendoring a dependency to replace tens of lines of framework code is a net negative on review, upgrade, and supply-chain cost.
• A platform-policy decision, not a feature decision. The real product signal is that route-level HTTPS hardening leaks friction into local, CI, and proxy-terminated environments. The durable answer is environment-scoped configuration (per-env .env, AppServiceProvider gating, trusted proxies), asserted as a production-only invariant — not a package whose purpose is to disable a security control.
• A roadmap non-starter on compatibility grounds. This is a Symfony2 bundle; Laravel cannot composer require it without pulling SymfEon 2 routing/DI components that conflict with illuminate/*. It does not appear on any Laravel roadmap regardless of quality.
• A useful reference pattern for legacy migrations. The one place it informs a decision is an inherited Symfony 2.x service: the concept (strip scheme requirements at container-build time, gated to dev/test kernels) is portable even though the package is not.
• A security-posture checkpoint. It reinforces a rule worth encoding in platform guidance: "insecure" behavior must be switched by environment, never by a runtime flag that could be flipped in production.

When to Consider This Package

Consider it only if all of the following hold:

• The application is Symfony 2.x (not Laravel, not Symfony 3+, not standalone Symfony components).
• Routes genuinely declare HTTPS scheme requirements that cannot be relaxed through configuration.
• The team is under a minimal-change policy and will not restructure config per environment.
• Someone owns the fork. With 13 stars and zero dependents, treat it as vendored source you maintain, not a dependency you consume.

Look elsewhere — or write it yourself — when:

• The stack is Laravel. Use URL::forceScheme() gated on app()->environment('production'), a ForceHttps redirect middleware, TrustProxies, and per-env .env. This package contributes nothing.
• You are on Symfony 4+. Framework-native per-env config and proxy trust cover the need without a bundle.
• You need maintenance guarantees or security review. Zero dependents means zero external validation; for a package that removes a security control, unmaintained-and-unvalidated is the worst combination.
• The real problem is proxy/scheme detection in production. That's a forwarded-headers fix, not an HTTPS-stripping one; using this package there would disable a control in the environment that needs it most.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Close the evaluation; harvest the pattern.

The package removes HTTPS scheme requirements from routes in Symfony2 applications so they can be served over plain HTTP in dev and test. The pain is real — hardened HTTPS defaults make local and CI environments awkward — but the instrument is wrong on every axis we care about:

• Wrong framework. It is a Symfony2 bundle. Our Laravel services cannot use it; modern Symfony services have moved past the bundle model it targets. No path to adoption exists on current stacks.
• Wrong economics. The functionality is a conditional in AppServiceProvider::boot() plus one middleware we would own and understand. The dependency costs more in review, upgrade, and supply-chain attention than writing it.
• Wrong risk profile. 13 stars, zero dependents, EOL target. For a package whose purpose is to remove a security control, the failure mode — it silently stays enabled in an environment that needed HTTPS — is exactly the one we cannot tolerate.

What to do instead: standardize the environment-scoped approach in platform guidance — HTTPS enforced as a production-only invariant, forceScheme gated on app()->environment() (not raw env()), trusted proxies configured, HSTS off only outside production, and a CI check that fails if scheme requirements are relaxed anywhere but local/testing. That guidance is reusable across every Laravel service; this package is usable on none of them.

Effort to close: near zero. Effort to adopt: fork maintenance plus ongoing security review of a control-disabling dependency. The trade is not close.