AWS S3 Bucket Policy: Deny Access by Domain

Amazon Simple Storage Service (AWS S3) is a highly scalable and reliable object storage service. Bucket policies in S3 allow you to define access control rules at the bucket level. One powerful use - case of bucket policies is to deny access to an S3 bucket based on the domain from which the request is originating. This can be crucial for security, ensuring that only trusted domains can access your S3 resources. In this blog post, we will explore the core concepts, typical usage scenarios, common practices, and best practices related to denying access to an S3 bucket based on the domain.

Table of Contents#

  1. Core Concepts
  2. Typical Usage Scenarios
  3. Common Practice
  4. Best Practices
  5. Conclusion
  6. FAQ
  7. References

Article#

Core Concepts#

S3 Bucket Policy#

An S3 bucket policy is a JSON - based access policy that you attach to an S3 bucket. It allows you to specify who can access the bucket, what actions they can perform, and under what conditions. The policy consists of one or more statements, each with a set of elements such as Effect, Principal, Action, and Condition.

Deny Access by Domain#

To deny access based on the domain, we use the aws:Referer condition key in the bucket policy. The aws:Referer key represents the domain from which the request originated. By specifying a condition that checks the value of aws:Referer, we can deny requests coming from unauthorized domains.

Typical Usage Scenarios#

Protecting Sensitive Content#

If you have an S3 bucket that stores sensitive documents, media files, or customer data, you may want to restrict access to only specific domains. For example, a company may want to ensure that its internal reports stored in S3 can only be accessed from the company's official website or internal network domains.

Preventing Hotlinking#

Hotlinking is the practice of using an image or other resource hosted on one website on another website without permission. By denying access to your S3 - hosted images from unauthorized domains, you can prevent other websites from using your bandwidth and resources without your consent.

Common Practice#

Here is an example of an S3 bucket policy that denies access from a specific domain:

{
    "Version": "2012 - 10 - 17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your - bucket - name/*",
            "Condition": {
                "StringLike": {
                    "aws:Referer": [
                        "http://unauthorized - domain.com/*"
                    ]
                }
            }
        }
    ]
}

In this policy:

  • Effect: "Deny" indicates that the policy will deny the specified actions.
  • Principal: "*" means the policy applies to all principals (users, roles, etc.).
  • Action: "s3:GetObject" specifies the action that is being denied, in this case, getting objects from the bucket.
  • Resource is the ARN of the bucket and all its objects.
  • The Condition block uses the StringLike operator to match the aws:Referer header against the specified domain pattern.

Best Practices#

Whitelist Instead of Blacklist#

Instead of just denying access from specific domains, it is often better to whitelist the domains that are allowed to access the bucket. This way, you have more control over who can access your resources. Here is an example of a whitelisting policy:

{
    "Version": "2012 - 10 - 17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your - bucket - name/*",
            "Condition": {
                "StringNotLike": {
                    "aws:Referer": [
                        "http://trusted - domain1.com/*",
                        "http://trusted - domain2.com/*"
                    ]
                }
            }
        }
    ]
}

Regularly Review and Update Policies#

As your business evolves, the list of trusted and untrusted domains may change. Regularly review and update your bucket policies to ensure they reflect the current security requirements.

Test Policies Thoroughly#

Before applying a new or updated bucket policy to a production bucket, test it in a staging environment. This helps to avoid any accidental disruptions to legitimate access.

Conclusion#

Denying access to an AWS S3 bucket based on the domain is a powerful security feature that can protect your sensitive data and prevent unauthorized use of your resources. By understanding the core concepts, using the right policies in typical scenarios, following common practices, and adhering to best practices, software engineers can effectively manage access to their S3 buckets.

FAQ#

Can the aws:Referer condition be bypassed?#

Yes, the aws:Referer header can be easily spoofed. So, while it can be used as an additional layer of security, it should not be the only security measure.

Can I use multiple domain patterns in a single policy?#

Yes, you can use multiple domain patterns in the aws:Referer condition. You can use both StringLike and StringNotLike operators to match or exclude multiple domains.

Does the bucket policy apply to all types of S3 requests?#

The bucket policy can be configured to apply to specific actions such as s3:GetObject, s3:PutObject, etc. You can define different policies for different types of requests.

References#

2025-10