CORS is a W3C specification and mechanism that you can use to request restricted resources from a domain outside the current domain.
What is it?
When these requests are made, the origin of the web page and the origin of the content that is being requested are compared. The origin is a combination of the scheme, host name, and port number. For example, the origin of https://mydomain.com:7843/path/to/index.html is https://mydomain.com:7843. When the origins of the web page and the content that is being requested match, the request is always permitted. When the origins match, it is called a same-origin policy. However, when the origins do not match, a cross-origin request must be made.
The enforcement of the CORS specification is performed by the HTTP client. For example, browsers implement CORS and the same origin policy because a browser does not implicitly trust the websites it visits to make requests to other websites.
Two types of request are defined in the CORS specification:
- Simple request
According to the CORS specification, an HTTP request is a simple CORS request if the request method is GET, HEAD, or POST. The header fields are any one of the Accept, Accept-Language, Content-Language, or Content-Type headers. The Content-Type header has a value of application/x-www-form-urlencoded, multipart/form-data, or text/plain.
When clients, such as browsers, send simple CORS requests to servers on different domains, the clients include an Origin header with the client host name as the value. If the server allows the origin, the server includes an Access-Control-Allow-Origin header with the allowed origin or an asterisk (*) in the response back to the client. The asterisk indicates that all origins are allowed to access the endpoint on the server.
- Pre-flight request
A CORS request is not a simple CORS request if a client first sends a pre-flight CORS request before it sends the actual request. For example, the client sends a pre-flight request before it sends a DELETE HTTP request. The pre-flight request is sent using the OPTIONS HTTP request to gather more information about the server. This pre-flight request has the Origin header and other headers to indicate the HTTP method and headers of the actual request to be sent after the pre-flight request.
Once the server receives the pre-flight request, if the origin is allowed, the server responds with headers that indicate the HTTP methods and headers that are allowed in the actual requests. The response might include more CORS-related headers. Next, the client sends the actual request, and the server responds.
An example pre-flight request:
OPTIONS /resource HTTP/1.1 Origin: https://test.ibm.com Access-Control-Request-Method: GET Access-Control-Request-Headers: X-IBM-HEADER, X-IBM-HEADER-2
A successful pre-flight request results in the server returning an empty response with HTTP status code 204. Additionally, the response contains headers which indicate to the client what is acceptable in is cross-origin requests.An example pre-flight response:
204 NO CONTENT Access-Control-Allow-Origin: https://test.ibm.com Access-Control-Allow-Method: GET Access-Control-Allow-Headers: X-IBM-HEADER, X-IBM-HEADER-2 Access-Control-Allow-Credentials: true Access-Control-Max-Age: 3600
- Enable CORS: Specifies whether to enable or disable CORS.
- Allowed origins: Specifies a comma-separated list of origins that are allowed to access the configured domain. A value of "*" indicates the resource is publicly accessible, with no access control checks. A value of "null" indicates the domain must not be accessible. This property is processed for simple and pre-flight CORS requests.
- Allowed methods: Specifies a comma-separated list of HTTP methods allowed to be used by the origin domain when making requests to the configured domain. This property is processed for pre-flight CORS requests.
- Allowed headers: Specifies a comma-separated list of HTTP headers that are allowed to be used by the origin domain when making requests to the configured domain. If this is set to "*", it indicates the request can include any HTTP headers. This property is processed for pre-flight CORS requests.
- Expose headers: Specifies a comma-separated list of HTTP headers that are safe to expose to clients. This property is processed only for simple CORS requests.
- Maximum age: Specifies a 64-bit integer that indicates how many seconds a response to a preflight request can be cached in the browser. This property is processed only for pre-flight CORS requests.
- Allow credentials: Specifies whether or not user credentials can be included in the request. This property is processed for simple and pre-flight CORS requests.
The server indicates to clients if an origin is permitted to make cross origin requests using the Access-Control-Allow-Origin header.
If the server is configured to allow all origins by setting '*' as an allowed origin, the header value will be '*', indicating that the resource can be accessed by any origin.
If the server is configured to allow some origins, the origin header presented by the client is evaluated against the list of configured allow origins. If the origin is permitted, the origin presented by the client in the origin header is returned. If the origin is not permitted, the server does not return the Access-Control-Allow-Origin header, resulting in a CORS error response by the HTTP client.
- Origins are compared in a case-sensitive manner.
The server can indicate to clients which of the headers they are permitted to expose using the Access-Control-Expose-Headers header.
If the exposed headers entry is not configured or invalid, no header is returned.
The first step performed by the server when performing a pre-flight check is to evaluate if the method provided in the requests Access-Control-Request-Method header is permitted. The server indicates to clients which methods are permitted using the Access-Control-Request-Method header.
If no methods are configured, no CORS headers are returned.
- Method names are compared in a case-sensitive manner.
The list of headers indicated by the client is also checked to ensure they are valid according to the configured policy. The server indicates to clients which headers are acceptable using the Access-Control-Request-Headers header.
If no headers are configured, the server allows any headers and returns the value provided by the client in the Access-Control-Request-Headers header.
- Header names are compared in a case-insensitive manner.
- Simple headers are only returned when the configured list of allowed methods is empty or if they are explicitly defined in the allowed headers configuration entry.
The server can indicate to the client how long (in seconds) they should cache the results of the pre-flight check using the Access-Control-Max-Age header.
If the maximum age entry is not set, no header is returned.
- -1: The response should not be cached at all.
- 0: The client may cache this entry for any period of time it wants.
- >0: The client should cache this entry for no longer than the number of seconds given.
Why use it?
The support is enabled in the following HTTP group PTFs and PTFs:
V7R3M0 SF99722 Level 40
V7R4M0 SF99662 Level 21
V7R5M0 SF99952 Level 3
Was this topic helpful?
19 August 2022