A web page can make requests to access other content, where that content is either hosted on the same domain or another domain. A web page can request static content, such as an image, JavaScript, or CSS file. Additionally, a web page can make a request for dynamic content, such as making a request to a REST API. However, you cannot request resources from another website domain without proper permission. In JavaScript, cross-origin requests with an XMLHttpRequest API and Ajax cannot happen unless CORS is enabled on the server that receives the request. Otherwise, same-origin security policy prevents the requests. For example, a web page that is served from the http://aboutcors.com server sends a request to get data to the http://openliberty.io server. Because of security concerns, browsers block the server response unless the server adds HTTP response headers to allow the web page to consume the data.

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

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.

Evaluating Access-Control-Request-Headers

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.

If any allowed headers are configured, the headers are evaluated against the list of configured allowed headers and list of simple headers (Accept, Accept-Language, and Content-Language) to determine if they are permitted. If all of the methods present in the request are permitted, the server returns to the client a list of all allowed headers in the Access-Control-Request-Headers header.

Notes:

• 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.

Evaluating Access-Control-Max-Age

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.

If a maximum age has been set, it returns to clients. Clients typically interpret the value in the following ways:

• -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.

Note: Many clients have a built-in maximum period of time that they cache pre-flight results for and this might be lower than the value returned by the server.