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

Getting Started

Reality check before anything else: jmikola/insecure-routes-bundle is a Symfony 2.x bundle. It registers through the Symfony kernel/bundle model and hooks the Symfony routing layer at container-build time. You cannot composer require it into a Laravel app — it drags in Symfony2-era routing and DI components that conflict with illuminate/routing and illuminate/container. There is no adapter, no shim, and no reason to expect one. So the day-to-day value here is the pattern, not the package. Everything below is framed that way.

What the package actually does: Symfony routes can declare a scheme requirement (schemes: [https] or requirements: { _scheme: https }). That's correct for production and painful locally, because a route with an HTTPS requirement refuses to serve over plain HTTP. The bundle walks the compiled route collection and strips the scheme requirement, so http://app.local/... resolves. It is designed to be registered in dev and test kernels only.

Where to look first in the repo: the DependencyInjection/ extension and any compiler pass — that's where the route collection is mutated — plus the README for the jmikola_insecure_routes config key and the registerBundles() gating example. If you're reading it as a reference implementation, those two files are the whole package.

If you inherit a Symfony2 app (the only case where it's usable): composer require --dev jmikola/insecure-routes-bundle, register it in AppKernel::registerBundles() inside the dev/test branch, enable it in config_dev.yml, bin/console cache:clear, and confirm an HTTPS-required route now serves over HTTP locally.

Laravel first use case: you added URL::forceScheme('https') to AppServiceProvider::boot() and now every generated URL and redirect points at a certificate your laptop doesn't have. The minimal, correct fix:

// app/Providers/AppServiceProvider.php
public function boot(): void
{
    if ($this->app->environment('production')) {
        URL::forceScheme('https');
    }
}

That one conditional covers ~90% of what the bundle does, in your own codebase, with no dependency.

Implementation Patterns

The Symfony2 pattern the bundle enforces is coarse and environment-scoped: the environment is the security boundary. Enable the bundle in dev/test, and scheme enforcement disappears for that environment globally. There is no per-route opt-in or opt-out. That bluntness is a feature — it makes "is HTTPS weakened here?" a question you answer by looking at one kernel file.

Carry that discipline into Laravel. Ordered by preference:

  1. Don't disable HTTPS locally — enable it. valet secure, herd secure, or mkcert gives you a trusted local certificate. This exercises the same code path production uses and eliminates the entire problem class. It is strictly better than weakening scheme enforcement.

  2. Environment-gated forceScheme (above), kept in AppServiceProvider::boot() and keyed off app()->environment(...) rather than env('APP_ENV'), so it survives config:cache.

  3. Environment-gated redirect middleware for legacy routes that must hard-redirect:

final class ForceHttps
{
    public function handle(Request $request, Closure $next): Response
    {
        if (! $request->secure() && app()->environment('production')) {
            return redirect()->secure($request->getRequestUri(), 301);
        }

        return $next($request);
    }
}
  1. Per-route intent via middleware groups, since Laravel routes carry no scheme metadata. If you genuinely need mixed schemes, express it as a route group, not as route annotation:
Route::middleware('force.https')->group(function () {
    Route::get('/account', AccountController::class);
});

Integration tips that transfer from the bundle's design:

  • One switch, one place. Provider boot plus one middleware. Scattering if (local) { http } through controllers is precisely the mess the Symfony bundle exists to prevent.
  • Make the production invariant testable. Assert in CI that URL::forceScheme('https') is active under the production environment and that HTTPS-required routes redirect — a failing test is the guardrail the package never had.
  • Treat TrustProxies as part of the security surface, not a workaround. Behind a TLS-terminating load balancer, the app sees HTTP and needs forwarded-header trust, not scheme stripping. Configure TrustProxies correctly and let the framework infer the scheme.

Gotchas and Tips

Package-level pitfalls:

  • Abandoned and framework-locked. Symfony 2 only; the Symfony 3 router refactor and everything after invalidate its assumptions. With 13 stars and zero dependents, there is no community to catch regressions — vendor the source and own it, or don't take it.
  • It removes a security control by design. The failure mode is silent: a bundle left enabled in a shared or production-like environment serves session cookies over plaintext. There is no warning, no log line.
  • Compiled container caching. In Symfony, toggling the bundle without clearing the cache leaves you debugging a config change that hasn't taken effect. Classic half-hour lost.

Laravel-side gotchas:

  • env() in application code breaks under config:cache. Use app()->environment(), which reads from the cached config. A env('APP_ENV') === 'local' check silently returns null in a cached deployment.
  • Don't fix proxy/scheme detection by disabling schemes. If production users get mixed-content errors or redirect loops behind a load balancer, the fix is TrustProxies and correct X-Forwarded-Proto handling — not relaxation. Using an insecure-routes approach here means disabling a control in the environment that needs it most.
  • Secure cookies and HSTS drift with the scheme. SESSION_SECURE_COOKIE, Secure cookie flags, and HSTS headers all key off the perceived scheme. If you gate HTTPS relaxation inconsistently across provider boot, middleware, and cookie config, you get cookies dropped in one environment and plaintext sessions in another. Keep them governed by the same environment check.
  • Tests default to http://localhost. $request->secure() is false unless you pass an absolute URL: $this->get('https://localhost/account'). This bites when asserting redirect targets or secure cookies.
  • The environment switch must not be a runtime flag. Never expose "insecure routes" as a config value toggleable per-deployment. The bundle's design — gating on kernel/environment, not config — is the right instinct; preserve it.
  • Extension point worth copying: if you build the Laravel equivalent, put the decision in a single AppServiceProvider boot branch and a single middleware class, with a test asserting production behavior. That's the whole extension surface, and keeping it small is the point.
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.
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
noith/settings
kda/laravel-package