Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Insecure Routes Bundle Laravel Package

jmikola/insecure-routes-bundle

Symfony bundle for enforcing HTTPS on sensitive routes: mark routes as secure-only and the listener denies or redirects any request arriving over plain HTTP. Simple YAML configuration, works with your existing firewall and route names.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

  • Architecture fit: Poor for a Laravel codebase. This is a Symfony2 bundle that hooks Symfony’s routing/DI layer; Laravel does not use Symfony bundles or route “scheme requirements” in the same way. HTTPS behavior in Laravel is handled through URL generation, middleware, trusted proxies, secure cookies, HSTS, and web-server configuration. The underlying pattern—relaxing HTTPS only in dev/test—is portable; the package itself is not.
  • Integration feasibility: Low to none. There is no credible composer require path into Laravel without pulling Symfony2-era routing/container dependencies that conflict with Illuminate components. Adoption would require a legacy Symfony2 kernel and bundle registration. For Laravel, the equivalent is a small environment-gated provider/middleware.
  • Technical risk: High if adopted. The package is security-sensitive, targets EOL Symfony2, has very low adoption (13 stars, 0 dependents), and scores 0.155. Accidental activation outside dev/test could weaken transport security. Treat package health signals as disqualifying for a control-disabling dependency.
  • Key questions: Are we actually maintaining a Symfony2 app, or is this being evaluated for Laravel? Can the need be met with Laravel-native environment configuration, trusted proxies, and middleware? What guardrails prevent HTTP relaxation from reaching staging/production? Is the real problem proxy/scheme detection rather than HTTPS enforcement? Do we need legacy migration parity, or only dev/test ergonomics?

Integration Approach

  • Stack fit: Not compatible with Laravel’s package ecosystem. Use Laravel-native patterns: environment-gated URL::forceScheme('https'), TrustProxies, HSTS only outside local/testing, local TLS via Valet/Herd/mkcert, and middleware for any required HTTPS redirects. Keep environment as the switch—not a runtime config flag that could be flipped in production.
  • Migration path: Do not migrate Laravel onto this bundle. If a legacy Symfony2 service exists, isolate the bundle to dev/test kernels and require-dev only, and verify it cannot activate in production. For Laravel, build a narrowly scoped internal equivalent with tests around URL schemes, secure cookies, proxy headers, and redirect behavior.
  • Compatibility: Expect Symfony2/PHP-era constraints that conflict with modern Laravel and PHP versions. There is no Illuminate support and no evidence of compatibility with current frameworks. The Symfony router refactor and later releases break the assumptions this bundle relies on.
  • Sequencing: First confirm framework and environment. Then spike a Laravel-native equivalent behind environment guards. Add CI checks that assert HTTPS enforcement in production and fail if scheme requirements are relaxed outside local/testing. If legacy Symfony is involved, containerize/isolate it and prevent bundle activation outside dev/test before any broader migration work.

Operational Impact

  • Maintenance: Poor as a dependency. It is effectively unmaintained for modern stacks; adopting it creates fork/patch ownership and legacy framework coupling. The durable alternative is a small, owned configuration pattern that the team understands.
  • Support: Minimal community support and no dependent ecosystem. Escalation would be internal only. With zero dependents, there is no external validation to catch regressions; treat it as vendored source or a reference pattern, not a supported dependency.
  • Scaling: Runtime cost is negligible, but operational risk scales with environment drift. A single misconfigured environment flag could relax HTTPS in shared or production-like environments. Standardize environment-scoped configuration centrally.
  • Failure modes: Accidental HTTP in production, insecure session cookies, mixed-content failures, redirect loops behind load balancers/proxies, HSTS inconsistency, divergent local/production behavior, and silent enablement of HTTP relaxation outside dev/test.
  • Ramp-up: Low for a Laravel team to build the native equivalent; higher if forced to understand Symfony2 bundle conventions. TPM action: close the package evaluation, document the Laravel-native HTTPS policy, and add CI guardrails so production HTTPS enforcement remains an explicit invariant.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route
mirvan/ippanel
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource