Amazon S3 - Returns 403 error instead of 404 despite GetObject allowance

Question

I've set up my S3 bucket with this tutorial to only accept requests from specific IP addresses. But even though those IPs are allowed to do GetObject, they get 403 errors instead of 404 for any files that are missing.

My updated bucket policy is (with fictitious IP addresses):

{
    "Version": "2012-10-17",
    "Id": "S3PolicyId1",
    "Statement": [
        {
            "Sid": "IPDeny",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.bucketname.com/*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "100.100.100.0/22",
                        "101.101.101.0/22"
                    ]
                }
            }
        },
    {
      "Sid": "ListItems",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::www.bucketname.com",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "100.100.100.0/22",
                        "101.101.101.0/22"
                    ]
                }
            }
    }
    ]
}

(Updated with the ListBucket command, as pointed out by Mark B.)

I've found several related questions here on SO (like this and this), but their solutions are based on giving everyone permission to access the bucket's contents.

And that approach works, because if I lift my IP filter then 404 errors are given for missing files instead of 403. But that defeats the purpose of an IP filter.

I learned here that:

S3 returns a 403 instead of a 404 when the user doesn't have permission to list the bucket contents.

But I cannot find way to have the bucket generate 404 error codes for missing files without removing my IP whitelist filter. And that is with including the GetObject command for retrieving the objects and ListBucket for listing the objects.

My reasoning is as follows: if the IP addresses are allowed to access the bucket's content, then shouldn't S3 generate a 404 error for these IPs instead of 403? How do I do that without removing my existing filter?

Alba

Answer 1

I've solved the problem of S3 issuing 403 instead of 404 errors not by changing the bucket policy, but by simply adding an 'Everyone' listing policy in the bucket settings:

I feel it's a less elegant than setting the bucket policy, but it at least works now.

My accompanying bucket policy is now still based on only whitelisting a few IPs:

{
    "Version": "2012-10-17",
    "Id": "S3PolicyId1",
    "Statement": [
        {
            "Sid": "IPDeny",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::website-bucket/*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "10.1.1.0/22",
                        "11.1.1.0/22"
                    ]
                }
            }
        }
    ]
}

Alba

you say 'still based on only whitelisting' but the policy document you have seems to be blacklisting IP addresses rather than whitelisting. I guess it was a typo or smth and you meant IpAddress instead of NotIpAddress – Bounce

Answer 2

Note the documentation you quoted:

S3 returns a 403 instead of a 404 when the user doesn't have permission to list the bucket contents.

The GetObject permission you have granted only gives permission to get an object that exists, it does not give permission to list all the objects in a bucket. You would need to add the ListBucket permission to your bucket policy. See this page for the full list of S3 IAM permissions, and the S3 operations they cover.

Batwing

Thanks for your reply Mark and sharp noticing. I've added the ListBucket permission policy but the same issue still occurs -- I've updated my question to reflect that. – Alba

Answer 3

My issue was that my computer clock was not set correctly. (because of DST issues)

Garb