Authorization turns an identity into a defined set of allowed actions. The rule may be simple, such as letting only an administrator invite users, or contextual, such as letting an account member edit records only inside that account. The important property is enforcement: every route to the action must reach the same decision.
Where permission gaps come from
A product interface hides controls that do not apply to the current user, but hidden controls are not authorization. The server must make the decision again when it receives the request. A user can call an API without using the intended screen, and a background job can reach data without passing through a browser at all.
Fast feature generation can scatter these checks. One handler verifies the account, another checks only that the user is logged in, and a newer endpoint trusts an identifier from the request. An audit of the generated system builds a single view of those decisions.
| Surface | Authorization question | Evidence |
|---|---|---|
| User interface | Is a control visible to the right role? | Renderovanie podľa roly |
| API route | Is the action allowed for this identity and record? | Server-side check |
| Background job | Which account or service owns the work? | Scoped job context |
| Admin tool | Are elevated actions distinct and recorded? | Explicit admin policy |
Identity is only the first step
Autentifikácia establishes who made the request. Authorization evaluates that identity against the requested action and resource. Treating a valid session as permission is a common structural mistake because it protects the route from anonymous access while leaving every logged-in account with the same reach.
An audit separates the inputs to the decision:
- Aktér: The user, service, or device making the request.
- Action: The operation being attempted, such as reading or deleting.
- Resource: The specific record, file, account, or configuration involved.
- Context: Ownership, role, organisation, workflow state, or another policy condition.
- Decision: The server-side rule that permits or refuses the action.
How an audit traces authorization
The review starts with sensitive actions and follows every route that can trigger them. It compares API handlers, direct object lookups, bulk operations, scheduled tasks, and internal tools. Threat modeling helps identify the actions whose failure would expose data or change critical state.
Tests matter when they cross boundaries rather than repeat successful examples. A useful permission test creates two distinct accounts, attempts the same action from each, and proves that access to one account does not imply access to the other. It also checks denied actions for side effects. A refusal that still writes part of a record is not a complete refusal.
What the audit produces
The result is a permission map tied to code paths. It records which policy should govern each sensitive action, where that policy is enforced, and which alternate path does something different. This makes remediation specific. The task is not to “improve security” in general, but to centralise or add the missing decision and verify it at every entry point.
That level of review is one part of the discipline that separates software built for production from a working prototype. The interface may look identical after repair. The difference is that the server now rejects actions the actor was never meant to perform.
