Building Progressive Web Apps

Appendix C. CORS Versus NO-CORS

When a site makes a request to a resource from a different origin, that request is known as a cross-origin request (COR); for example, when the page at https://www.gothamimperial.com/ attempts to load a stylesheet from https://maxcdn.bootstrapcdn.com/, or Analytics code from https://www.google-analytics.com/.

For security reasons, browsers allow pages to embed resources from a different origin, but they do not allow a script to read the content of a resource from another origin. This is known as the same-origin policy. An embed, such as when the Gotham Imperial Hotel uses a <link> tag to load a stylesheet from a CDN, is allowed, but making an Ajax request to read a JSON file from a different domain will be blocked.

Developers have often bypassed some of these limitations by embedding resources instead of accessing them directly (e.g., by using JSONP), but these were partial solutions that only worked in some cases and re-exposed their users to the security issues that the browsers attempted to solve (mainly cross-site scripting attacks).

Clearly, a better solution was needed.

Cross-origin resource sharing (CORS) is a new (less than a decade old) W3C standard used to define these interactions between the server and browser. Both the browser making the request as well as the server responding to it can determine how requests are handled. For example, a script can configure a request so that it can come from a different origin. But for the request ...