Laravel Authorization with Gates and Policies: Before Hooks, Form Requests, @can and Testing

The security report was two lines long: "Changing the post ID in PUT /api/posts/{id} lets any logged-in user edit any post." The web controller had the check, if ($post->user_id !== auth()->id()) abort(403);, copied by hand. The API controller, written six months later by someone else, did not. Neither did the bulk-publish action in the admin panel. Every new rule ("editors can edit any post in their team", "nobody edits a published post after 24 hours") had to be patched into fourteen places, and the fifteenth place is always the one that leaks data.

Laravel already has the answer: Gates and Policies. They move every "is this user allowed to do this?" decision into one place, give it a name, and let controllers, Form Requests, routes, Blade and tests all ask the same question the same way. The hard part is not the API; it is using it consistently and knowing its sharp edges.

Gates vs Policies

Both answer the same question, they just organise it differently:

• A Gate is a named closure, usually defined in AppServiceProvider::boot(). Good for abilities that are not about one model: "view the reports dashboard", "access Horizon", "impersonate users".
• A Policy is a class grouping the abilities for one model: PostPolicy::view, update, delete and so on. Good for anything that involves a specific record.

Under the hood, policies are registered with the same Gate service. Gate::allows('update', $post) looks at the type of $post, finds PostPolicy, and calls PostPolicy::update($user, $post). That is why $user->can(...), @can, Gate::authorize(...) and route ->can(...) all work identically with both.

How a Check Is Resolved

The order matters. Before callbacks run first and can short-circuit everything: return true to allow, false to deny, null to say "no opinion, continue". Then the policy method (or gate closure) decides. If the user is a guest and the method's $user parameter is not nullable, Laravel denies without even calling it. A missing policy method also means deny. Laravel fails closed, which is the behaviour you want.

Writing a Policy

Generate it with php artisan make:policy PostPolicy --model=Post. Since Laravel 11, policies in App\Policies named after a model in App\Models are discovered automatically, so there is nothing to register.

namespace App\Policies;

use App\Models\Post;
use App\Models\User;
use Illuminate\Auth\Access\Response;

class PostPolicy
{
    public function viewAny(?User $user): bool
    {
        return true;
    }

    public function view(?User $user, Post $post): Response
    {
        if ($post->published_at !== null) {
            return Response::allow();
        }

        return $user?->id === $post->user_id
            ? Response::allow()
            : Response::denyAsNotFound();
    }

    public function create(User $user): bool
    {
        return $user->hasVerifiedEmail();
    }

    public function update(User $user, Post $post): Response
    {
        if ($user->id !== $post->user_id && ! $user->isEditorOf($post->team_id)) {
            return Response::deny('You can only edit your own posts.');
        }

        if ($post->published_at?->lt(now()->subDay())) {
            return Response::deny('Published posts are locked after 24 hours.');
        }

        return Response::allow();
    }

    public function delete(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }

    public function restore(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }

    public function forceDelete(User $user, Post $post): bool
    {
        return false;
    }
}

A few choices in there are deliberate:

• ?User $user on viewAny and view lets guests through to the method. Without the ?, guests are denied automatically.
• Response::denyAsNotFound() returns a 404 instead of a 403 for drafts. A 403 confirms that a draft with that ID exists, which is itself an information leak.
• Response::deny('...') carries a message that ends up in the 403 response and in Gate::inspect(), which is far more useful than a bare false when support asks why an editor cannot save.
• forceDelete returns false for everyone; the before hook below lets admins through.

Before Hooks: Super Admins Without Polluting Every Method

Admins usually can do everything. Writing || $user->isAdmin() in every method is noise and easy to forget. Use a before hook instead, either per policy or globally.

namespace App\Providers;

use App\Models\User;
use Illuminate\Support\Facades\Gate;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Gate::before(function (User $user, string $ability): ?bool {
            return $user->is_super_admin ? true : null;
        });

        Gate::define('view-reports', function (User $user): bool {
            return $user->hasRole('finance') || $user->hasRole('manager');
        });
    }
}

The single most important detail: return null, not false, when the hook has no opinion. Returning false denies every ability for every non-admin user, and that bug usually ships because the developer testing it was an admin.

A policy can also define public function before(User $user, string $ability): ?bool. It runs only for that policy, and only if the policy actually has a method for the ability being checked. Use it for rules like "banned users can do nothing with posts".

Where to Authorize

Authorize as close to the entry point as possible, and pick one style per entry point so reviewers know where to look.

In a controller, call Gate::authorize(). It throws AuthorizationException, which Laravel renders as 403 (or 404 for denyAsNotFound). Laravel 11+ controllers no longer extend a base class with AuthorizesRequests, so $this->authorize() only works if you add that trait yourself; the facade always works.

namespace App\Http\Controllers;

use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Support\Facades\Gate;

class PostPublishController
{
    public function __invoke(Post $post): RedirectResponse
    {
        Gate::authorize('update', $post);

        $post->update(['published_at' => now()]);

        return to_route('posts.show', $post);
    }
}

When a Form Request already validates the input, its authorize() method is the natural place. It runs before validation, so unauthorized users do not even learn which fields are invalid.

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UpdatePostRequest extends FormRequest
{
    public function authorize(): bool
    {
        return $this->user()->can('update', $this->route('post'));
    }

    public function rules(): array
    {
        return [
            'title' => ['required', 'string', 'max:200'],
            'body' => ['required', 'string'],
        ];
    }
}

For simple cases, authorize on the route itself: Route::put('/posts/{post}', UpdatePostController::class)->can('update', 'post');. For abilities without a model instance, pass the class: ->can('create', Post::class).

In Blade, @can hides buttons users cannot use. That is a UX feature, not security: the server-side check must exist anyway.

@can('update', $post)
    <a href="{{ route('posts.edit', $post) }}">Edit</a>
@endcan

@cannot('delete', $post)
    <p class="text-sm text-gray-500">Only the author can delete this post.</p>
@endcannot

Testing Policies

Test policies at two levels. Unit-style tests call the policy through the gate so before hooks are included; feature tests prove that the endpoint actually enforces it. The second kind is what catches the forgotten API controller.

use App\Models\Post;
use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;

uses(RefreshDatabase::class);

it('lets authors update their own posts', function () {
    $author = User::factory()->create();
    $post = Post::factory()->for($author)->create(['published_at' => null]);

    expect($author->can('update', $post))->toBeTrue();
});

it('forbids other users from updating a post', function () {
    $post = Post::factory()->create();
    $stranger = User::factory()->create();

    expect($stranger->can('update', $post))->toBeFalse();

    $this->actingAs($stranger)
        ->putJson("/api/posts/{$post->id}", ['title' => 'Hacked', 'body' => 'x'])
        ->assertForbidden();
});

it('hides drafts from other users with a 404', function () {
    $draft = Post::factory()->create(['published_at' => null]);

    $this->actingAs(User::factory()->create())
        ->getJson("/api/posts/{$draft->id}")
        ->assertNotFound();
});

it('lets super admins force delete through the before hook', function () {
    $admin = User::factory()->create(['is_super_admin' => true]);
    $post = Post::factory()->create();

    expect($admin->can('forceDelete', $post))->toBeTrue()
        ->and(User::factory()->create()->can('forceDelete', $post))->toBeFalse();
});

A useful habit: for every route that takes a model, write one "stranger gets 403/404" test. It is cheap, and it is exactly the test that would have caught the original IDOR.

Common Pitfalls

• Returning false from a before hook. It denies everything for everyone the hook does not explicitly allow. Return null to fall through.
• Authorizing in the view only. @can hides a button; the endpoint is still reachable with curl.
• Assuming policies filter queries. PostPolicy::view does not stop Post::all() from returning other users' drafts. List endpoints need query scopes (->whereBelongsTo($user)) that mirror the policy rules.
• Forgetting guests. A non-nullable User $user means guests are always denied, which is right for writes but wrong for public pages.
• Calling $this->authorize() in a Laravel 11+ controller. Without the AuthorizesRequests trait it is an undefined method. Use Gate::authorize() or add the trait.
• 403 that reveals existence. For private resources, prefer denyAsNotFound().
• Business rules leaking into controllers again. If a check needs the user and the model, it belongs in the policy, even if it is "just one line".

When to Use Gates, Policies, or Neither

• Use a policy for anything about a specific model or model type: CRUD, publish, archive, export one record.
• Use a gate for app-wide abilities with no model: dashboards, admin tools, feature access by role.
• Use a before hook for cross-cutting overrides like super admins or banned users, and keep it to a few lines.
• Do not use either for validation ("title must be unique") or for data scoping on lists; those belong to Form Request rules and query scopes.
• For complex role and permission matrices managed in the database, a package like spatie/laravel-permission can feed into the same gate, so $user->can() keeps working everywhere.

The real win is not syntax; it is that "who can edit a post?" has exactly one answer in the codebase, and every entry point, view and test asks that same answer.