Confused Deputy Problem

The confused deputy problem involves three parties: a caller, a privileged intermediary called the deputy, and a protected resource. The deputy legitimately has access to the resource, but the caller induces it to perform an action the caller should not be allowed to cause. The underlying failure is a missing connection between the caller’s authority and the deputy’s use of its own authority. This is an authorization problem, not necessarily credential theft or failed authentication.

Consider a monitoring provider that assumes IAM roles in many customers’ AWS accounts. A customer creates a role that trusts the provider’s AWS principal. If the provider accepts an arbitrary role ARN from its users without correctly binding that role to the requesting customer, an attacker might submit another customer’s role ARN. The provider could then assume the victim’s role using its legitimate identity. Knowing the ARN does not itself grant access; the vulnerability is the provider’s ability to exercise trusted access for the wrong customer.

For this third-party cross-account pattern, require a provider-generated external ID in the role trust policy using the sts:ExternalId condition key. The provider assigns a distinct external ID to each customer and supplies the appropriate value when calling AssumeRole. Its application must maintain the customer-to-external-ID association rather than allowing customers to impersonate another customer’s association. An external ID is not a password and need not be secret. It supplements, rather than replaces, a narrowly specified trusted principal and least-privilege role permissions.

A related pattern occurs when an AWS service accesses a resource on a customer’s behalf. Trusting only a service principal may allow requests associated with unintended accounts or resources. Where the integration supports them, use aws:SourceArn and aws:SourceAccount conditions to constrain the originating resource and its owning account. For example, an S3 bucket policy granting CloudTrail permission to deliver logs can restrict aws:SourceArn to the intended trail ARN. The source ARN identifies the originating resource, not the destination bucket. Condition-key availability and supported policy locations vary by integration, so do not assume every service request supplies every source key.

Role trust policies and permission policies solve different parts of the problem. The trust policy controls who can obtain a role session and under what conditions; the role’s permission policies constrain what that session can do. Resource policies constrain access at the destination. Broad permissions amplify the consequences of a confused deputy, but least privilege alone does not establish that a request belongs to the correct tenant. Similarly, IAM paths organize identities and can support explicit ARN-based policy scoping, but a path is not an independent security boundary.

Application-level authorization must preserve the same binding. A multitenant API can use Amazon Verified Permissions to evaluate whether an authenticated user may perform an action on a particular tenant’s resource. The application must derive trusted identity and tenant context, enforce the decision before exercising its backend role, and avoid trusting caller-supplied ownership claims. For external workloads using IAM Roles Anywhere, restrict role trust to intended trust anchors and appropriate certificate attributes. Possessing a valid certificate does not automatically establish authorization for every workload or tenant.

The main trade-off is precision versus operational flexibility. Exact source-resource restrictions provide strong isolation but require updates when resources are replaced; account-wide restrictions are easier to maintain but permit a wider set of sources. Missing condition keys can also break legitimate integrations. Test both valid and adversarial requests, including another tenant’s role ARN, an incorrect external ID, and an unexpected source resource. Authentication controls such as MFA, short-lived credentials, and certificate validation remain valuable, but none independently prevents a deputy from misusing legitimately acquired authority.