Laravel Middleware Order: Auth Before Role Prevents 403

Every serious web application has invisible rules running behind every single page load. Is this user logged in? Are they an admin? Should this response be cached? Is the session still valid? Without a clean system to answer those questions, you end up scattering security checks and response tweaks all over your controllers — a maintenance nightmare waiting to happen. Laravel middleware solves that by giving you a dedicated, organised layer that sits between the incoming request and your application logic.

The problem middleware solves is cross-cutting concerns — logic that applies to many routes but doesn't belong inside any single controller. Authentication is the classic example: you don't want to paste an if (!Auth::check()) { redirect('/login'); } block at the top of fifty different controller methods. Middleware lets you declare that concern once, attach it to whichever routes need it, and never think about it again. It keeps controllers lean and focused on their actual job: returning a response.

By the end of this article you'll know how to create custom middleware from scratch, understand the difference between global, route-level and group middleware, handle the 'after' vs 'before' execution distinction that trips up most developers, and build a real role-based access guard you could drop into a production app today. You'll also know exactly what to say when an interviewer asks about middleware pipelines.

What Laravel Middleware Actually Does Under the Hood

Laravel processes every request through a pipeline — a concept borrowed from Unix pipes. The pipeline takes your request object and passes it through a stack of middleware classes, one by one. Each middleware can inspect the request, modify it, short-circuit the whole pipeline by returning a response early, or pass the request down to the next middleware by calling $next($request).

This pipeline is powered by Illuminate\Pipeline\Pipeline and is assembled in your HTTP kernel (app/Http/Kernel.php). The kernel holds three lists: $middleware (global — runs on every request), $middlewareGroups (named collections like web and api), and $middlewareAliases (short names you attach to individual routes).

The key mental model is a Russian doll. Each middleware wraps the next one. When the innermost doll (your controller) produces a response, that response travels back outward through the same stack — meaning code written after $next($request) runs on the way out, not the way in. That's what makes 'before' vs 'after' middleware tick, and it's the thing almost everyone gets wrong the first time they build custom middleware.

<?php

// File: app/Http/Middleware/RequestLifecycleDemo.php
// Purpose: Illustrate exactly WHEN code runs relative to the next layer.

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;

class RequestLifecycleDemo
{
    public function handle(Request $request, Closure $next): mixed
    {
        // ─────────────────────────────────────────────────────────
        // BEFORE phase: runs BEFORE the request reaches the controller.
        // Perfect for: authentication checks, rate limiting, input sanitising.
        // ─────────────────────────────────────────────────────────
        Log::info('⬇ Middleware BEFORE — request arriving', [
            'url'    => $request->fullUrl(),
            'method' => $request->method(),
        ]);

        // Hand the request to the next layer (another middleware or the controller).
        // $response contains whatever that next layer ultimately returned.
        $response = $next($request);

        // ─────────────────────────────────────────────────────────
        // AFTER phase: runs AFTER the controller has built the response.
        // Perfect for: adding headers, logging response times, caching.
        // ─────────────────────────────────────────────────────────
        $response->headers->set('X-Processed-By', 'TheCodeForge');

        Log::info('⬆ Middleware AFTER — response leaving', [
            'status' => $response->getStatusCode(),
        ]);

        return $response; // Send the (possibly modified) response back up the stack.
    }
}

Creating Real-World Middleware — A Role-Based Access Guard

Let's build something you'd actually ship. Imagine a SaaS dashboard where certain routes are only accessible to users with an 'admin' role. We'll create an EnsureUserIsAdmin middleware that checks the authenticated user's role, redirects non-admins gracefully, and can be reused across any route with a single annotation.

Run php artisan make:middleware EnsureUserIsAdmin to generate the boilerplate, then fill in the logic. The generated file lands in app/Http/Middleware/. After writing the class, you register it in bootstrap/app.php (Laravel 11+) or app/Http/Kernel.php (Laravel 10 and earlier) so the framework knows it exists.

Notice what the middleware does NOT do: it doesn't query the database for permissions lists, it doesn't render any HTML, and it doesn't touch the controller. Each of those concerns stays separate. The middleware has one job — decide whether this user is allowed through — and it does exactly that job, then gets out of the way.

This single-responsibility design is what makes middleware so composable. Need to add a 'super-admin' bypass later? Add a second middleware and stack it. Need to log every admin access? Add a logging middleware. None of them need to know about the others.

<?php

// File: app/Http/Middleware/EnsureUserIsAdmin.php
// Run: php artisan make:middleware EnsureUserIsAdmin

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Symfony\Component\HttpFoundation\Response;

class EnsureUserIsAdmin
{
    public function handle(Request $request, Closure $next): Response
    {
        // If no one is logged in at all, send them to the login page.
        if (!Auth::check()) {
            return redirect()->route('login')
                ->with('status', 'Please log in to continue.');
        }

        // Auth::user() returns the currently authenticated User model.
        // We check a 'role' column on the users table — adjust to your schema.
        if (Auth::user()->role !== 'admin') {
            // Abort with 403 Forbidden and a clear reason.
            // This gets caught by Laravel's exception handler,
            // which renders your custom 403.blade.php if it exists.
            abort(403, 'You do not have permission to access this area.');
        }

        // User is an admin — let the request continue normally.
        return $next($request);
    }
}

// ─────────────────────────────────────────────────────────────────────────────
// REGISTRATION — Laravel 11+ style (bootstrap/app.php)
// ─────────────────────────────────────────────────────────────────────────────
// In bootstrap/app.php:
//
// use App\Http\Middleware\EnsureUserIsAdmin;
//
// ->withMiddleware(function (Middleware $middleware) {
//     $middleware->alias([
//         'admin' => EnsureUserIsAdmin::class,
//     ]);
// })

// ─────────────────────────────────────────────────────────────────────────────
// REGISTRATION — Laravel 10 style (app/Http/Kernel.php)
// ─────────────────────────────────────────────────────────────────────────────
// protected $middlewareAliases = [
//     'admin' => \App\Http\Middleware\EnsureUserIsAdmin::class,
// ];

// ─────────────────────────────────────────────────────────────────────────────
// USAGE IN ROUTES (routes/web.php)
// ─────────────────────────────────────────────────────────────────────────────

// routes/web.php
use Illuminate\Support\Facades\Route;
use App\Http\Controllers\AdminDashboardController;
use App\Http\Controllers\ReportController;

// Single route — only admins can view the dashboard.
Route::get('/admin/dashboard', [AdminDashboardController::class, 'index'])
    ->middleware('admin')
    ->name('admin.dashboard');

// Route group — apply 'admin' middleware to every route inside.
Route::prefix('admin')
    ->middleware('admin')
    ->name('admin.')
    ->group(function () {
        Route::get('/reports', [ReportController::class, 'index'])->name('reports');
        Route::get('/users',   [ReportController::class, 'users'])->name('users');
    });

Middleware Parameters and Chaining — Advanced Patterns You'll Actually Use

Hard-coding role checks inside middleware is fine for simple cases, but what if you have four roles — 'admin', 'editor', 'moderator', 'viewer'? You'd need four separate middleware classes. Middleware parameters solve this elegantly: you pass a dynamic value through the route definition, and your middleware receives it as an extra argument after $next.

Chaining is the other power move. You can stack multiple middleware on a single route, and they execute in left-to-right order. This lets you compose complex access rules from simple, reusable pieces — auth to check login, then verified to check email confirmation, then role:editor to check the role. Each piece stays independently testable.

Parameters and chaining together give you a tiny permissions DSL built right into your route file — readable, auditable, and requiring zero changes to controller code when your access rules change.

<?php

// File: app/Http/Middleware/EnsureUserHasRole.php
// A single middleware that handles ANY role via a parameter.

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Symfony\Component\HttpFoundation\Response;

class EnsureUserHasRole
{
    /**
     * @param string $requiredRole  — injected by Laravel from the route definition.
     *                                e.g. middleware('role:editor') sets $requiredRole = 'editor'
     * @param string ...$extraRoles — variadic: middleware('role:editor,moderator') passes both.
     */
    public function handle(
        Request $request,
        Closure $next,
        string  $requiredRole,
        string  ...$extraRoles    // Capture any additional roles passed after a comma.
    ): Response {
        // Merge the first role and any extras into one array for a clean in_array check.
        $allowedRoles = [$requiredRole, ...$extraRoles];

        $currentUserRole = Auth::user()?->role; // ?-> safely returns null if not authenticated.

        if (!in_array($currentUserRole, $allowedRoles, strict: true)) {
            abort(403, "Access requires one of: " . implode(', ', $allowedRoles));
        }

        return $next($request);
    }
}

// ─────────────────────────────────────────────────────────────────────────────
// REGISTRATION (bootstrap/app.php — Laravel 11+)
// ─────────────────────────────────────────────────────────────────────────────
// $middleware->alias([
//     'role' => \App\Http\Middleware\EnsureUserHasRole::class,
// ]);

// ─────────────────────────────────────────────────────────────────────────────
// USAGE — Chaining middleware on routes (routes/web.php)
// ─────────────────────────────────────────────────────────────────────────────
use Illuminate\Support\Facades\Route;
use App\Http\Controllers\ArticleController;
use App\Http\Controllers\AnalyticsController;

// Chain: user must be logged in AND have a verified email AND have the 'editor' role.
Route::get('/articles/create', [ArticleController::class, 'create'])
    ->middleware(['auth', 'verified', 'role:editor'])
    ->name('articles.create');

// Multiple roles allowed — editor OR moderator can access analytics.
Route::get('/analytics', [AnalyticsController::class, 'index'])
    ->middleware(['auth', 'role:editor,moderator'])
    ->name('analytics.index');

// Route group with shared middleware — every route here needs auth + admin role.
Route::middleware(['auth', 'role:admin'])
    ->prefix('admin')
    ->name('admin.')
    ->group(function () {
        Route::get('/settings', fn() => view('admin.settings'))->name('settings');
        Route::get('/billing',  fn() => view('admin.billing'))->name('billing');
    });

Testing Middleware in Isolation — Don't Skip This Step

Most developers test middleware indirectly by hitting a route and checking the response code. That works, but it makes your tests fragile — a controller change can break a middleware test for no good reason. Laravel's testing toolkit lets you test middleware directly by faking the request and injecting it into the middleware's handle method. This keeps your middleware tests fast, focused, and immune to controller-level changes.

The cleaner approach for route-level tests is $this->actingAs($user) combined with ->get('/route') and asserting the HTTP status code. For middleware unit tests, you can also use Route::fake() or test the middleware class directly with a Request and a closure that captures whether $next was called.

Pair middleware tests with Laravel's RefreshDatabase trait when the middleware queries the database (like a subscription check), and avoid it for pure logic checks (like a role string comparison) to keep your suite fast. Good middleware tests document your security rules better than any comment ever could.

<?php

// File: tests/Feature/Middleware/EnsureUserHasRoleTest.php
// Run: php artisan test --filter=EnsureUserHasRoleTest

namespace Tests\Feature\Middleware;

use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class EnsureUserHasRoleTest extends TestCase
{
    use RefreshDatabase; // Resets the DB between tests — important for user creation.

    /** @test */
    public function admin_user_can_access_admin_dashboard(): void
    {
        // Arrange: create a user with the 'admin' role using a factory state.
        $adminUser = User::factory()->create(['role' => 'admin']);

        // Act: simulate the admin making a GET request, fully authenticated.
        $response = $this->actingAs($adminUser)->get('/admin/dashboard');

        // Assert: the request passed through middleware and hit the controller.
        $response->assertStatus(200);
    }

    /** @test */
    public function editor_user_is_forbidden_from_admin_dashboard(): void
    {
        // Arrange: a regular editor — NOT an admin.
        $editorUser = User::factory()->create(['role' => 'editor']);

        // Act + Assert: expect the middleware to block with 403.
        $this->actingAs($editorUser)
             ->get('/admin/dashboard')
             ->assertStatus(403);
    }

    /** @test */
    public function guest_is_redirected_to_login_from_admin_dashboard(): void
    {
        // No actingAs() — simulates an unauthenticated guest.
        $this->get('/admin/dashboard')
             ->assertRedirect('/login');
    }

    /** @test */
    public function middleware_allows_multiple_roles_when_configured(): void
    {
        // Arrange: a moderator hitting the analytics route which allows editor,moderator.
        $moderator = User::factory()->create(['role' => 'moderator']);

        $this->actingAs($moderator)
             ->get('/analytics')
             ->assertStatus(200); // Moderator is in the allowed list — should pass.
    }
}

Excluding Middleware and Route Group Tricks — withoutMiddleware() and Middleware Priority

Sometimes you need a route inside a group to skip a middleware that the group applies. For example, an admin group might have 'auth' and 'role:admin', but a public login route inside that group shouldn't require authentication. Laravel's ->withoutMiddleware() method lets you exclude specific middleware from a route or group.

withoutMiddleware() is also useful when you're testing a route in isolation and don't want any global middleware interfering. Combined with route groups, it gives you fine-grained control over which requests pass through which gates.

Another advanced trick: middleware priority. Laravel allows you to define a $middlewarePriority array in your HTTP kernel to force the order of middleware (e.g., always run StartSession before Authenticate). This is rarely needed but valuable when you have middleware that depends on another's side effects (like sessions).

<?php

// routes/web.php
use Illuminate\Support\Facades\Route;
use App\Http\Controllers\Auth\LoginController;
use App\Http\Controllers\DashboardController;

// Admin group with auth and role:admin middleware
Route::middleware(['auth', 'role:admin'])
    ->prefix('admin')
    ->group(function () {
        // This route will NOT have the 'auth' and 'role:admin' middleware applied
        Route::get('/public-info', function () {
            return 'Public admin info - no auth required';
        })->withoutMiddleware(['auth', 'role:admin']);

        // Other routes in the group still use the group middleware
        Route::get('/dashboard', [DashboardController::class, 'index']);
    });

// ─────────────────────────────────────────────────────────────────────────────
// withoutMiddleware() also works for individual middleware:
// Route::get('/some-route', ...)->withoutMiddleware('auth');
//
// ─────────────────────────────────────────────────────────────────────────────
// Middleware Priority in app/Http/Kernel.php (Laravel 10+):
//
// protected $middlewarePriority = [
//     \Illuminate\Session\Middleware\StartSession::class,
//     \Illuminate\View\Middleware\ShareErrorsFromSession::class,
//     \App\Http\Middleware\Authenticate::class,
//     \Illuminate\Routing\Middleware\SubstituteBindings::class,
//     // ...
// ];
//
// This forces StartSession to always run before Authenticate, even if the order in
the route middleware array is different.

Middleware Execution Order: Why Your Filters Run in the Wrong Sequence

Most tutorials show you how to create middleware but never explain order. This is where bugs breed. Laravel runs middleware in a stack. Global middleware fires first, then route-specific middleware (in the order you assign them), and finally controller middleware. But here’s the kicker: the response runs in reverse. If your logging middleware runs before auth, you’ll log requests that fail authentication. Learn to control priority. In app/Http/Kernel.php, the $middlewarePriority array lets you reorder global middleware. I’ve seen teams spend hours debugging CORS issues caused by middleware order. Always put EncryptCookies before StartSession. Put Cors before ThrottleRequests if you need to return CORS headers on throttled responses. Test order explicitly in your route files. Don’t assume the stack is default-safe.

// Priority sorted list of middleware
protected $middlewarePriority = [
    \App\Http\Middleware\TrustProxies::class,
    \Illuminate\Http\Middleware\HandleCors::class,
    \Illuminate\Session\Middleware\StartSession::class,
    \App\Http\Middleware\LogRequest::class, // MUST come after session
    \Illuminate\Auth\Middleware\Authenticate::class,
];

Terminable Middleware: Run Cleanup After the Response Ships

Most middleware runs before or after the controller. But what about code that should execute after the response is already sent to the browser? Laravel’s terminable middleware runs during kernel termination. Use it for writing audit logs, flushing cache, or sending analytics without blocking the user. Define a terminate method on any middleware. Laravel calls it after the response is sent. This is not async — it’s synchronous but happens after headers are flushed. Perfect for heavy operations like image resizing or slow API calls. Benchmark your routes. If a middleware takes 200ms and you move it to terminate, the user sees the page in real-time while the server finishes work. Think of it as a deferred payload. I use this in payment systems to log receipts without slowing checkout.

<?php
namespace App\Http\Middleware;
use Closure;
use Illuminate\Http\Request;

class LogAfterResponse
{
    public function handle(Request $request, Closure $next)
    {
        return $next($request);
    }

    public function terminate($request, $response)
    {
        // Runs after response sent — user already sees page
        \Log::info('Request completed', [
            'status' => $response->getStatusCode(),
            'uri' => $request->fullUrl(),
            'time' => microtime(true) - LARAVEL_START,
        ]);
    }
}

Trusted Proxy Middleware: How to Stop Breaking Redirects Behind Load Balancers

Every Laravel app behind a proxy (Nginx, AWS ELB, Cloudflare) needs TrustProxies middleware. Without it, redirect()->back() sends users to http://localhost instead of your domain. The url() helper generates wrong scheme (http vs https). I’ve seen teams blame Laravel for broken login redirects when the fix was a single line. Open App\Http\Middleware\TrustProxies. Set $proxies to '*' if you trust all proxies (like Cloudflare), or list specific IPs. Configure $headers to Request::HEADER_X_FORWARDED_TRAFO for AWS. Test with dd(url('home')) before deploying. A misconfigured proxy middleware creates silent security holes — cookie theft via mixed content warnings. Trust me, this is the most overlooked middleware in production.

<?php
namespace App\Http\Middleware;

use Illuminate\Http\Middleware\TrustProxies as Middleware;
use Illuminate\Http\Request;

class TrustProxies extends Middleware
{
    protected $proxies = '*'; // Trust all proxies (Cloudflare, ELB)
    protected $headers =
        Request::HEADER_X_FORWARDED_FOR |
        Request::HEADER_X_FORWARDED_HOST |
        Request::HEADER_X_FORWARDED_PORT |
        Request::HEADER_X_FORWARDED_PROTO;
}

Laravel 11 Middleware Simplification

Laravel 11 introduces a streamlined middleware configuration that reduces boilerplate. Instead of defining middleware in app/Http/Kernel.php, you now register middleware directly in the bootstrap/app.php file using the ->withMiddleware() method. This change simplifies the bootstrap process and makes middleware registration more intuitive.

For example, to register global middleware in Laravel 11:

// bootstrap/app.php
use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Middleware;
return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        // ...
    )
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->append(\App\Http\Middleware\TrustProxies::class);
    })
    ->withExceptions(function ($exceptions) {
        // ...
    })->create();

Route-specific middleware groups are also defined here. For instance, to add middleware to the 'web' group:

->withMiddleware(function (Middleware $middleware) {
    $middleware->web(append: [
        EnsureUserIsSubscribed::class,
    ]);
})

This approach eliminates the need for a separate Kernel class, reducing cognitive load and potential misconfiguration. The Middleware class provides fluent methods like append, prepend, remove, and replace for managing middleware stacks.

Additionally, Laravel 11 removes several default middleware that were previously included in the web and api groups, such as TrimStrings and ConvertEmptyStringsToNull. You can re-add them if needed, but the defaults are now minimal, giving you more control.

This simplification is particularly beneficial for new projects, but existing projects upgrading to Laravel 11 can adopt it gradually. The old Kernel-based approach still works, but the new method is recommended for clarity and future compatibility.

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        // ...
    )
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->append(\App\Http\Middleware\TrustProxies::class);
        $middleware->web(append: [
            EnsureUserIsSubscribed::class,
        ]);
    })
    ->withExceptions(function ($exceptions) {
        // ...
    })->create();

TrustProxy and LoadBalancer Middleware for Production

When your Laravel application runs behind a load balancer or reverse proxy (like Nginx, AWS ELB, or HAProxy), the server's IP address is often the proxy's IP, not the client's. This breaks features like rate limiting, logging, and redirects that rely on the client's IP or scheme.

Laravel's TrustProxies middleware solves this by trusting specific proxies to forward accurate headers. In Laravel 11, you configure it in bootstrap/app.php:

``php ->withMiddleware(function (Middleware $middleware) { $middleware->trustProxies(at: '*'); }) ``

For more control, specify trusted proxies:

``php $middleware->trustProxies( proxies: ['192.168.1.1', '10.0.0.0/8'], headers: Request::HEADER_X_FORWARDED_FOR | Request::HEADER_X_FORWARDED_HOST | Request::HEADER_X_FORWARDED_PORT | Request::HEADER_X_FORWARDED_PROTO ); ``

In older Laravel versions, you set $proxies in app/Http/Middleware/TrustProxies.php. The * wildcard trusts all proxies, but be cautious—only use it if your proxy is fully trusted (e.g., in a private network).

Always test behind your load balancer. Use php artisan serve locally, but simulate proxy headers with tools like ngrok or by setting X-Forwarded-* headers in your local environment.

For production, explicitly list proxy IPs or use a CIDR range. Avoid trusting all proxies (*) on public-facing apps unless you have strict network controls.

->withMiddleware(function (Middleware $middleware) {
    $middleware->trustProxies(
        proxies: ['192.168.1.1', '10.0.0.0/8'],
        headers: Request::HEADER_X_FORWARDED_FOR | Request::HEADER_X_FORWARDED_HOST | Request::HEADER_X_FORWARDED_PORT | Request::HEADER_X_FORWARDED_PROTO
    );
})

Rate Limiter Middleware in Laravel

Laravel's rate limiter middleware protects your application from abuse by limiting the number of requests a user or IP can make in a given time window. It's built on the Illuminate\Cache\RateLimiter class and integrates seamlessly with the framework.

Define rate limiters in App\Providers\AppServiceProvider using the RateLimiter facade:

```php use Illuminate\Cache\RateLimiting\Limit; use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('api', function (Request $request) { return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip()); }); ```

Then apply the throttle middleware to routes:

``php Route::middleware('throttle:api')->group(function () { Route::get('/user', function () { // ... }); }); ``

You can also use named limiters directly:

``php Route::middleware(['throttle:api'])->get('/user', function () { // }); ``

For more granular control, create multiple limiters:

```php RateLimiter::for('uploads', function (Request $request) { return Limit::perMinute(5)->by($request->user()->id); });

RateLimiter::for('login', function (Request $request) { return Limit::perMinute(3)->by($request->ip()); }); ```

Apply them:

```php Route::post('/upload', function () { // })->middleware('throttle:uploads');

Route::post('/login', function () { // })->middleware('throttle:login'); ```

Rate limiters can return dynamic limits based on user roles or other conditions. For example, premium users get higher limits:

``php RateLimiter::for('api', function (Request $request) { $limit = $request->user()?->isPremium() ? 100 : 20; return Limit::perMinute($limit)->by($request->user()?->id ?: $request->ip()); }); ``

When a request exceeds the limit, Laravel returns a 429 Too Many Requests response with Retry-After header. You can customize the response by throwing a ThrottleRequestsException or using the throttle middleware's callback.

Rate limiting is essential for production APIs to prevent brute force attacks and ensure fair usage. Always test your limits under load.

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

public function boot(): void
{
    RateLimiter::for('api', function (Request $request) {
        return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
    });

    RateLimiter::for('uploads', function (Request $request) {
        return Limit::perMinute(5)->by($request->user()->id);
    });
}