Includes the domain information which has incurred the COR, and is used for the purpose of checking the source of the domain side that has received the relevant request. In addition, this header is protected in the browser side and cannot be changed from the application side.

Allows a relevant response only when the information in the Origin request header matches. If the Access-Control-Allow-Origin header is a wildcard (*), it unconditionally allows the response regardless of the Origin request header information.

NoteIf an extremely permissive CORS policy is used, it can lead to spoofing, data stealing, relay, and other attacks through communication with malicious application programs. To avoid unexpected consequences, pay attention when defining the response header.

CORS supports 2 request types: simple and preflight.

Simple Request

The request is considered to be a simple request, if all the conditions following conditions are met:

Preflight Request

If the access authority is allowed through the preflight request, the actual request for sending the actual data is made. The preflight request can allow access based on various standards other than Origin, such as HTTP certification, HTTP method (for example, GET, POST, or PUT…), or the existence of a certain header.

If you check the request header through the network log, you find that an additional Origin header has been added. This header informs the relevant server of the sender side domain. The Origin header is protected in the browser side, and cannot be changed by the user.

NoteYou must define the authorized domains on the server side to ensure that CORS is handled properly. For more information on setting the authorization settings on different platforms, see Enable CORS Web site.

Source Code

For the complete source code related to this use case, see the following file:

If you check the network log, you find that 2 communications between the browser and server occur consecutively: first the preflight request and response, and then the actual request and response.

The preflight request checks the access authority before sending the actual data. The Origin and Access-Control-Request-Headers headers have been added to the request, because the request has a user-defined custom header, and the Content-Type set to application/json:

If the request is sent from the browser side, a preflight response is sent for it from the server side. The browser determines from the response whether the actual data is sent. In the following preflight response example, the Content-Type and Header-Custom-Tizen are included in the Access-Control-Allow-Headers header:

If the access authority fails, the browser does not send the actual data request. Instead, the following error occurs in the browser side:

XMLHttpRequest cannot load http://another-domain.com/CORS.
Request header field Header-Custom-Tizen is not allowed by Access-Control-Allow-Headers.

NoteYou must define the authorized domains on the server side to ensure that CORS is handled properly. For more information on setting the authorization settings on different platforms, see Enable CORS Web site.