Troubleshoot access denied (403 Forbidden) errors in Amazon S3
Access denied (HTTP 403 Forbidden) errors appear when AWS explicitly or
implicitly denies an authorization request.
-
An explicit denial occurs when a policy contains a
Denystatement for the specific AWS action. -
An implicit denial occurs when there is no applicable
Denystatement and also no applicableAllowstatement.
Because an AWS Identity and Access Management (IAM) policy implicitly denies an IAM principal by default, the policy must explicitly allow the principal to perform an action. Otherwise, the policy implicitly denies access. For more information, see The difference between explicit and implicit denies in the IAM User Guide. For information about the policy evaluation logic that determines whether an access request is allowed or denied, see Policy evaluation logic in the IAM User Guide.
For more information about the permissions to S3 API operations by S3 resource types, see Required permissions for Amazon S3 API operations.
The following topics cover the most common causes of access denied errors in Amazon S3.
Note
For access denied (HTTP 403 Forbidden) errors, Amazon S3 doesn't charge the
bucket owner when the request is initiated outside of the bucket owner's individual
AWS account or the bucket owner's AWS organization.
Topics
Note
If you're trying to troubleshoot a permissions issue, start with the Access denied message examples and how to troubleshoot them section, then go to the Bucket policies and IAM policies section. Also be sure to follow the guidance in Tips for checking permissions.
Access denied message examples and how to troubleshoot them
Amazon S3 now includes additional context in access denied (HTTP 403 Forbidden) errors
for requests made to resources within the same AWS account or same organization in AWS Organizations. This
context includes the type of policy that denied access, the reason for denial, and information about the
IAM user or role that requested access to the resource.
With this additional context, you can troubleshoot access issues, identify the root cause of access denied errors, and fix incorrect access controls by updating the relevant policies. This additional context is also available in AWS CloudTrail logs. Enhanced access denied error messages for same-account or same-organization requests are available in all AWS Regions, including the AWS GovCloud (US) Regions and the China Regions.
For explicit deny cases, the error message also includes the Amazon Resource Name (ARN) of the specific policy that denied the request. With this policy ARN, you can quickly identify the exact policy responsible for the denial and navigate directly to it to make the necessary changes. The error message includes the policy ARN for Service Control Policies (SCPs), resource control policies (RCPs), identity-based policies, session policies, and permissions boundaries.
Most access denied error messages appear in the format User
. In this example,
user-arn is not authorized to perform
action on "resource-arn"
because context is the Amazon Resource Name
(ARN) of the user that doesn't receive access,
user-arn is the service action that the
policy denies, and action is the ARN of
the resource on which the policy acts. The
resource-arn field represents additional context
about the policy type that explains why the policy denied access.context
When a policy explicitly denies access because the policy contains a Deny
statement, then the access denied error message includes the phrase with an
explicit deny in a , along with
the ARN of the specific policy that denied the request. When the policy
implicitly denies access, then the access denied error message includes the phrase
type policybecause no .type policy allows the
action action
Important
-
Enhanced access denied messages are returned only for same-account requests or for requests within the same organization in AWS Organizations. Cross-account requests outside of the same organization return a generic
Access Deniedmessage.For information about the policy evaluation logic that determines whether a cross-account access request is allowed or denied, see Cross-account policy evaluation logic in the IAM User Guide. For a walkthrough that shows how to grant cross-account access, see Example 2: Bucket owner granting cross-account bucket permissions.
-
For requests within the same organization in AWS Organizations:
-
Enhanced access denied messages aren't returned if a denial occurs because of a virtual private cloud (VPC) endpoint policy.
-
Enhanced access denied messages are provided whenever both the bucket owner and the caller account belong to the same organization in AWS Organizations. Although buckets configured with the S3 Object Ownership Bucket owner preferred or Object writer settings might contain objects owned by different accounts, object ownership doesn't affect enhanced access denied messages. Enhanced access denied messages are returned for all object requests as long as the bucket owner and caller are in the same organization, regardless of who owns the specific object. For information about Object Ownership settings and configurations, see Controlling ownership of objects and disabling ACLs for your bucket.
-
-
Enhanced access denied error messages aren't returned for requests made to directory buckets. Directory bucket requests return a generic
Access Deniedmessage. -
If multiple policies of the same policy type deny an authorization request, the access denied error message doesn't specify the number of policies.
-
For explicit deny cases, the error message includes the ARN of the specific policy that denied the request. This applies to Service Control Policies (SCPs), resource control policies (RCPs), identity-based policies, session policies, and permissions boundaries.
-
If multiple policy types deny an authorization request, the error message includes only one of those policy types.
-
If an access request is denied due to multiple reasons, the error message includes only one of the reasons for denial.
The following examples show the format for different types of access denied error messages and how to troubleshoot each type of message.
Access denied due to Blocked Encryption Type
To limit the server-side encryption types you can use in your general purpose buckets, you can
choose to block SSE-C write requests by updating your default encryption configuration for your
buckets. This bucket-level configuration blocks requests to upload objects that specify SSE-C. When SSE-C is blocked for a bucket, any PutObject,
CopyObject, PostObject, or Multipart Upload or replication
requests that specify SSE-C encryption will be rejected with an HTTP 403
AccessDenied error.
This setting is a parameter on the
PutBucketEncryption API and can also be updated using the S3 Console, AWS CLI, and AWS SDKs, if you have the s3:PutEncryptionConfiguration permission. Valid values are SSE-C, which blocks SSE-C encryption for the general purpose
bucket, and NONE, which allows the use SSE-C for writes to the bucket.
For
example, when access is denied for a PutObject request because the BlockedEncryptionTypes setting blocks write requests specifying SSE-C, you receive the following
message:
An error occurred (AccessDenied) when calling the PutObject operation: User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: s3:PutObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" because this bucket has blocked upload requests that specify Server Side Encryption with Customer provided keys (SSE-C). Please specify a different server-side encryption type
For more information about this setting, see Blocking or unblocking SSE-C for a general purpose bucket.