Cybersecurity / Intermediate: operational defensive reasoning / Lesson 7

Authorization and least privilege

Turn account identity into narrow, reviewable permission decisions for subjects, resources, and actions.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Define deny-by-default access at the trusted boundary.
Review role, resource ownership, and service-account scope.

Describe the exact protected action

Authorization decides whether a validated subject may perform an action on a resource under current policy. A role name such as editor is only part of that decision: assignment, tenant, ownership, data sensitivity, and workflow state can matter. The learning portal may allow an editor to change assigned lessons but not learner identity records. Write the rule in plain language before implementation and default to denial when required context is missing. Do not trust a client-supplied role or a hidden button as the enforcement boundary. The server must evaluate the protected operation.

Model a narrow rule with negative cases

The pure example checks assignment for one fictional edit operation. It assumes the subject was authenticated through a trusted process and the lesson record came from trusted storage. Those assumptions are deliberately outside the function. The tests cover assigned editor, unrelated editor, and missing context so the rule cannot pass merely by allowing everyone. Real services must enforce the same policy at every relevant route, background job, export, and direct-object lookup. An isolated function test gives useful rule evidence but cannot prove the application actually calls it.

python A synthetic assignment rule and local checks

def may_edit(subject, lesson):
    if not subject or not lesson:
        return False
    return (subject.get("role") == "editor"
            and subject.get("id") in lesson.get("assignedEditors", []))

lesson = {"assignedEditors": ["lab-a"]}
assert may_edit({"id": "lab-a", "role": "editor"}, lesson)
assert not may_edit({"id": "lab-b", "role": "editor"}, lesson)
assert not may_edit(None, lesson)

No account or database is accessed. This is a complete in-memory teaching example, not production middleware. Tenant scope, delegated authority, and other actions need their own explicit rules and integration verification.

Give only the capability needed

Least privilege limits the actions, resources, duration, and conditions needed for a purpose. It applies to people, services, recovery accounts, and automation. Broad administration can make troubleshooting convenient while increasing the consequence of error or compromise. Separate ordinary use from privileged maintenance where the platform supports it, and make elevation accountable and time-bounded under policy. Do not distribute a shared administrator credential as a shortcut. Review permissions after role changes and project completion, and make temporary exceptions expire rather than accumulating permanent authority.

Keep an inspectable permission matrix

A permission matrix connects a subject category, resource scope, action, expected result, and evidence. The JSON below describes a test plan and grants nothing. Include both allowed and denied paths, including cross-account access and direct requests that bypass the interface. Keep machine-readable identifiers stable while translating human explanations. A real test environment should use synthetic accounts and owned records with cleanup and privacy limits. Changes to the matrix are policy changes that need review, especially when adding broad roles or new export operations.

json An application-defined permission test matrix

{
  "operation": "edit-lesson",
  "cases": [
    {"subject": "assigned-editor", "expected": "allow"},
    {"subject": "unassigned-editor", "expected": "deny"},
    {"subject": "anonymous", "expected": "deny"}
  ],
  "environment": "synthetic-offline-plan"
}

The cases are a planning artifact, not actual requests or identity-provider settings. Verification must later establish the trusted subject context and test the real enforcement boundary under explicit authorization.

Verify enforcement and explain denial safely

A denied action should leave protected state unchanged and avoid leaking private record details through error messages. Log enough bounded context for authorized investigation without storing tokens or unnecessary personal information. Review whether permission checks cover all paths and whether cached decisions remain valid after role or account changes. Test useful legitimate behavior too, because blocking everyone is not a correct access system. OWASP authorization guidance emphasizes least privilege, denial by default, and validation at each request. Applying these ideas requires context-specific design and evidence rather than a universal role table copied into every application.

Common errors and fixes

The interface hides a button but the action remains allowed

Why it happens: Client presentation substitutes for server enforcement.
How to fix it: Enforce the rule at the trusted operation boundary.
Prevent it next time: Test direct allowed and denied requests in an authorized environment.

A service account receives administrator access

Why it happens: Convenience replaced purpose-based scoping.
How to fix it: Review required actions and narrow authority through approved change.
Prevent it next time: Record owner, scope, and expiry.

A denied action still changes a record

Why it happens: Authorization is checked after side effects.
How to fix it: Move enforcement before protected mutation and verify atomic behavior.
Prevent it next time: Assert unchanged state in negative tests.

Check your understanding

1. An editor guesses another lesson id. What should protect the resource?

Show worked solution

The server checks current assignment and scope for the requested lesson regardless of how the id was obtained. Identifier obscurity is not permission. A rejected request should not reveal private content or alter state.

2. A rule test allows all assigned editors. What additional evidence is needed?