Cross-origin resource sharing (CORS)
Last updated
Last updated
An origin contains:
A scheme (the protocol), e.g. HTTP, HTTPS.
A host (the domain name), e.g. example.com.
The port, e.g. 443 for HTTPS, 80 for HTTP.
Basically getting resources from a different origin.
It is an HTTP-header based mechanism that allows a server to indicate any other origins than its own from which a browser should permit loading of resources
CORS defines a way for client web applications that are loaded in one domain to interact with resources in a different domain.
CORS also relies on a mechanism by which browsers make a “preflight” request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request.
In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.
With CORS support, you can build rich client-side web applications with S3 and selectively allow cross-origin access to your S3 resources.
For example, you are hosting a website in an Amazon S3 bucket named website.
Your users load the website endpoint:
http://website.s3-website.us-east-1.amazonaws.com
Now you want to use JavaScript on the webpages that are stored in this bucket to be able to make authenticated GET and PUT requests against the same bucket by using the Amazon S3 API endpoint for the bucket, website.s3.us-east-1.amazonaws.com.
A browser would normally block JavaScript from allowing those requests, but with CORS you can configure your bucket to explicitly enable cross-origin requests from website.s3-website.us-east-1.amazonaws.com.
Scenario 2
For example, you want to host a web font from your S3 bucket.
Again, browsers require a CORS check (also called a preflight check) for loading web fonts.
You would configure the bucket that is hosting the web font to allow any origin to make these requests.