Authorization, Least Privilege, and Policy Design
Translate business permissions into explicit decisions about who can perform which action on which resource under which conditions.
In this lesson, you will learn to:
- Express an access decision as subject, action, resource, and context, then apply least privilege and default-deny reasoning.
Authorization, Least Privilege, and Policy Design
This lesson compares authorization models, shows why default deny and server-side enforcement matter, and guides learners through a practical permission design.
Authentication answers who; authorization answers what is allowed
A successful sign-in should not be treated as permission to do everything. Authorization evaluates whether a subject may perform a specific action on a specific resource in a particular context. Writing the decision this way exposes missing questions: may this person approve a payment, or only view it? May they act on every tenant, or only their own? Does the request come from an approved device or during an active incident?
Role-based access control groups permissions into job-oriented roles and is often easier to administer than individual grants. Attribute-based access control evaluates properties such as department, data classification, device posture, or project membership. Relationship-based approaches can be useful when access follows ownership or collaboration links. These models can be combined, but complexity should earn its keep; a policy nobody can explain or test creates hidden privilege.
Least privilege means granting only the access needed for the declared purpose, for the necessary period, with no broader scope. It is not simply a request to reduce permissions. Start with the business task and the minimum verbs and objects needed. Prefer read access over modification when that is sufficient, and scoped access over global access. Separate incompatible duties when one person could create and approve a high-impact outcome.
Enforce authorization on the server or trusted policy enforcement point for every relevant request. Hiding a button in a user interface is not authorization. A determined caller can alter a request, call an API directly, or reuse an endpoint. Default deny means that when the policy has no affirmative reason to allow an action, the action does not proceed.
Permission design needs tests, ownership, and boundaries
A permission catalog is useful only if it describes real capability. Define each permission in plain language: subject type, allowed action, resource scope, constraints, approving owner, and review trigger. For example, “Finance analyst may export monthly reports for assigned legal entities” is more testable than a role named “Finance Power User.”
Test both allowed and denied cases. A positive test confirms that an authorized analyst can export the assigned report. Negative tests confirm that the analyst cannot export another entity’s report, modify source transactions, or use a bypass endpoint. Include boundary cases: a user who moved teams, a record created after the permission was issued, a bulk request, an API call without the normal user interface, and an emergency role that has expired.
Beware permission accumulation. Adding roles over time is operationally easy, while removing obsolete grants takes investigation. Group nesting, inherited cloud permissions, and application-local roles can combine unexpectedly. Record the source of each high-impact entitlement and avoid routing all requests through a single powerful catch-all group just to simplify support.
Decisions also need owners. A platform team can operate the policy engine, but the business owner should decide what a role permits and when that role remains necessary. Security can set guardrails and review high-risk patterns. When these responsibilities are not explicit, teams tend to preserve access because no one feels authorized to remove it.
Resources
- OWASP Authorization Cheat Sheet — Use this application-security guidance to review server-side enforcement, deny-by-default behavior, and authorization testing.