iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A confused deputy attack occurs when an attacker gets a more-privileged program or service to misuse its legitimate authority on the attacker’s behalf. The deputy fails to bind the request to the right caller, customer, target, or action, so the target may see only the trusted intermediary—not the person who initiated the request.
What is a confused deputy attack?
A confused deputy is an intermediary with authority that a less-privileged caller lacks. The caller supplies or manipulates a request, and the deputy carries it out using its own permissions without correctly checking whose request it is or what resource and operation the caller is entitled to use.
AWS defines the issue as one in which “an entity that doesn’t have permission to perform an action can coerce a more-privileged entity to perform the action” (AWS IAM User Guide: The confused deputy problem). The underlying failure is authorization and identity context, not simply the presence of a proxy or privileged service.
How does the attack work?
- A program or service has permission to access a resource or perform an operation.
- A less-privileged caller provides or manipulates an identifier, destination, customer context, or requested action.
- The intermediary forwards or executes the request using its own authority, without adequately validating the original caller and intended target.
- The target sees the trusted intermediary’s identity, allowing the operation to pass controls that would have blocked the caller directly.
MITRE describes this proxy pattern as a product receiving a request from an upstream component and forwarding it without preserving the original source. The intermediary can then appear to be the request’s origin. The weakness applies when the intermediary has different privileges, the attacker cannot make the request directly, and the attacker can induce a request the intermediary did not intend to forward (MITRE CWE-441: Unintended Proxy or Intermediary (‘Confused Deputy’)).
#1 Best Overall
What are common confused deputy examples in AWS?
Third-party cross-account role delegation
A customer can let a multi-tenant third-party service access AWS resources by giving it the ARN of an IAM role to assume. If one customer can cause the service to use another customer’s role ARN while processing the first customer’s request, the service may act on the other customer’s resources. The role ARN identifies the role; it is not a secret, so hiding it is not a reliable safeguard.
AWS’s mitigation is an external ID: the third-party service generates and controls a unique value for each customer, and the customer’s role trust policy requires that value when the service calls AssumeRole. The check ties role assumption to the intended customer context. An external ID is not a password or a replacement for least-privilege permissions and a correctly scoped trust policy (AWS IAM User Guide: The confused deputy problem).
AWS service access to a resource
AWS gives a CloudTrail-to-S3 example: a bucket policy that trusts the CloudTrail service principal without conditions may allow an unauthorized actor who knows the bucket name to configure CloudTrail to write logs there. The bucket sees a trusted AWS service principal, but the policy has not established which account or resource configured the service.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When granting a service principal access in a resource policy, AWS recommends applicable source-context conditions such as aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, or aws:SourceOrgPaths. Use the narrowest source identity that fits the integration. Support for these keys varies by service interaction, so check the specific service’s documentation before relying on a condition (AWS IAM User Guide: The confused deputy problem).
How the AWS examples differ
| Aspect | Third-party role delegation | AWS service access |
|---|---|---|
| Deputy | Multi-tenant third-party service | AWS service principal |
| Trust boundary | Delegation into a customer account | Service access to a resource |
| Context to bind | External ID tied to the intended customer | Source ARN, account, or organization context |
| Where the control is enforced | IAM role trust policy | Resource-based policy |
These controls address related but distinct context-binding problems: an external ID is for the third-party cross-account pattern, while source conditions constrain service-principal access to resources.
How can you prevent a confused deputy attack?
- Preserve the initiator’s identity. Carry the original caller’s identity through intermediary hops instead of replacing it with only the deputy’s identity. MITRE recommends keeping the initiator identity immutable and forwarding it to the target (MITRE CWE-441).
- Authenticate both parties. In an architecture that uses an intermediary, strongly authenticate the caller and the intermediary; the deputy’s identity alone does not prove the caller is authorized (MITRE CWE-441).
- Authorize the operation and target explicitly. Check whether the original caller may request this specific action on this specific resource, rather than assuming that a valid request from the deputy is sufficient.
- For third-party AWS role delegation, bind the customer context. Require the third-party service’s customer-specific external ID in the role trust policy, and keep the role’s permissions limited to what the service needs (AWS IAM User Guide).
- For AWS service principals, constrain the source. Add supported source-context conditions to the resource policy and choose a specific source ARN where the intended resource is known. Verify the relevant condition keys for that service integration (AWS IAM User Guide).
Is a confused deputy attack the same as SSRF?
No. Server-Side Request Forgery (SSRF), identified by MITRE as CWE-918, is a related and narrower case in which an attacker induces a server-side component to make requests the attacker cannot make directly. MITRE lists SSRF as a child entry of CWE-441 because some SSRF vulnerabilities use an intermediary as a proxy. Not every confused deputy attack involves SSRF; the broader problem is a privileged intermediary misusing its authority because it failed to preserve or validate the request’s originating context (MITRE CWE-441).
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Where did the term originate?
MITRE’s CWE-441 reference list cites Norm Hardy’s 1988 paper, “The Confused Deputy (or why capabilities might have been invented).” That is a historical attribution from MITRE’s reference list, not a claim that the original paper was reviewed here (MITRE CWE-441).
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
