How to Prevent Authorization Vulnerabilities

The direct defense against client-side authorization flaws is simple: every authorization decision must be enforced by the server.

The client may tell the server what it wants to do:

POST /api/users/4522/delete

But it must never be allowed to determine whether it is permitted to do it.

For example:

{
  "role": "admin"
}

The server should never simply trust that value:

Client says: role = admin
        ↓
Server trusts it
        ↓
Privilege escalation ✗

Instead, the server should establish the requester's actual privileges from trusted authentication state:

Session / validated token
        ↓
Identify user
        ↓
Determine trusted role / permissions
        ↓
Evaluate requested action
        ↓
Allow or deny

For example:

$user = User::findOrFail($session->user_id);

if ($user->role !== 'admin') {
    abort(403);
}

The important distinction is:

Client-controlled role
→ untrusted input

Server-validated identity + permissions
→ trusted authorization basis

This applies regardless of what the UI does:

Admin button visible
→ not authorization

Admin button hidden
→ not authorization

JavaScript says user is admin
→ not authorization

Server verifies permission
→ authorization

The client can request an action, but only the server can decide whether the authenticated user is authorized to perform it.

test

test

test

test