Troubleshoot Access Denied (403 Forbidden) errors in Amazon S3

• For same-account access, there must not be an explicit Deny statement against the requester you are trying to grant permissions to, in either the bucket policy or the IAM user policy. If you want to grant permissions by using only the bucket policy and the IAM user policy, there must be at least one explicit Allow statement in one of these policies.

• For cross-account access, there must not be an explicit Deny statement against the requester you are trying to grant permissions to, in either the bucket policy or the IAM user policy. If you want to grant cross-account permissions by using only the bucket policy and IAM user policy, then both the bucket policy and the IAM user policy of the requester must include an explicit Allow statement.

• Identify the requester. If it’s an unsigned request, then it's an anonymous request without an IAM user policy. If it’s a request using a presigned URL, then the user policy will be the same as the one for the IAM user or role that signed the request.

• Verify that you're using the correct IAM user or role. You can verify your IAM user or role by checking the upper-right corner of the AWS Management Console or by using the aws sts get-caller-identity command.

• Check the IAM policies that are related to the IAM user or role. You can use one of the following methods:

  • Test IAM policies with the IAM policy simulator.

  • Review the different IAM policy types.

• If needed, edit your IAM user policy.

• Review the following examples of policies that explicitly deny or allow access:

  • Explicit allow IAM user policy: IAM: Allows and denies access to multiple services programmatically and in the console

  • Explicit allow bucket policy: Granting permissions to multiple accounts to upload objects or set object ACLs for public access

  • Explicit deny IAM user policy: AWS: Denies access to AWS based on the requested AWS Region

  • Explicit deny bucket policy: Require SSE-KMS for all objects written to a bucket

• If Amazon S3 rejected a LIST, PUT object, GetBucketAcl, or PutBucketAcl request, then review the ACL permissions for your bucket.

  Note

  You cannot grant GET object permissions with bucket ACL settings.

• If Amazon S3 rejected a GET request on an S3 object, or a PutObjectAcl request, then review the ACL permissions for the object.

  Important

  If the account that owns the object is different from the account that owns the bucket, then access to the object isn't controlled by the bucket policy.

• Disable ACLs (recommended) – This method will apply to all objects and can be performed by the bucket owner. This method automatically gives the bucket owner ownership and full control over every object in the bucket. Before you implement this method, check the prerequisites for disabling ACLs. For information about how to set your bucket to bucket owner enforced (recommended) mode, see Setting Object Ownership on an existing bucket.

  Important

  To prevent an Access Denied (403 Forbidden) error, be sure to migrate the ACL permissions to a bucket policy before you disable ACLs. For more information, see Bucket policy examples for migrating from ACL permissions.

• Change the object owner to the bucket owner – This method can be applied to individual objects, but only the object owner (or a user with the appropriate permissions) can change an object's ownership. Additional PUT costs might apply. (For more information, see Amazon S3 pricing.) This method grants the bucket owner full ownership of the object, allowing the bucket owner to control access to the object through a bucket policy.

  To change the object's ownership, do one of the following:

  • You (the bucket owner) can copy the object back to the bucket.

  • You can change the Object Ownership setting of the bucket to bucket owner preferred. If versioning is disabled, the objects in the bucket are overwritten. If versioning is enabled, duplicate versions of the same object will appear in the bucket, which the bucket owner can set a lifecycle rule to expire. For instructions on how to change your Object Ownership setting, see Setting Object Ownership on an existing bucket.

    Note

    When you update your Object Ownership setting to bucket owner preferred, the setting is only applied to new objects that are uploaded to the bucket.

  • You can have the object owner upload the object again with the bucket-owner-full-control canned object ACL.

  Note

  For cross-account uploads, you can also require the bucket-owner-full-control canned object ACL in your bucket policy. For an example bucket policy, see Grant cross-account permissions to upload objects while ensuring that the bucket owner has full control.

• Keep the object writer as the object owner – This method doesn't change the object owner, but it does allow you to grant access to objects individually. To grant access to an object, you must have the PutObjectAcl permission for the object. Then, to fix the Access Denied (403 Forbidden) error, add the requester as a grantee to access the object in the object's ACLs. For more information, see Configuring ACLs.

• If the specified access control list (ACL) is public, then the BlockPublicAcls setting rejects your PutBucketAcl and PutObjectACL calls.

• If the request includes a public ACL, then the BlockPublicAcls setting rejects your PutObject calls.

• If the BlockPublicAcls setting is applied to an account and the request includes a public ACL, then any CreateBucket calls that include public ACLs will fail.

• If your request's permission is granted only by a public ACL, then the IgnorePublicAcls setting rejects the request.

• If the specified bucket policy allows public access, then the BlockPublicPolicy setting rejects your PutBucketPolicy calls.

• If the BlockPublicPolicy setting is applied to an access point, then all PutAccessPointPolicy and PutBucketPolicy calls that specify a public policy and are made through the access point will fail.

• If the access point or bucket has a public policy, then the RestrictPublicBuckets setting rejects all cross-account calls except for AWS service principals. This setting also rejects all anonymous (or unsigned) calls.

• Server-side encryption with Amazon S3 managed keys (SSE-S3)

• Server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS)

• Server-side encryption with customer-provided keys (SSE-C)

• SSE-S3 – No extra permissions are required.

• SSE-KMS (with a customer managed key) – To upload objects, the kms:GenerateDataKey permission on the AWS KMS key is required. To download objects and perform multipart uploads of objects, the kms:Decrypt permission on the KMS key is required.

• SSE-KMS (with an AWS managed key) – The requester must be from the same account that owns the aws/s3 KMS key. The requester must also have the correct Amazon S3 permissions to access the object.

• SSE-C (with a customer provided key) – No additional permissions are required. You can configure the bucket policy to require and restrict server-side encryption with customer-provided encryption keys for objects in your bucket.

• If the object version is protected by the compliance retention mode, there is no way to permanently delete it. A permanent DELETE request from any requester, including the root user, will result in an Access Denied (403 Forbidden) error. Also, be aware that when you submit a DELETE request for an object that's protected by the compliance retention mode, Amazon S3 creates a delete marker for the object.

• If the object version is protected with governance retention mode and you have the s3:BypassGovernanceRetention permission, you can bypass the protection and permanently delete the version. For more information, see Bypassing governance mode.

• If the object version is protected by a legal hold, then a permanent DELETE request can result in an Access Denied (403 Forbidden) error. To permanently delete the object version, you must remove the legal hold on the object version. To remove a legal hold, you must have the s3:PutObjectLegalHold permission. For more information about removing a legal hold, see Configuring S3 Object Lock.

• The configurations for your access points

• The IAM user policy that's used for your access points

• The bucket policy that's used to manage or configure your cross-account access points

Access point configurations and policies

• When you create an access point, you can choose to designate Internet or VPC as the network origin. If the network origin is set to VPC only, Amazon S3 will reject any requests made to the access point that don't originate from the specified VPC. To check the network origin of your access point, see Creating access points restricted to a virtual private cloud.

• With access points, you can also configure custom Block Public Access settings, which work similarly to the Block Public Access settings at the bucket or account level. To check your custom Block Public Access settings, see Managing public access to access points.

• To make successful requests to Amazon S3 by using access points, make sure that the requester has the necessary IAM permissions. For more information, see Configuring IAM policies for using access points.

• If the request involves cross-account access points, make sure that the bucket owner has updated the bucket policy to authorize requests from the access point. For more information, see Granting permissions for cross-account access points.