Authorization: gates and policies

A Pathshala guardian may read their own child’s fees but not another family’s; a teacher may edit students at their own centre but not another centre’s; only the owner may delete a record. Authentication proved who the user is, which the earlier lessons covered; authorization decides what that user may do, and Laravel answers it in two shapes.

A gateauthorization gate: A closure, registered with Gate::define, that answers yes or no to an ability such as opening a staff back office; it always receives the user first and may take more arguments, such as a model. is a closure that takes the user and returns yes or no for an app-wide ability, such as opening the staff back office. A policyauthorization policy: A class whose methods each answer one ability for a model, receiving the user and, for abilities about one record, that model instance; Laravel finds it by convention from the model's name. is a class whose methods answer questions about one model: may this user view, update or delete this student? The first two sections build both and print a runnable matrix of who may do what. Later parts add an owner override and the choice between a 403 and a 404. They also close the slip that lets a guardian read another child’s report card by changing a number in the URL.

Gates for app-wide abilities, policies for a model

Reach for a gate when the question has no model behind it. Gate::define('access-admin-area', fn (User $user) => ...) sits in a service provider’s boot method, and Gate::allows('access-admin-area') (or Gate::forUser($user)->allows(...)) answers it anywhere. Each ability is one closure, and Laravel always passes it the user first; a gate may take more arguments, such as a model, but the staff-area question needs none. This is the gate the matrix below asks:

<?php

namespace App\Providers;

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

class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
    }

    public function boot(): void
    {
        // An app-wide ability that is not tied to one model: may this user open
        // the staff back office at all? A gate always receives the user first
        // (it may take more arguments) and returns a bool. Questions about one
        // record ("edit THIS student") go in StudentPolicy instead.
        Gate::define('access-admin-area', function (User $user): bool {
            return in_array($user->role, ['owner', 'teacher', 'accountant'], true);
        });
    }
}

Reach for a policy when the question is about one record. php artisan make:policy StudentPolicy --model=Student generates a class with a method per ability, and Laravel finds it by convention: App\Policies\StudentPolicy is the policy for App\Models\Student, so no registration is needed. A method such as update receives the user and the model instance, which is exactly what a per-record decision needs. Answer the table’s one question for a check of your own:

A policy by convention, and four ways to call it

A policy method answers one ability by comparing the model’s columns against the user asking. StudentPolicy::update returns true only when the user is a teacher whose centre_id equals the student’s; the id in the URL never decides. This is the whole class the matrix asks, one method per ability:

<?php

namespace App\Policies;

use App\Models\Student;
use App\Models\User;

// Discovered by convention: App\Policies\StudentPolicy is the policy for
// App\Models\Student, so $user->can('update', $student) and
// Gate::authorize('update', $student) both land here. Each method answers one
// ability by comparing the student's columns against the user asking.
class StudentPolicy
{
    // Only staff see the student list; a guardian has no "list every student".
    public function viewAny(User $user): bool
    {
        return in_array($user->role, ['teacher', 'accountant'], true);
    }

    // Staff see students of their own centre; a guardian sees only their child.
    public function view(User $user, Student $student): bool
    {
        if (in_array($user->role, ['teacher', 'accountant'], true)) {
            return $user->centre_id === $student->centre_id;
        }

        return $user->role === 'guardian' && $user->id === $student->guardian_id;
    }

    // A teacher of the student's own centre may edit the record; nobody else.
    public function update(User $user, Student $student): bool
    {
        return $user->role === 'teacher' && $user->centre_id === $student->centre_id;
    }

    // Deleting a student is reserved for the centre owner, whom this policy does
    // not know yet; no ordinary role may delete.
    public function delete(User $user, Student $student): bool
    {
        return false;
    }
}

The same policy is reached from four places: Gate::authorize('update', $student) in a controller, $user->can('update', $student) in any PHP, the can:update,student middleware on a route, and @can('update', $student) in a Blade view. Older code often calls $this->authorize() instead, a helper that comes from the AuthorizesRequests trait. The base controller of a new Laravel 13 app is an empty class without that trait, so the documented call is the Gate facade. Follow one edit request from the URL to the policy and back:

The runnable matrix seeds three users at centre 1 and three students across two centres, then prints the gate’s answer for each user and the policy’s view, update and delete answers for every student. It is the evidence a plain description cannot give: the exact allow and deny for real rows.

from session import run

# Seeds three users of centre 1 and three students across two centres, then
# prints the app-wide gate's answer for each user and the StudentPolicy's answer
# for every role, ability and student, so the allow/deny matrix is visible on
# real seeded data.
run(
    """
php policy_matrix.php
""",
    app=True,
    overlay=("policy-probe",),
)

$ php policy_matrix.php
The gate 'access-admin-area', asked with Gate::forUser($user)->allows():
  teacher     ALLOW
  accountant  ALLOW
  guardian    DENY

StudentPolicy, asked about three students:
  A = Aarav, centre 1, the guardian's own child
  B = Diya, centre 1, another family's child
  C = Imran, centre 2, another centre

teacher (centre 1)
  view    A ALLOW   B ALLOW   C DENY
  update  A ALLOW   B ALLOW   C DENY
  delete  A DENY    B DENY    C DENY

accountant (centre 1)
  view    A ALLOW   B ALLOW   C DENY
  update  A DENY    B DENY    C DENY
  delete  A DENY    B DENY    C DENY

guardian (Aarav's parent)
  view    A ALLOW   B DENY    C DENY
  update  A DENY    B DENY    C DENY
  delete  A DENY    B DENY    C DENY

A teacher may view and edit both centre-1 students and nothing at centre 2; an accountant may view them but never edit; a guardian may view only Aarav, their own child. Deleting is refused to every role, even a teacher at the student’s own centre. The @can directive hides the edit link from a user who may not use it, but hiding a button is a convenience, never the control; the guard in the controller or route is what refuses the request.

{{-- The @can directive asks the same policy a controller would, so a button is
     shown only to a user who may use it. The guard in the controller or route
     is still required: hiding a button is a convenience, never the control. --}}
@can('update', $student)
    <a href="{{ route('students.edit', $student) }}">Edit this student</a>
@endcan

@cannot('update', $student)
    <p>You can view this student but not edit them.</p>
@endcannot

{{-- For an app-wide ability with no model, name the gate: --}}
@can('access-admin-area')
    <a href="{{ route('admin.dashboard') }}">Staff dashboard</a>
@endcan

A form request moves the check next to the rules: its authorize method runs before validation, so a request from the wrong user is a 403 before a single field is examined.

<?php

// A form request can carry the authorization check next to the rules. authorize()
// runs before validation; returning false (or a denied Response) answers 403
// before a single rule is checked, so a request from the wrong user never
// reaches the controller.

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UpdateStudentRequest extends FormRequest
{
    public function authorize(): bool
    {
        // route('student') is the bound model; $this->user() is the signed-in user.
        return $this->user()->can('update', $this->route('student'));
    }

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

A super-admin override, and choosing between a 403 refusal and a 404 that hides a record Pro: opens with a Pro, Premium or Ultimate pass

How route model binding becomes an IDOR, and the negative tests that catch it Pro: opens with a Pro, Premium or Ultimate pass

Practise

Build the authorization layer on your own Pathshala project:

1. Write StudentPolicy with view, update and delete, discovered by convention, and a Gate::define('access-admin-area', ...) for the staff area. Prove the matrix with a test that seeds a teacher, an accountant and a guardian.
2. Wrap the edit link of a student page in @can('update', $student), then send the update request directly as the accountant and confirm that Gate::authorize in the controller still answers 403.
3. Move the same check into a form request’s authorize method and confirm that the wrong user gets a 403 before any validation error appears.

Then test yourself with the questions below.

Interview questions

Each of these asks for a decision and its defence, as an interviewer would:

Key takeaways

• A gate is one closure for an app-wide ability that receives the user first; a policy is a class, found by convention from the model name, whose methods receive the user and, for a check on one record, that model instance.
• A policy method decides from the record’s own columns, such as a matching centre_id, and never from the id in the URL.
• Call a policy with Gate::authorize in a controller, $user->can in any PHP, the can middleware on a route, @can in Blade or can inside a form request’s authorize method, and every one of them reaches the same class.
• Hiding a button with @can is a convenience; the authorization call in the controller or the route is what refuses the request.