You are viewing the preview version of this book
Click here for the full version.

CORS

Tip

You don't need to configure CORS if the bucket and the frontend are on the same domain. See Integrating with CloudFront how to do this.

Usually, the bucket and the frontend are hosted on different domains, the latter on your own, like example.com, while the former on S3, which is something like s3-<region>.amazonaws.com. This means they are on different origins and in some cases that means you need to configure for CORS (Cross-Origin Resource Sharing).

There are requests that are subject to CORS while others are not. For example, showing an image in an <img src=""> tag or downloading a file do not need any additional config, while sending a fetch in JavaScript does. Fortunately, there is an error message in the console indicating a CORS-related error:

Access to XMLHttpRequest at '...' from origin '...'
has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on
the requested resource.

CORS is a broad topic with many subtleties, but it boils down to correctly setting a HTTP header in the response: the Access-Control-Allow-Origin. In most cases, you can set it to * for the bucket you are serving the signed URLs from:

resource "aws_s3_bucket" "bucket" {
  cors_rule {
    allowed_methods = ["GET"]
    allowed_origins = ["*"]
  }
}

Of course, this only handles downloading from the bucket. We'll cover how to configure CORS for uploading in the CORS config for uploads section.

CORS on the backend

If the backend and the frontend are on different URLs then that request is also subject to CORS. How to configure it is outside the scope of signed URLs, but see this article to see an example how it can be done.

CORS