Protect IAM Service Roles from Confused Deputy Attacks Using Proper Trust Policies
Why this matters
A confused deputy attack occurs when a trusted AWS service (the βdeputyβ) is tricked into performing actions on behalf of an untrusted principal. Without proper conditions in the trust policy of IAM service roles, malicious actors or external services might:
Exploit overly broad trust relationships
Use legitimate roles to escalate privileges
Gain unauthorized access to resources
Preventing this risk requires properly scoping trust policies, especially in roles assumed by AWS services like Lambda, S3, or Step Functions.
What this check does
This Auto Check examines IAM roles for:
Trust policies that do not include aws:SourceArn
or aws:SourceAccount
condition keys
Service principals that allow role assumption without context-bound restrictions
Overly permissive policies where no scoping is enforced
The check fails if service roles are found to be exposed to confused deputy vulnerabilities.
How to fix it
Update IAM trust policies for service roles to include source constraints.
From the AWS Console
Open the IAM Console.
Go to Roles and select each service role flagged in the check.
Edit the Trust Relationships tab.
Add Condition
blocks using:
"aws:SourceArn"
: Limits access to a specific resource (e.g., a specific Lambda or Step Function)
"aws:SourceAccount"
: Ensures only your AWS account can invoke the role
Save changes.
Trust policy example:
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function"
}
} }
Using AWS CLI
# View role trust policy
aws iam get-role --role-name <role_name>
# Update the trust policy file locally and apply it:
aws iam update-assume-role-policy --role-name <role_name> --policy-document file://updated-trust-policy.json
Exceptions
If a service does not support SourceArn
or SourceAccount
:
Restrict access using resource-based permissions or service control policies
Implement monitoring for abnormal role assumption behavior
Periodically review trust relationships for minimal exposure