Cross-Origin Resource Sharing
Last updated
Was this helpful?
Last updated
Was this helpful?
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.
Browsers restrict cross-origin HTTP requests initiated from scripts. For example, XMLHttpRequest and the follow the . This means that a web application using those APIs can only request resources from the same origin the application was loaded from unless the response from other origins includes the right CORS headers.
the server responds:
Now no domain other than https://foo.example can access the resource in a cross-site manner. To allow access to the resource, the Access-Control-Allow-Origin header should contain the value that was sent in the request's Origin header.
This section lists the HTTP response headers that servers send back for access control requests as defined by the Cross-Origin Resource Sharing specification. The previous section gives an overview of these in action.
Access-Control-Allow-Origin specifies either a single origin, which tells browsers to allow that origin to access the resource; or else — for requests without credentials — the "*" wildcard, to tell browsers to allow any origin to access the resource.
For example, to allow code from the origin https://mozilla.org to access the resource, you can specify:
For example, the following:
…would allow the X-My-Custom-Header and X-Another-Custom-Header headers to be exposed to the browser.
The delta-seconds parameter indicates the number of seconds the results can be cached.
The origin is a URI indicating the server from which the request initiated. It does not include any path information, but only the server name.Note: The origin value can be null, or a URI.
The CORS mechanism supports secure cross-origin requests and data transfers between browsers and servers. Modern browsers use CORS in APIs such as XMLHttpRequest or to mitigate the risks of cross-origin HTTP requests.
The request header of note is , which shows that the invocation is coming from https://foo.example.
In response, the server sends back an header. The use of the header and of show the access control protocol in its simplest use. In this case, the server responds with Access-Control-Allow-Origin: *, which means that the resource can be accessed by any domain. If the resource owners at https://bar.other wished to restrict access to the resource to requests only from https://foo.example, they would send:
A returned resource may have one header, with the following syntax:
If the server specifies a single origin (that may dynamically change based on the requesting origin as part of a white-list) rather than the "*" wildcard, then the server should also include Origin in the response header — to indicate to clients that server responses will differ based on the value of the request header.
The header lets a server whitelist headers that browsers are allowed to access.
The header indicates how long the results of a preflight request can be cached. For an example of a preflight request, see the above examples.
The header Indicates whether or not the response to the request can be exposed when the credentials flag is true. When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple GET requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.
are discussed above.
The header specifies the method or methods allowed when accessing the resource. This is used in response to a preflight request. The conditions under which a request is preflighted are discussed above.
An example of a , including an example which sends this header to the browser.
The header is used in response to a to indicate which HTTP headers can be used when making the actual request.
This section lists headers that clients may use when issuing HTTP requests in order to make use of the cross-origin sharing feature. Note that these headers are set for you when making invocations to servers. Developers using cross-site capability do not have to set any cross-origin sharing request headers programmatically.
The header indicates the origin of the cross-site access request or preflight request.
Note that in any access control request, the header is always sent.
The is used when issuing a preflight request to let the server know what HTTP method will be used when the actual request is made.
Examples of this usage can be
The header is used when issuing a preflight request to let the server know what HTTP headers will be used when the actual request is made.
Examples of this usage can be .
