S3 CORS policy for public bucket

It seems to be easy, but I don't know what I am missing. I have a public bucket with a js script that I fetch from my web site. I noticed that I don't send Origin header to S3, it is not required and everything works without any CORS configurations.

What's more, even after I manually added Origin header to that GET call and explicitly disallowed GET and my domain via:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>http://www.nonexistingdomain.com</AllowedOrigin>
        <AllowedMethod>POST</AllowedMethod>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

I can still get the content. What's going on here?

Solution

Ok, after a conversation with Quentin, I think I understand where I am misinterpreting how CORS should work. In Java world, it's a very common practice to actually reject requests when Origin doesn't match. Here is another thread where it's mentioned. If we take Spring as an example(which is de-facto standard in Java world), here is what happens when CORS filter is added:

String allowOrigin = checkOrigin(config, requestOrigin);
...

if (allowOrigin == null) {
    logger.debug("Reject: '" + requestOrigin + "' origin is not allowed");
    rejectRequest(response);
    return false;
}

where:

/**
 * Invoked when one of the CORS checks failed.
 */
protected void rejectRequest(ServerHttpResponse response) {
    response.setStatusCode(HttpStatus.FORBIDDEN);
}

You can find the code here.

But to my surprise, it is not such a common practice with other stacks and server-side technologies. Another common approach would be to send whatever CORS configuration they have to the browser and leave the decision to it.

S3 is even more tricky: it only sends CORS response headers when the bucket CORS rules match the CORS-enabled request(a request qith Origin header). Otherwise, there would be no CORS response headers.