Security Guides

When your system acts with the wrong person’s authority

Estimated Reading Time =

3 minutes

Technical Level =

Advanced

Threat Level =

Medium

Attack Type =

Other

Editorial illustration for when your system acts with the wrong person's authority

What you will learn

What you will learn

A service may have more access than the person asking it to act. It must check the caller’s authority before using its own powerful identity on that person’s behalf.

Sometimes a service performs an action using its own powerful identity after a less privileged user requests it. The security question is whether the user was entitled to that particular result. A trusted service must not accidentally lend its authority to a person who lacks permission.

Understand the idea

Follow the requesting user through the whole operation. The service should check who asked, which record or destination is involved, and whether the action is allowed for that user. Permission for the service account alone does not establish permission for the person using the feature.

A simple way to follow the process
  1. Caller

    A user asks the service to perform an operation.

  2. Deputy

    The service acts with its own permissions.

  3. Check

    Bind the requested action and resource to the caller’s allowed scope.

A practical example

Imagine a report generator that can read every department’s data. A staff member asks it for a report. The generator must limit the result to that person’s authorized department rather than relying on its own broad database access.

Visual guide: When your system acts with the wrong person's authority
A user asks the service to perform an operation. The service acts with its own permissions. Bind the requested action and resource to the caller’s allowed scope.

What to do next

  1. Identify the original caller, the resource, the action, and the business or tenant context.
  2. Derive sensitive authority context from trusted server-side records rather than accepting arbitrary client claims.
  3. Constrain the deputy's own permissions to the resources and operations its role needs.
  4. Carry the required authorization context across queues and service boundaries, and re-evaluate it at the point of action as appropriate.
  5. Log the initiating identity and effective service identity without exposing passwords and access keys or unnecessary data.

How to check the result

Test with users from different roles and groups in an approved environment. Record the expected result for each request and confirm that the service refuses requests outside the user’s authority.

Our worker can read every customer’s data. Is checking the caller once enough?

Authorization must cover the actual operation and requested resource. The worker’s broad identity must not silently turn a limited user request into broader access.

Sources and useful guides

The following resources provide background and more detailed guidance. Use the sections that match your service and situation.

Scroll to Top