View a markdown version of this page

Troubleshoot access denied (403 Forbidden) errors in Amazon S3 - Amazon Simple Storage Service

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 Deny statement for the specific AWS action.

  • An implicit denial occurs when there is no applicable Deny statement and also no applicable Allow statement.

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.

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 user-arn is not authorized to perform action on "resource-arn" because context. In this example, user-arn is the Amazon Resource Name (ARN) of the user that doesn't receive access, action is the service action that the policy denies, and resource-arn is the ARN of the resource on which the policy acts. The context field represents additional context about the policy type that explains why the policy denied access.

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 type policy, 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 because 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 Denied message.

    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 Denied message.

  • 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.

Access denied due to a resource control policy – explicit denial