What Is Authorization?

Authorisation determines what an authenticated party may do. It is the step after authentication, and it is where the serious application vulnerabilities live.

The reason is structural. Authentication is a solved problem with well-tested libraries and protocols. Authorisation is application-specific logic — nobody can write a library that knows whether this user should see that record — so every application implements it, and many implement it incompletely.

The two failure modes

Broken object-level authorisation is the dominant one. The system correctly identifies the caller and then fails to check whether that caller should reach the specific object requested. Change an identifier in a request, receive someone else's record.

Broken function-level authorisation is the other: an ordinary user reaches an administrative function because the interface hid the button rather than the server refusing the call.

Both share a cause. The check was implemented where the developer was thinking about the user experience rather than where the decision is enforced.

Why tools cannot find these

A scanner can detect a missing authentication check because unauthenticated access is observable. It cannot detect a missing authorisation check, because it does not know that account 4471 should not be readable by the token belonging to account 3902. That requires understanding what the identifier means in your business.

Consequently these are found by people testing deliberately — authenticating as a low-privilege user and attempting to reach another user's data, endpoint by endpoint, role by role.

Centralise the decision, not the logic

Authorisation checks scattered through application code diverge over time. One endpoint checks ownership, another checks role, a third was added later and checks nothing, and no one can enumerate which is which.

The pattern that scales is a single authorisation component every request passes through — a middleware layer, a policy service, a framework hook — so the check is structural rather than remembered. Endpoints then declare what they require and the decision is made consistently in one place.

That also makes the property testable: you can enumerate every endpoint and confirm each declares a requirement, which is impossible when the logic is distributed through handlers.

Elevation and delegation need explicit handling

Two patterns cause recurring problems. Elevation — a user temporarily acting with higher privilege — needs a defined scope, a time limit and a record, or it becomes a permanent grant nobody revisits.

Delegation, where one user acts on another’s behalf, is common in healthcare, finance and support contexts and frequently implemented as simply using the other account. That destroys attribution: the log shows the patient’s record was accessed by the delegating user, not by the person actually doing it.

Proper delegation records both identities, which matters enormously when the question later becomes who looked at what.

The thing most worth getting right

Where to start

Take one endpoint that returns a record by identifier, authenticate as a test user, and request a record belonging to someone else. It is a five-minute test for the most consequential flaw class in applications.

See API security. GuardsArm delivers application penetration testing.