Home / Knowledge hub / Server-side authorisation
Knowledge hub
Server-side authorisation
Enforcing permissions on the server, because hiding a button in the page protects nothing.
What it means
Server-side authorisation means the server decides, on each request, whether the caller may do what they asked. The page can hide buttons and menus for convenience, but the decision that counts is made where the user cannot change the code.
Anything running in the browser or app is under the user's control. They can edit the page, replay requests, call the API directly or use a tool that sends requests with no interface at all. A rule that exists only in that code is a hint, not a control.
Why it matters
A great many access-control bugs are one mistake: the interface hides a function and the server trusts that. The ordinary user who finds the request can use the admin action. CWE lists this pattern as client-side enforcement of server-side security.
It also makes testing meaningful. A security test that clicks through the interface sees only what the interface allows. If the real rules are on the server, they need to be tested by sending requests straight to it. That is why server rules need direct requests to test them.
How it shows up
You meet it in role checks, ownership checks and tenant checks, in the code that runs before any data is read or changed. Good designs put the check in one shared place, such as middleware, a policy layer or the database, so that a new route is covered by default.
Warning signs: a role stored in a cookie or token that the server does not verify, isAdmin flags sent from the client, checks in JavaScript only, an API that trusts a userId in the body, and authorisation done at login but never again. Apply a deny-by-default rule.
Questions people ask
Server-side authorisation, answered
Is it wrong to hide buttons from users who cannot use them?
No, it is good design and reduces confusion. It is just not security. The server must also refuse the request.
What is the difference from authentication?
Authentication checks who you are. Server-side authorisation checks what you may do. Both must happen on the server.
Can we trust a role claim in a token?
Only if the token is verified and issued by you, and its claims are kept up to date. A role that can be edited by the client, or that outlives a change in permission, is a risk.
Where is the best place to put the checks?
In a shared layer that every route passes through, so a developer cannot forget it. Add object-level checks close to the data access for records and tenants.
How do we test it?
Call the API directly with accounts of different levels and with no session, and compare to the rules you intended. A request the interface would never send is the one to try.
Sources
Where this comes from
Related
Terms that sit next to this one
Authorization
Deciding what a proven user is then allowed to do.
Broken access control
An application failing to enforce its own rules about who may do what.
Deny by default
Refusing every request unless a rule explicitly allows it.
Missing function-level access control
A sensitive action that checks you are signed in but not whether you may use it.
Ownership check
Confirming that the record being requested belongs to the account asking for it.
Does the server say no on its own?
We send requests your interface would never send and report which ones the server wrongly accepted, with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.